Adding ease of use abilities to the std. sheet metal model feature

shawn_crocker

@lougallo

I am starting out very simple.  I am trying to add a selection list to the standard sheet metal model feature.  if I select an option, I want the sheet metal material properties to be set either from predefined values, or if custom is selected, from user input values.  I am creating a function that will decide what values should be returned.  I will then replace the "definition. whatever" calls with the function call.  It seems I cannot see definition.thickness (and others) from my function which is strange because I see it being referenced in other functions in the feature.  Could someone please tell me what simple thing I am missing here? CUSTOM SHEET METAL FEATURES | sheetMetalStart.fs Copy 1 (onshape.com)

I know there are going to be more robust ways of doing this but I am just trying to get this super simple way to work first.

shawn_crocker

I realized I needed to be passing the definition map into the function.

Alex_Kempen

I actually spent some time putting together a short intro to functions document a little while ago. I think it does a decent job explaining basic function behavior, especially for those who don't have a lot of programming experience. You can find it here. Feel free to take a look at it and let me know what you think.

shawn_crocker

I realized I needed to be passing the definition map into the function.

Alex_Kempen

I actually spent some time putting together a short intro to functions document a little while ago. I think it does a decent job explaining basic function behavior, especially for those who don't have a lot of programming experience. You can find it here. Feel free to take a look at it and let me know what you think.

shawn_crocker

@Alex_Kempen
Your article is great!  I've been finding there is not a lot of clear use cases for featurescript.  Not many YouTube videos either.  The onshape featurescript documentation is a little too vague with its examples I am finding.  For some reason I was thinking the definition map that is storing the users input was global.  Because it seems to been visible to the second code block of the feature.  I guess that is some sort of special featurescript ability enabling it to be seen in that second block only?  I then discovered I didn't need a function.  I was initially trying to hi jack the definition values inside the precondition block which seems to not allow data manipulation like that.  I was able to logically overwrite the values from that second code block.  My other main interest now is using a .csv file.  I really want my material list selection at the start of the feature to populate out of the csv.  And then my goal is to also update the definition values with values out of the csv using vlookup or something.  When I insert the code snippet to allow user selection of an imported .csv, the debug system informs me that "no declaration found for tableData".  Here is my document so far.  CUSTOM SHEET METAL FEATURES | sheetMetalStart.fs Copy 1 (onshape.com).  Do you happen to have any info on working with csv files.  Do you know if I must do some addition thing to allow the tableData.  I was looking at the code of another script 3D XYZ CSV Points and Splines and I am not seeing anything special happening before the insert of that tableData thing.

Alex_Kempen

Okay, there's a few things to unpack.
There is a little blurb on CSV imports buried in the Onshape documentation here. Assuming you've found that already, I think your issue is that you've consistently entered "tableData" instead of "TableData". The difference is that "TableData" is a custom enum or type, as it follows the Onshape standard upper camel case (Pascal) for types and enums (MyEnum, MyCustomType), whereas "tableData" would most likely refer to a variable or a function, as it is written using lower camel case. These standards help prevent confusion and errors like yours, and I would strongly recommend adopting them to your own code. (definition.myEnum == MyEnum.MY_VALUE is a lot cleaner, than, say, definition.myEnum == myEnum.myValue).

Next, its important to note that there isn't anything particularly special about the definition map; it certainly isn't global, and it has to be carefully managed. If a function needs to make changes to the definition which affect other functions later on, then the function should also return the definition, and the definition of the main feature should be overwritten with the new definition provided by the function.

definition = extrudeUpToBoundaryFlip(context, definition);

Lastly, I want to discuss your use case specifically. You probably don't need to be modifying a copy of all of the code of the sheet metal feature itself; I think it would instead be easier to create a copy of the sheet metal feature's UI, then go back and add in your own UI elements and set them to override the definition as needed before passing them into a call of the sheet metal feature itself. This is called wrapping a feature, and it can be a good way to add alternative inputs to function without having to fool around with the complicated bits that you don't really need.

For example, an 1/8" aluminum sheet is really just a sheet metal part with a thickness of 1/8" and some other properties defined; thus, you can do something like the following in your code:

if (definition.material == Material.ALUMINUM_125)
{
    definition.thickness = 0.125 * inch; // can also pull values from a map or CSV instead
    definition.kFactor = 1/16 * inch;
}
else if (definition.material == Material.ALUMINUM_085)
// etc.

// call the sheet metal function
sheetMetalStart(context, id, definition); // pass in your updated definition; additional parameters which don't match a sheetMetalStart parameter will be ignored

An example of a feature which has had it's UI broken out and is in a ready to wrap format can be found here; as you can see, my custom feature holeUI has all of the UI of the hole feature copied and pasted, as well as the hole editing logic function, and simply calls the hole feature itself internally. Hopefully you could imagine how one could then add on some additional options to the hole UI and then override the definition with the newly computed values (before the hole call).

shawn_crocker

Yes I'm loving that idea of just enabling different ui abilities.  Then when onshape updates there master feature I may only have to update my features version reference depending on the complexity of there change.  As for the TableData thing, it is spelled out "TableData" in the code.  Still gives the error 

I'm noticing the feature does not have a "import(path : "onshape/std/geometry.fs", version : "1521.0");" at the begining.  When I paste that in it throws errors all over the code.  I think I am going to start setting up for a UI wrap thing because that TableData thing seems to work when creating a fresh feature.  There must be something missing from the onshape feature in the imports that is not allowing the declaration.  Thanks for all the help your providing.