Welcome to the Onshape forum! Ask questions and join in the discussions about everything Onshape.
First time visiting? Here are some places to start:- Looking for a certain topic? Check out the categories filter or use Search (upper right).
- Need support? Ask a question to our Community Support category.
- Please submit support tickets for bugs but you can request improvements in the Product Feedback category.
- Be respectful, on topic and if you see a problem, Flag it.
If you would like to contact our Community Manager personally, feel free to send a private message or an email.
A few more undocumented FeatureScript functions
Caden_Armstrong
Member Posts: 364 PRO
Over on the SmartBench blog I've written another article discussing a few undocumented FeatureScript functions that I find useful.
While there are some hidden gems in the std code, just keep in mind that undocumented functions could produce unexpected results, or change without warning. Something to keep in mind if you use these in any business critical applications.
Are there any gems hidden in the featurescript std code that you've found to be useful?
Experts in Onshape Automation - Custom Features and Integrated Applications
Comments
Not undocumented functions but undocumented behavior of functions was discussed pretty widely in this thread.
There are apparently a number of hard-coded feature names in the standard library that change the behavior of the rest of the product. Some examples are that sheet metal contexts will never inherit the tree name unless your feature declaration is sheetMetalStart specifically, the in-context mate connector functionality discussed in that thread is only enabled when the feature declaration is mateConnector, you can't override the tree name of any computed feature name unless your feature declaration is either hole or routingCurve which have computed names but can be overridden by the user. I ran into an issue with library validation stuff where no copy of formedUtils would pass the sheet metal form library validation step even if it was unchanged from the original std.fs copy, it seems to be looking for the document ID to be referenced instead of the code.
I did find a lovely little operation called opSplitBySelfShadow that's gonna make its way into 456D Make. What it does is essentially a draft query where it takes an object as an input and returns all the faces that are visible from a direction and all the faces invisible from a direction, and will draw split lines on any shadowed faces from that direction that are included in the selection set. I originally was looking for a tool that would let me normalize geometry for my slices via this shadowing operation but discovered that it's actually also got some utility for stuff like 3d printer support generation potentially. Completely unused in the standard library right now.
Derek Van Allen | Engineering Consultant | MeddlerUndocumented behaviour is usually a little harder to take advantage of. I've come across the hard coded feature names a few times.
There is some functionality that standard features have that I wish could make their way into general use, like multilingual support. Standard features are multilingual, Itd be great if I could make a multilingual custom feature.
I wrote an article a while back when I figured out why newSketch has a hidden parameter for specifically sheet metal, so sometimes you can take advantage of undocumented behaviour.
Experts in Onshape Automation - Custom Features and Integrated Applications
Thanks, Caden! I'm all for this kind of blog content. I don't think I've used constructPaths() before and have probably worked around it manually with constructPath() instead.
The Onsherpa | Reach peak Onshape productivity
www.theonsherpa.com
I've built work around too. Feels like a right of passage for fs developers.
Experts in Onshape Automation - Custom Features and Integrated Applications