New FeatureScripts - Variable Suite and Plate Suite

Alex_Kempen

Hello all,
I'm extremely happy to be finally sharing my latest and greatest FeatureScript projects. Earlier, less complete versions of each of these were demoed at the Onshape workshop in early August - the fully finished versions are now public and available for use.

Variable Suite
https://cad.onshape.com/documents/d33530b06909083111cf1770/w/5be0429e68b3332e158a3559/e/963c20a96586623733457a41
Variable Library
The variable library feature makes it possible to quickly import variables from one part studio to another. This makes it easier than ever to set and use global variables without having to mess around with feature studios or code. It can be used to build large libraries of variables which can be used by your entire team, or to quickly define a few variables which can then be parametrically used across several part studios in a project.


Variable Hole
The variable hole feature utilizes variables to transfer entire hole definitions. This makes it possible to create variables which can then be used to instantly define an entire hole, including information like counterbore/countersink, standard, hole type, tap size/depth, and so on. And thanks to my variable library feature, it's easy to setup and use these variables across an entire project or organization.


Variable Properties
Variable Properties behaves similarly to the Variable Hole feature, making it possible to create variables which can be used to quickly define part color and material type.


Plate Suite
https://cad.onshape.com/documents/2c2b49357f3f1a232881256a/w/6258e1943ecedc8606542dd7/e/68778048129306d291c7bb9c

Plate Extrude
The plate extrude feature allows users to quickly extrude flat geometry. The plate extrude feature can be used as a standalone feature, or it can be used in conjunction with other plate features. Useful options include the ability to select a plate plane to extrude off of, symmetric up to behavior, and the ability to extrude adjacent faces as separate parts.


Plate Tab
The plate tab feature serves as an alternative to the plate extrude feature which creates plates centered around single holes. This can be used to create tabs which connect to existing geometry, or to quickly create simple linkages from scratch. Useful options include the ability to use variables from the variable hole feature, as well as the ability to define start and end conditions for tabs.

Plate Hole
The plate hole feature can be used to quickly add holes to plates created by a plate extrude or plate tab feature. Holes can be defined manually or using a hole variable created by a variable hole feature. Useful options include being able to arbitrarily flip the side of the plate holes originate from, the ability to quickly add holes to existing features, and the ability to add new geometry to existing plates without interfering with any existing geometry.

Plate Fillet
The plate fillet feature makes it easy to quickly fillet plates. Useful options include the ability to fillet an entire plate at once, the ability to select faces and edges to exclude, and the ability to add full round fillets to the sides of plates with a single click.

Oh, and for those curious, here are some stats:
21 different feature studios
~50 unique custom error messages
~3,800 lines of code
~way to much of my free time 

Thanks for reading, and I hope you find them useful!
Alex Kempen

MichaelPascoe

Very nice bro, Thanks for sharing!

Variable library is pretty outside the box  

ilya_baran

Very cool!  Here's an idea on the variable suite (yes, I know we need a built-in solution for that -- we're working on it):

If instead of having one feature, the user were to create variables using our variable feature and your custom features would create the cube and import all the variables (getting them using the getAllVariables function), you'd have two benefits: editing the variables via the variable table and being able to configure the part studio and configure the variable values.  That would let the user set up a configured design, consisting of multiple part studios, controlled by a single configured set of variables.

MichaelPascoe

If you were to implement ilya's suggestion, someone could model a whole studio, then throw in your feature at the end to capture the variables. That could be useful.

ilya_baran

@MichaelPascoe I wouldn't recommend that for performance reasons.  It's cheap to import a part studio everywhere that just has a bunch of variables, but can be more expensive if there's a whole design there.  This is why we suggest people avoid chains of "derived" parts.

MichaelPascoe

Good to know.

EvanReese

@Alex_Kempen
You launched them! I'm excited to use them. Thanks

Alex_Kempen

Okay, I've just released a new version of the variable library suite which implements @ilya_baran's suggestion. The variable library feature now packages all existing variables into a single variable library cube. As Ilya pointed out, this simplifies its usage and makes it possible to use with the variable table, which is very convenient.


I also experimented with a version which allows users to cache variables to a hidden parameter. This has the benefit of allowing users to then suppress any created variables (since their values are now saved inside a hidden parameter directly), resulting in marginally better performance. However, this breaks my other variable features since types don't behave as expected when added to a parameter using editing logic, which seems like a bug. Type casting custom types (such as enums) inside editing logic also doesn't seem to work, which is rather strange.

EvanReese

ooh! I do like that workflow

MichaelPascoe

Well that was fast. 

lemon1324

@Alex_Kempen looks good! My desired use case (and I was about to write something that did this, but worse) is to be able to define custom hole profiles (e.g. 100 deg countersinks for aerospace fasteners), and then use those profiles repeatably.

