Configurable rollback bar

brooke_spreen

We sometimes use configurations for demonstrating different steps in the manufacturing process. Rather than suppressing/unsuppressing all of these features by hand, it would be super convenient to have a type of configuration which controls rollback bar placement in the feature tree.

As an example, in the pic below, the "Name" column would be followed by "Rollback Bar Position", where features could be selected from a drop-down menu. For each configuration, the rollback bar would be placed directly before (or after?) the selected feature.

What do y'all think? Useful?

lougallo

@brooke_spreen The roll back bar is not really something configurations should control.  Configurations should be a state of the full featurelist and a rolled back state is typically not going to work especially if a featurelist is versioned in a roll back state.

matthew_stacy

@brooke_spreen I like the idea.  I can definitely envision applications where rollback configurations would be useful.  For example it would be a great way to walk a client through a fabrication or assembly sequence in a link-shared, view-only document.

@lougallo are there technical considerations that would make this difficult to implement?

brooke_spreen

@lougallo, I don't quite follow the logic of why configurations should not control the rollback bar (is this a technological or philosophical concern?), but perhaps the same functionality could be reached through a suppression shortcut....instead of the suggested column "Rollback Position" there would be an option for "Suppress all features after:"....does this make a difference?

john_mcclary

Rollback bar is an assist tool to prevent computation of the tree where you don't need it while editing.

It is bad practice to leave the rollback bar anywhere other than the bottom of the tree once you leave a studio. As some parts come and go in and out of existence based off later features consuming or re-defining them. (example: boolean-union will absorb all bodies and combine the result into the first selected part in list)

a more technical concern will be for those who use release management. Onshape will not let you release a part if its part studio's rollback bar is not at the bottom of the tree.

If you have assemblies and you roll back a part. You would likely be removing faces/edges that were used during mating. Rolling bar affects the final state of every part in the studio even in assemblies or derived parts.

So roll back is far to sensitive to be used willy-nilly. Something like this would be nice for people like us who would know the intended purpose, but can be too easy to misuse for all of the people who don't first understand everything I wrote before this line without question. Especially if they didn't read up on when to use this niche feature and take a guess at what they think it should do. I would bet to see many support tickets and forum posts with confused users.

On another note, your tree may end up working out linearly for your projects. But I find it more of a hassle if you need to sort your tree based off of manufacturing steps  rather than efficient modeling practices. Especially if you need to change the order of operations in machining, your part and child assemblies may end up needing a whole refactor. (Yikes!)

Suppressing features independently is a much safer and understandable practice. If anything I would ask for more efficient ways to manage the config tables. Currently I find them a little too large, I tend to do a lot of scrolling or copy/paste into googlesheets.