New Feature: Linear Pattern Plus

EvanReese

I've been wanting this one for a while, so I finally got around to making it! This is riff on the native Linear Pattern feature that adds arrow manipulators, options for patterning based on total length or referencing other geometry. It also adds a third direction to the pattern. Enjoy it and let me know what you end up using it for!

Go get it here: https://cad.onshape.com/documents/1196579d97167d7a348652a9/v/1c9b35be187e7992fe9815d7/e/3e9783cad47053c2abb99ce0

Watch the 10-minute video tour here for details: https://youtu.be/tQbTv60SVL4

S1mon

@Evan_Reese

Video looks great. The permissions or location of your FS seem to be off. I can't access it.

I'd love to see this kind of spacing functionality with non-rectangular spacing. I assume a parallelogram (or parallelepiped) would work, but it would be cool if any 4-sided surface or 8-sided part would work. I know there's Surface Pattern, but it doesn't have some of the nice additions that you've done.

EvanReese

lol critical mistake. Try now.

MichaelPascoe

This will save some headaches. Very legit. Thanks for sharing @Evan_Reese!

SethF

So cool, @Evan_Reese! I've set up a lot of configurations where I had to do the math each time. Looks like you've got a pretty slick UI (speaking as someone who has very little experience developing UIs..). I'm excited to try it out!

EvanReese

S1mon said:

I'd love to see this kind of spacing functionality with non-rectangular spacing. I assume a parallelogram (or parallelepiped) would work, but it would be cool if any 4-sided surface or 8-sided part would work. I know there's Surface Pattern, but it doesn't have some of the nice additions that you've done.

Do you mean like forcing a rectangular grid to constrain to fit into a circle or something? Can you share an example?

EvanReese

SethF said:

So cool, @Evan_Reese! I've set up a lot of configurations where I had to do the math each time. Looks like you've got a pretty slick UI (speaking as someone who has very little experience developing UIs..). I'm excited to try it out!

Glad I'm not the only one! This pretty much just automates repetitive setup I've been doing with variables and measurements and makes it a lot more interactive.

S1mon

@Evan_Reese

I was thinking in terms of how surface pattern works along U and V. It already does one of your spacing options where it will do the math to divide up 0…1 by however many instances you want in U and or V. It would be great to have the min/max spacing and the border options. 

EvanReese

S1mon said:

@Evan_Reese

I was thinking in terms of how surface pattern works along U and V. It already does one of your spacing options where it will do the math to divide up 0…1 by however many instances you want in U and or V. It would be great to have the min/max spacing and the border options. 

Got ya. I think that sounds like it ought to be a totally different feature or a fork of the Surface Pattern feature. I'm just doing some algebra here, but as soon as we take the min/max spacing into 3D on a surface's UV space I don't know how to validate it anymore since the UV's may not be distributed evenly, and the surface may double back close to itself. All I can think of would be to loop through every single instance and check its closeness to neighboring ones and then modify the feature somehow in a recursive process, which sounds prohibitively computational. There's probably something simpler I'm not thinking of and maybe some computer science master could offer some help, but it's over my head. I mostly just do industrial design 😃

EvanReese

I just updated this to add arrow manipulators when using Measured Value with an offset.

shawn_crocker

@Evan_Reese This is a perfect pattern tool. It does all the things I have always had to strong arm features into accomplishing. Nice work!

EvanReese

shawn_crocker said:

@Evan_Reese This is a perfect pattern tool. It does all the things I have always had to strong arm features into accomplishing. Nice work!

Thanks! I'd had to strongarm one too many times and I was fed up with it.

adrian_vlzkz

Another Home Run @Evan_Reese, thanks for sharing

EvanReese

Thanks @adrian_vlzkz

EvanReese

I just released an edit to this feature that I think makes a bit more sense. Previously I had 3 options for the spacing:

1. spacing - like the normal pattern feature
2. Total length - which let's you pick how long the whole things is
   
3. Measured length - which let's you measure how long the whole thing is
   