The problem is that the hole variable definition requires you to define the end type, and if I attempt to define a through-hole variable but then override it to be blind, it also overrides all the custom dimensions I dropped in. Looks like this might be because you're using the official hole feature lookup tables? I'd prefer the hole definition to by default not allow changes to the shape, but allow changes to end conditions; if you're overriding more than that you really should be using a different hole variable, in my opinion.  I'd approach this by defining a local input for end type and depth, then merging that into the hole variable.  I can probably make a "pull request" on my copy by the weekend if that helps.

Also, trying to define a countersunk blind hole variable throws an error for me, though simple and counterbored blind holes work fine.  I think definition.useTipDepth on line 100 of variableHole.fs isn't being set, and your 50 error messages didn't catch it

Alex_Kempen

So, it looks like useTipDepth is actually an artifact of a previous age in the onshape hole feature; it's set to false by default in the hole feature (using the third optional argument of defineSheetMetalFeature), so that section of code never actually runs unless you call hole(context, id, definition) with definition.useTipDepth set to true. Exciting.

I'm surprised the hole editing logic is overriding your custom input parameters since the passed in lookup table should be set to custom, which should prevent any of the fields from being overridden. If the standard table of the hole variable is not custom, then it doesn't surprise me if it does override your fields to enforce whatever standard was selected.

I was moderately aware of the hole depth problem, but I didn't try to implement any sort of solution for it since the scope quickly expands once you start trying to figure out what to define locally vs globally. I agree that setting the end condition locally makes sense, but it gets murky when you consider that blind in last is an end condition option. I could use advanced conditional visibility to make the local depth options appear/disappear if blind in last is enabled in the hole variable, but that's been something I've been trying to actively avoid with the hole variable feature since it can cause weird things when the underlying variable is changed. It's also annoying for tapped holes since the tapped conditions might also need to update based on the chosen depth, and even setting them so they can be enabled is weird due to the default visibility settings of the hole feature. Accordingly, I'm definitely open to something like you've proposed, but I'm not sure there's a good solution that works well for it.

lemon1324

Ah, I see. I'm trying to define a custom hole that is "almost" an ISO standard hole, so I was creating a hole variable by selecting an ISO M1.6 and then modifying the countersink diameter and angle, then saving it.  If I do the same thing, then manually flip the hole standard to "Custom", overriding the variable and modifying the end condition when using it works as expected.  A quick solution for this (for my use case, at least) would be to override the hole standard to "custom" prior to saving any hole variable.

I'm wondering if one could make a "hole library" feature that assembles a lookup table from hole variables defined in the part studio, then when using the hole variables you just choose to use your alternate lookup table instead of the standard Onshape hole table.

Alex_Kempen

I have had a similar idea for dynamic hole presets in the past, but there unfortunately isn't really a way to dynamically generate UI options. The closest you can probably get is having a generic enum (i.e. Preset 1, Preset 2, Preset 3, etc.) and a read only parameter. It would maybe work, but I think the current variable functionality is better overall.

In regards to the issue you've been having, I think I've successfully added a fix. Basically, it now updates the oldDefinition to keep the hole table standardization logic from triggering and overriding stuff unnecessarily. I'll need to do some further testing, but it should be in the next update alongside some other cool stuff I've been tinkering with. 

lemon1324

Ah right, forgot you can't read anything from the context in the precondition.

Thanks for the responsiveness, looking forward to that update!

MichaelPascoe

Used variable library earlier, pretty smooth.

The automated option is very nice!

Of course, it was an expensive use. I traced several trim profiles, measured, then grabbed the measurements with the library feature. I'm not sure of a better way to do something like that without it creating a small derive chain, especially if I want the profiles to be sketch driven instead of variable driven.

Alex_Kempen

Hello all,
I've just pushed an update to my Variable library feature which adds a bit of new functionality. Notably, it is now once again possible to import variables from CSV files. There is also now an option to add descriptions to variables when they are being created. These descriptions can be seen in studios which are using said variables via a custom table feature.


A template sheet which can be used to generate a valid CSV file for importing variables can be found here:
https://docs.google.com/spreadsheets/d/1k5xZ5Lqxz4xRqVlRQ4j5USSUi_MWBjeumz-F2teNtok/edit#gid=0


Note that importing from a CSV file can be somewhat finicky - variables must have unique names and should always start in the leftmost column. 

You can find my variable suite here:
https://cad.onshape.com/documents/d33530b06909083111cf1770/w/5be0429e68b3332e158a3559/e/d329c12b1b5b5ddb643bccc2

As always, I hope you find these features useful!

EvanReese

The descriptions thing is awesome! that should be a standard part of the part studio variables tab.

ilya_baran

Agreed.  Descriptions are on our todo list.