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.
Why is it not possible to Suppress a Feature Folder?
StephenG
Member Posts: 370 ✭✭✭
Feature Folders were a much needed addition to help address difficult to manage and manipulate feature lists. However, it appears it is not possible to suppress/unsuppress the folder such that all the features it "contains" are suppressed/unsuppressed. I would have thought that folder suppression should be possible.
Am I missing something? Is there a logical reason why Folder suppression is not possible?
Here is my usage scenario where it makes sense to support feature folder supression...
All my modeling is initially done as a idealized concept where everything is modeled to a nominal size; a 1" dia shaft fits nicely in a 1" hole. Once the concept is worked out I will tweak the geometry using direct modeling approach to introduce the proper amount of tolerance gaps where needed. I collect these modeling tweaks in a feature folder.
Also, I 3D print a lot of my models, as either an actual end use parts, or as a semi functional mock up. Because FDM 3D printers often over extrude material I will make further adjustments to the geometry that has critical fit features, or small features (<2 mm). I collect theses adjustments in a feature folder as well.
I do this so it is clear where the critical interfaces are, and to isolate the tweaks made to support 3D printing. If I need to change the design concept I want to be able to suppress all these geometry tweaks while making the change. Suppression/unsuppressing a folder would be a lot easier than expanding it, using Shift section the top and bottom entry, then RMB select Suppress/Unsuppress.
Feature folder suppression could be something that be can added to part configurations.
Am I missing something? Is there a logical reason why Folder suppression is not possible?
Here is my usage scenario where it makes sense to support feature folder supression...
All my modeling is initially done as a idealized concept where everything is modeled to a nominal size; a 1" dia shaft fits nicely in a 1" hole. Once the concept is worked out I will tweak the geometry using direct modeling approach to introduce the proper amount of tolerance gaps where needed. I collect these modeling tweaks in a feature folder.
Also, I 3D print a lot of my models, as either an actual end use parts, or as a semi functional mock up. Because FDM 3D printers often over extrude material I will make further adjustments to the geometry that has critical fit features, or small features (<2 mm). I collect theses adjustments in a feature folder as well.
I do this so it is clear where the critical interfaces are, and to isolate the tweaks made to support 3D printing. If I need to change the design concept I want to be able to suppress all these geometry tweaks while making the change. Suppression/unsuppressing a folder would be a lot easier than expanding it, using Shift section the top and bottom entry, then RMB select Suppress/Unsuppress.
Feature folder suppression could be something that be can added to part configurations.
2
Answers
I very much agree that this would be useful functionality!
The answer to your question about why we did not release this with feature folders is the same as all other similar questions: When releasing new functionality, we aim to release the MVP (Minimum Viable Product), collect feedback, and then make improvements.
There are a number of design considerations here that would have slowed down the release of feature folders. The main one I can think of is as follows:
- I create a folder with a number of features inside of it. Some of these features are suppressed, and some are active.
- I suppress the folder, now all of the features inside of it are suppressed.
- I unsuppress the folder. Now what happens? Do all of the features become unsuppressed? Do only the features that were previously unsuppressed become unsuppressed?
I suspect that a majority of users would like the second case. But, for the users who would like the first case, folder suppression would be more of a shortcut to suppressing/unsuppressing all of the features, rather than a true suppression state. Additionally, if we were to go with the first case, the suppression would not be configurable because a configuration would not be deterministic. An example of what I mean: Folder A contains features 1, 2, and 3. I am currently in config alpha, which keeps folder A unsuppressed. I suppress feature 2. I switch to config beta, which suppresses folder A. I switch back to config alpha, which unsuppresses folder A. Now feature 2 is unsuppressed again, meaning that something the configuration is not supposed to control has changed, meaning config alpha is unstable (not deterministic). (In other words, when I am in config alpha, then switch to beta, then back to alpha, everything needs to be exactly the same as before switching. This workflow violates that condition.)So, it seems the second is more stable and correct (if we want feature folder suppression to be configurable, and not just a shortcut to suppress/unsuppress all the features in a folder). So, if we go with that, now there has to be a new concept of whether a feature is "suppressed by feature" or "suppressed by folder" or potentially both. Does "suppressed by folder" have a different piece of UI? Maybe the strikethough is grey instead of black? Is this color choice high contrast enough for accessibility purposes? If a feature has both kinds of suppression, do we represent it with two strikethroughs instead of one? If I right click on a feature inside of a suppressed folder, do I still have the ability to "supressed by feature" state of that feature? If that suppression state just adds or removes an additional strikethough, will the user be confused about what is happening? Maybe we would need to change the wording of the right click dialog, or not allow this operation at all. Etc, etc, etc. All of these questions need to be iterated on, then user tested, changed in response to the user testing, and then user tested again. The client needs a bunch of UI changes and the server and database need plumbing for a new suppression concept, and configurations needs to understand how to work with it.
My point is, if we go down every rabbit hole we see, we would never release any functionality. So instead, we release when we have something useful, collect feedback, and constantly improve. Go agile!
Let me know if you have feedback on any of the above questions! As you can tell, folder suppression is something we've been mulling over and any additional feedback would be very useful.
- Jake
Owen S.
Kidding, mostly.
HWM-Water Ltd
For the benefit of the user, a suppressed featured count should be added next to the feature count for the folder.
For example...
Now for my idea regarding making Feature Folder Suppression" configurable...
When I mentioned the possibility of supporting "Feature Folder" suppression as a configurable feature I knew it would require additional thought and it would raise interesting questions.
My initial thought for suggesting adding Feature Folder Suppression as a configurable feature has a lot to do with my current use of Part Configurations. I find that my usage requires suppressing a lot features which greatly increases the configuration table horizontally. Being able to "group" blocks of features in a Feature Folder and then add just the Feature Folder for suppression to the part configuration would reduce the size/complexity of the configuration table.
I realizing I am using Part Configurations in a manner different from what it was originally intended. I do not use it to create families of parts that have just a few parameters that vary. I am more likely to use Part Configurations for reengineering activity where I want to capture the original "As-Built" design as one configuration and changes made to "improve" the design and an "Improved" configuration. For this reason, the entire concept of make Feature Folder Suppression (if it existed) configurable should be rejected. (Maybe I should be use versioning, branches, and version compare, but using configurations gives me a much finer control of documenting the changes.)
After giving it some additional thought, the "Feature Folder" is a lousy grouping mechanism and should not be a configurable item. Feature Folders should be all about compressing the length of the Feature List to improve the user's efficiency working the feature list.
What is needed is something completely different, something that does not depend on the features being grouped linearly in the Part Studio's feature list. Even then many of @Jake_Rosenfeld points about non deterministic configurations are still valid. My gut feel is there is a workable solution, but this forum is not place to iron out the feasibility of it.
IR for AS/NZS 1100
I think we're nearly there with "labels". If we tag a feature with a label we then set suppression state of anything with the appropriate tag. Doesn't matter where they are in the tree then. They're also be searchable. We could also choose to put them in a standard folder if we wished.
This is only useful go suppression not input parameters though.
Idea 2
The concept of "suppression only" folders. The items within cannot be individually or manually suppressed, a config may either turn them all on, or turn them all off. Stability resumed, but has limited functionality. I still kinda like it though, even if it were only a stepping stone to something else.
Idea 3. Half baked idea of revising the search functionality to make something a bit like featurescript queries. You then have a suppression method built around queries rather than user clicks.
Cheers, Owen.
HWM-Water Ltd
Your question as why I did not use OS "Branching" deserves a response. I have had to rethink what branching is and to reconsider using it in my workflow.
When I started using OS I experimented with branching a little, but set it aside because branching was a foreign concept to me and my understanding of what it was intended for did not fit my workflow. I do not think I am unique in this respect; I bet branching is not utilized as much as it should be for that reason. It is my understanding OS is the first MCAD product to offer this capability, therefore, it is a foreign concept to anyone experienced in other MCAD tools. It is a capability that does not have established usage in a typical MCAD workflow, therefore it it not leveraged.
As a single individual working a design I thought branching could be used as a way to go off on tangents to explore different design approaches, but I found simple versioning works just as well.
It was my understanding that branching was intended as a collaboration tool allowing multiple people to work on a design within the same OS document, where the individual contributions would be eventually consolidated into the final design. I am a 1 man show so there is minimal collaboration going on. I guess the biggest reason I do not use it is because the work done in branches is "hidden". When I open a OS doc it isn't immediately clear as to whether the doc has branches and how many. When I am working a design that has multiple design variants I found that using Folders, multiple tabs, part/assy configurations are a much more obvious way of communicating what is taking place in the document.
As I said, I will revisit using branching. Based on my workflow I will attempt to use branches to represent various states of a design with different geometric states, for example, geometric differences that are driven by redesign of an As-Is condition to correct a design flaw, or geometric differences attributed to refactoring the design to accommodate changes in either material, or manufacturing processes.
Here is an example of a document I used (to make a small keychain of a chef's knife) where I had to branch for different manufacturing processes:
After doing a few test prints, I found that I wanted to test with medium and small clearances at the same time, so I branched off and made those changes in separate branches, and did those two tests at the same time. Then, I wanted to print it using metal, and had to make additional changes. Branching here helped me keep the original design intent of the finalized design "Third Print", while making adjustments for the manufacturing process "Med Clearances", "Low Clearances", and "Metal print" branches.
Since these branches can have any number of versions on them, and act in parallel, you can imagine that it would be very helpful if I had three entirely different manufacturing processes (let's say 3d print, cast, and machined), and needed to do design iterations for all three. Instead of having a mess of part studios with no associativity, or a bunch of versions for three unrelated concepts along the "Main" branch, I could be separately iterating on the design for all three manufacturing processes in an organized, contained manner; creating versions as checkpoints on each branch as I go.
Here is the link for that doc: https://cad.onshape.com/documents/ec4d9c75a4f6b2b6741f2799/w/ce408aac3197e266c0b46523/e/2a1630ebfa945ac5703a4289
If you wanted to do that, you would make the change on the "Main" branch, and then merge "Main" into all of the branches which you wanted to consume that change.
https://cad.onshape.com/help/Content/merge.htm
Thank you for your response. Indeed we find that we have to convince experienced CAD users one-by-one to test-drive branching. Please do not hesitate to ask for help if branches don't work as you expect them.
@lana
This is indeed pretty amazing.
@Jake_Rosenfeld I couldn't get your knife design intent to hold together well enough to try this (merging changes in Master into Branches) but did a simple model of my own to test.
Amazing.
This is an area that will take a while to understand and to use effectively.
Glad to see your elaboration on "why not" from 2019. Here's my feedback.
My use of folders is:
- to group similar steps, essentially making them look like a one step (sample: "main frame")
- sometimes configuring such steps in/out in an all-or-nothing manner
I can see the mixed use case useful if some of the internal steps are exploratory, i.e. suppression used for commenting out. This is the second way of suppression I use. This brings (grant me slack here - just describing my workflows) use cases to three:
1. Working on individual steps (main level or within folders that aren't suppressed); both "comment out" and configured suppression works as now.
2. "Commenting out" a folder. This is the first (simple) case you wrote about in 2019. I'd be okay with:
- If there are both suppressed and unsuppressed steps within such folder, a warning dialog to be presented. If I agree, all steps within the folder would lose their suppression status and the folder becomes the entity that is suppressed.
- If there are configured suppressed steps under the folder, I would simply give an error dialog and refuse to proceed. Needs manual decision making.
The folder is now the suppressed entity. I can configure its suppression as a one thing. Thus - less columns in the configuration table. Yay!
Even in this "simple" way, there are more details to be listed (won't do them here; I think the above reasoning allows them to be derived, so that the behaviour remains compatible with existing functionality, internally coherent, while allowing for yet better organization of the steps.
---
Interestingly, how @StephenG (OP) turns away from his idea:
What is needed is something completely different, something that does not depend on the features being grouped linearly in the Part Studio's feature list. Even then many of @Jake_Rosenfeld points about non deterministic configurations are still valid. My gut feel is there is a workable solution, but this forum is not place to iron out the feasibility of it.
I am certainly happy to engage on this in a detailed fashion elsewhere, but as it now stands, this is the forum I have access to.
The reason-of-existance of suppressing/configuring feature folders to me are:
- internal consistency
- ability to be keep configuration tables short (something mentioned by @StephenG as well)