Since then I've had some cases where I wished I could just measure the gap between a single instance, so now I've got it split out where you have options for:

1. Spacing
2. Total Length

and a second set of options for:

1. Distance - you can input a number, like the standard pattern feature
2. Measured Value - you can measure anything and use it for either the total length or instance spacing

I think it's more flexible this way. Hopefully you all agree! If so, update to V4.

shawn_crocker

@Evan_Reese
I have been enjoying this feature so much.  I come across a patterning problem quite often.  I often want to pattern a set distance over a measured length and have the last pattern instance stop short of the end leaving a space that is less then the pattern spacing.  You have that covered perfectly in this feature.  Very often, I want to create something else downstream in the feature tree that fits into that space and I think it would be really cool if you could create a section in the feature that allows the creation of a variable that represents this leftover space.  I'm thinking there is room for having the feature create variables for all kinds of things here but immediately this would be very useful at least to me.  Also, I wouldn't mind generating the code myself if you don't have time to do it but I'm thinking with a feature of this caliber, it would be best for the code to make it back to the source.  Is that something you would be open too?

shawn_crocker

@Evan_Reese
What I coincidence.  I just noticed, there is a little bug with the exact spacing parameter.  If measured distance is used, exact spacing does not work and the outcome is the same as nearest spacing.  See my little .gif that looking back at, is super unclear.

EvanReese

@shawn_crocker
Glad you're enjoying it!

I think I understand what you're getting at with the variable, but does just creating a variable on the fly work? If you start typing a new variable name into that field you can automatically make one that will come in right before the feature. There are several benefits to that in my opinion. First, I don't like mashing two features into one when they'd work just as well separately. In this case, I don't see how making the variable inside of this feature is better than just making it outside of it. And second, the end result is a lot more readable. If someone else needs to edit your model they may not know where that variable came from. Maybe I'm misunderstanding your ask here though. Let me know.

As for the bug, I'll look into it when I've got time. It's been a busy week. Thanks again for the suggestion and feedback!

shawn_crocker

@Evan_Reese
Thanks for getting back.  actually, my aim for the variable being created by the feature is to avoid doing the calculations before the feature when the feature is already doing the calculations internally.  If I'm just rocking and rolling through a design I create the pattern feature, tell it what to pattern, tell it what to measure to fit the instances to and am then, desirably, left with a space to fit in a piece that is not as large as the instance spacing.  Because I'm a bit of a configuration junky and almost everything I am designing will inevitable be used again but slightly different, that left over space will be changing all the time.  In order to accommodate ATM, I basically have to create an equation driven variable that performs some variation of the calculations that are already being done within the pattern feature.  If the pattern feature could do its work and when done, spit out a variable that equals the leftover space I'm thinking it would be a very clean workflow.  What would also be just as good and possibly more flexible for differing workflows would be for the feature to create a variable that represents how many instances it calculated and the measured distance that was selected.  This concept is coming straight from functionality solidworks would allow for.  You could create a pattern that automatically did the work that was needed, just like your feature, and downstream, you could link other features to the data it had calculated like instance count and such reducing the amount of user created equations.

some additional info that may bring more logic to this request:

Since the upgrading of the assembly replicate feature, I almost always use the replicate tool instead of the assembly linear pattern.  Usually what I do is create some type of surface in a part studio with a single circular face at one end that represent the position of the first instance to be patterned in the assembly.  Then I use your feature or in the past, equations and variables to get a dynamic pattern of that one face along the surface.  Now I have a surface with a bunch of circular faces on it that can be configured, brought into an assembly and driven.  If I mate my first part instance to that mating surface, replicate will also dynamically do the rest of the work for me.  The last step in reducing the amount of premeditated equations would be for your feature to just create some variables that hold data corresponding to some of the features internally calculated things.

I know I could copy out your feature and make it work how I'm trying (probably failing) to describe but I have a nasty feeling about having parallel stuff doing the same thing.  Let me know if you are still on the fence and I will just mod it so that you can see exactly why this functionality would be so great.  My main goal here is to not start using my own customized version of your feature.  Not because I don't want to do the work but because I'm thinking things are better to stay referring back to the source when possible.

