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.
Managing a FeatureScript Library
sam_parsons
Posts: 43 PRO
Hey guys,
We've spent the last year building a great set of custom features for our joinery company. But as the library grows, we're finding it difficult to keep on top of feature updates.
We're splitting out bits of FeatureScript into functions that can be reused in different features, but then you have the issue of needing to update those if they're not within the same document as the feature.
We've thought about putting all of our custom features and functions within the same document, but then there's the scary hurdle of having to reapply those features in the feature list of all the models they're already used in.
Wondered if anyone out there had experienced something similar and had any suggestions?
Sam
We've spent the last year building a great set of custom features for our joinery company. But as the library grows, we're finding it difficult to keep on top of feature updates.
We're splitting out bits of FeatureScript into functions that can be reused in different features, but then you have the issue of needing to update those if they're not within the same document as the feature.
We've thought about putting all of our custom features and functions within the same document, but then there's the scary hurdle of having to reapply those features in the feature list of all the models they're already used in.
Wondered if anyone out there had experienced something similar and had any suggestions?
Sam
Tagged:
0
Comments
-
I would strongly suggest keeping the features all in separate documents. That way you can properly manage the versions without unnecessarily up-versioning features that didnt change.Tim Rice | User Experience | Support
Onshape, Inc.0 -
I take your point.
Based on that, might you suggest that we kept functions that we use in the same document as a kind of internal utility library? And then import those where needed into custom features which are in their own document, which may even mean that some custom features simply execute a function from the 'global functions' document and not much more than that. But then at least the custom feature is defined in its own document... ?
It's just that sometimes, it feels like it would be easier if our custom features just updated the way onshape's native features do when onshape releases a new version. Though I do understand why that isn't the case.0 -
I apologize if I am misunderstanding, but why would you need to keep the features in one doc as a library? Personally, I keep all of my features in a folder on the docs page. Generally I would avoid duplicating references as this goes against our "single source of truth" paradigm.
In our Enterprise level we do support admins setting a default company wide FS toolset and manage the referenced version for each feature.Tim Rice | User Experience | Support
Onshape, Inc.0 -
I used to keep all my featurescripts in one doc, but it got very annoying every time I tweak one of tte scripts every document i own and every part studio had a blue update icon, because there was at least one feature i was using from the document. Even though that feature was not the updated one.
Also if others use your features then they too will be annoyed by this even if the features they use are not the one you update.
Remember versions are document wide.
Eventually i ended up breaking up everything into new documents. And store those documents into a featurescripts folder that i manage as a library. Much smoother0 -
It's actually precisely for the single source of truth that we're splitting some stuff out of custom features. We're not duplicating anything, only referencing/importing.
There a certain bits of script that we end up putting across multiple custom features (like enums or functions), which, when updated, would have copied and pasted in. It seems a lot more sensible to import them in, but the question, I suppose, is from where? If those functions are in featurescript studios in the same file as a custom feature, then they aren't in the other custom features where it is used, hence the suggestion for a function library (not dissimilar to the onshape's standard library source).
Does that make sense?0 -
Hi John, that's what we've got at the moment, there's just a lot of overlap with some of the custom features. I definitely see logic in keeping the features themselves separate thoughjohn_mcclary said:Eventually i ended up breaking up everything into new documents. And store those documents into a featurescripts folder that i manage as a library. Much smoother0 -
Interesting... anywhere I can preview that functionality....?TimRice said:In our Enterprise level we do support admins setting a default company wide FS toolset and manage the referenced version for each feature.0 -
I see your problem.
How big of a cross reference spider web is it?
I still think it is ok to have a couple of features in the same document if they are part of the same suite of tools that all need to update together anyway0 -
It's a tricky one, because just when you think they don't overlap, you find some overlap....0
-
I guess the next question would be,
How important is it that they all reference each other?
Maybe some things are better off disconnected0 -
Please see our Whats new update for OCTOBER 17TH, 2019: https://forum.onshape.com/discussion/12473/improvements-to-onshape-october-17th-2019/p1sam_parsons said:
Interesting... anywhere I can preview that functionality....?TimRice said:In our Enterprise level we do support admins setting a default company wide FS toolset and manage the referenced version for each feature.Tim Rice | User Experience | Support
Onshape, Inc.0 -
Thanks Tim! It looks like that would be useful for making sure the team's toolbar is up to date. But doesn't necessarily help us when it comes to managing the code and feature studios.TimRice said:Please see our Whats new update for OCTOBER 17TH, 2019: https://forum.onshape.com/discussion/12473/improvements-to-onshape-october-17th-2019/p1
You're right John, not all of them need connecting, and it might need to be determined on a case by case basis.john_mcclary said:I guess the next question would be,
How important is it that they all reference each other?
Maybe some things are better off disconnected
Just wanted to see what other onshape users were doing with repeated FS code.1