EvanReese

oh oh oh I see! You're saying that the feature is already figuring out some numbers based on the measurement, but it doesn't tell you exactly what they are and you'd like to be able to access them downstream. That does have a lot more merit. I'm not going to promise to make that change, but I'll give some thought to what it might look like to implement and decide if I think it's either too cluttered or too niche. I'm considering adding either a second "tab" using a horizontal enum to take the feature into a separate "variable UI" or maybe even create a second feature that can get the information from the first feature and set all of the variables. My main concern is adding complexity to a feature that's already borderline too complex.

shawn_crocker

I like the idea of creating a tab.  It would make for a nice conscious shifting of focus once your pattern settings are dealt with.

Hans_Ole_Leirvik

Wow, very good. I will use this to place series of holes.
It will save me some time.
Thank you

EvanReese

shawn_crocker said:

I like the idea of creating a tab.  It would make for a nice conscious shifting of focus once your pattern settings are dealt with.

Might be the way to go, but there may be some value to it being a secondary feature that could actually be used with a number of other features. They'd have to be designed to work with it, but if there's any feature that calculates anything you may want to make into a variable it could be designed to be compatible.

EvanReese

@shawn_crocker
I couldn't stop thinking about the idea of a separate feature that can pull variables out of other features, and it seemed easy enough so I had to give it a go. Take a look at this workflow and see if it would meet your needs. I like the flexibility this gives, as opposed to adding a whole separate UI to any feature that could produce variables. The downsides are that it may not be obvious which features are compatible (currently only Linear Pattern Plus), you can't control which variables are included or excluded, and the variable order in the variable table flyout is currently arbitrary (but I think I could probably fix this somehow). I still expect to prefer this, but I'll use it more and see if I still feel that way. Let me know what you think too.

If you want to try it, you can add the Extract Variable feature here. For now, it only works with Linear Pattern Plus, but I wrote some functions that would make it a lot easier to add compatibility to other features. I encourage any other FS developers to consider whether any of your features would benefit from compatibility with something like this.

EvanReese

Hans_Ole_Leirvik said:

Wow, very good. I will use this to place series of holes.
It will save me some time.
Thank you

Thanks! glad to hear it will help.

shawn_crocker

Evan_Reese said:

@shawn_crocker
I like the flexibility this gives, as opposed to adding a whole separate UI to any feature that could produce variables

I'm starting to see this as the better solution as well.  So far it seems quite friendly to use.  I wasn't aware features could directly reference another features.  I'm imagining other custom features being able to also directly interface with the linear pattern.  I often create a pattern and then need to create other patterns that use the same settings as the first one.  If linear pattern itself could reference another instance of itself and do what that first pattern does.  Like often need to pattern faces or features and then need a part pattern to follow along (or maybe linear pattern plus could handle patterning mixed input data types in one go?).  I have a sheet metal feature that can follow other sheet metal parts.  I can reference other sheet metal while creating a new sheet metal (by selecting the attributed part. didn't know how to interface with features directly) and it follows along what the first sheet metal instance is doing.
I like how you can select multiple features with your extraction tool.  Not sure if it is possible, but it would be useful I think to see a list of the available data to extract from the selected features and then be able to explicitly name a variable for anything in the list.  Maybe not naming something automatically excludes it and a variable is not created for the particular list item?
Thanks a lot for all this.  You are so quick!  This would have been weeks of me combing the web searching for tidbits of info to overcome a hurtle that apparently nobody has come across or is just so obvious, I can't see it.

Here is a link to a document containing my testing of the extraction tool.
https://cad.onshape.com/documents/4acbd9c458cb4f1965cb5ebd/w/afcbb4ef6d6da8f5a20a44da/e/fdd9546dd00a2bcb1be053bf

I am unsure what the lengthOne variable is?  Also, it would be great to get a variable out of the pattern that represents the distance shown in the below image



I also created this document so you could see directly what I mean about the exact spacing algorithm picking the wrong calculation type if the measured length option is being used.  It seems the exact spacing choice combined with the measured length choice is causing the calculation to be the same as the approx. spacing.  This is also being reflected in the variable extraction.  You can see one of the spacing variables is around 5.5IN and the other is at 5IN when both pattern features have been set to 5IN using the exact spacing option.

S1mon

@shawn_crocker

I'm not sure how parametric this would be if you change the number of instances in the pattern, but couldn't you just use Measure value to extract this dimension?

EvanReese

Thanks, Shawn!

All I'm doing here is making Linear Pattern Plus create one variable that's a map of all of the variables to extract, which looks something like this:

{"lengthOne" : 20*inch, "spacingOne" : 2*inch, "countOne" : 10}

The trick is that the variable name starts with a character that's not allowed for a variable name (i.e. the standard Variable feature wouldn't let you do it. Something like "@ or ["). That makes the variable hidden in the part studio so it doesn't show up in the variable table or autocomplete. You'd never know it's there, and you can't access it directly, but downstream features can. I'm using the feature's id as the variable name, which makes it unique, and that's how Extract Variable is finding it when you click the feature to extract from. After that it's just looping over the map and declaring each one as a variable. Even if another solution ends up being better because of some of the limitations noted in my last message, I had fun working this out!

I could use the same technique to store pattern settings for use across multiple features, but it would take a bit of work. See my Captive Nut feature which can also take a Nut Spec Variable feature to drive the UI. It could be similar to that, but you'd just select a previous pattern feature instead of creating a separate Pattern Spec Variable. If implemented, I imagine it should match the directions, counts and distances, but not the pattern type or selections. Definitely an interesting idea, but again, I'm always wary of letting features get bloated to the point that they're too hard to use. I'll think on it. I've considered adding a "simple/advanced" enum to some features which would default to simple, but remember your last selection, so beginners get a simpler UI, but less powerful feature, and can "upgrade" later if they want.

"lengthOne" is the total pattern length. I may want to find a way to add descriptions to the variables too. I could definitely add a "remainderLengthOne" variable or something for the case you mention above.

Thanks for the example document. I still need to get on that bug fix sometime, but it sounded less fun 

EvanReese

S1mon said:

@shawn_crocker

I'm not sure how parametric this would be if you change the number of instances in the pattern, but couldn't you just use Measure value to extract this dimension?

You could, but you'd have to have a point to reference on the last instance, and, as you say, it would break if you changed the instance count. Shawn's point is that since the feature is already doing all of that calculation, it may as well also be able to spit out variables, which makes sense to me.

shawn_crocker

@S1mon
Yes and know.  If something is configured, measure value will fail because the ID of the last instance will be changing all the time.  I have found the most robust way to figure out this value is to just calculate it with variables and then create geometry that fits in the space driven by the variables so that nothing breaks.  Not having this final dimension automatically created as a variable by the linear pattern features means, most of the calculations the feature is doing to create pattern instances and distance, I have to do again.  With this great extraction tool @Evan_Reese has created it certainly makes for less number crunching in variables as I can use the instances and spacing auto generated variables.  However, this would still leave needing to create a variable with the measure value tool for the measured length previously selected within the pattern feature, and then use the three variables to create the final variable that represents the remaining space.
One might ask the logic here as to why so much concern is being put onto patterning parts in a part studio.  This is because I am usually patterning parts or faces of a surface to create some construction geometry that gets brought into the assembly.  The construction geometry is used to replicate parts onto which quite effectively brings the versatility of the part studio tools into the assembly environment.  I'm looking at things from a configured assembly/part studio perspective as I am usually aiming for a configured highly reusable model as an end result.  In my company, we manufacture not such a large variety of different products but a wildly huge variety of options available to those products or customer requested customizations.

shawn_crocker

Evan_Reese said:

Thanks for the example document. I still need to get on that bug fix sometime, but it sounded less fun 

It is Saturday after all.  I noticed FYI that its seems the pattern length variable is adding an extra instance to is summing.  I think that's why I wasn't getting what it was for at first.