Welcome to the Onshape forum! Ask questions and join in the discussions about everything Onshape.

First time visiting? Here are some places to start:
  1. Looking for a certain topic? Check out the categories filter or use Search (upper right).
  2. Need support? Ask a question to our Community Support category.
  3. Please submit support tickets for bugs but you can request improvements in the Product Feedback category.
  4. 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.

Configured properties can be changed later in old versions? It should not be possible!?

René_SartorioRené_Sartorio Member Posts: 44 PRO
How can it be that configured properties can be changed later in old versions? 

Example where I noticed it:
An assembly with a drawing.
Part A from library directory.
Part B (distance hexagon V6) from library directory.

Part B (distance hexagon V6) has a wrong surface. 
I noticed this on the parts list of the drawing. 
I open part B (distance hexagon V6) from the assembly.
I correct the surface in V6 of part B (distance hexagon V6)

The problem is that I can' t update the assembly or the drawing because it is not a new version. 

If you now change part A to get a new version, you have to update the assembly and the drawing. 

Now the change is also visible in the parts list of part B (distance hexagon V6).

It should not be possible to change the properties afterwards, right?
This change is not documented anywhere. 

Do I have a mistake in thinking?


Best Answer

  • eric_pestyeric_pesty Member Posts: 423 PRO
    Answer ✓
    Hey @S1mon
    I have read your post.
    Where can I find these settings ? 
    We have Onshape Professional. 

    "edit value in workspace" This is the only right way
    A version has to be complete static. Not only the geometry.
    There are legitimate reasons to want these to be editable in versions but if you want everything to be absolutely 100% locked down then you only want to check "edit in workspace".

    There are checkboxes for each property setting in the "company settings" for professional:



Answers

  • S1monS1mon Member Posts: 985 PRO
    See this discussion. It depends on how your enterprise is set up.
  • René_SartorioRené_Sartorio Member Posts: 44 PRO
    Hey @S1mon
    I have read your post.
    Where can I find these settings ? 
    We have Onshape Professional. 

    "edit value in workspace" This is the only right way
    A version has to be complete static. Not only the geometry.
  • S1monS1mon Member Posts: 985 PRO
    @René_Sartorio

    They are in Enterprise for custom properties. I don't think they exist as options in Professional, so I'm not sure what's happening for you.

    In our case, what I really want is a way to edit the workspace values, but at the assembly level BOM so I can see the properties all together. Without combining documents, and using non-versioned instances, I don't think there's a way to do this.
  • eric_pestyeric_pesty Member Posts: 423 PRO
    Answer ✓
    Hey @S1mon
    I have read your post.
    Where can I find these settings ? 
    We have Onshape Professional. 

    "edit value in workspace" This is the only right way
    A version has to be complete static. Not only the geometry.
    There are legitimate reasons to want these to be editable in versions but if you want everything to be absolutely 100% locked down then you only want to check "edit in workspace".

    There are checkboxes for each property setting in the "company settings" for professional:



  • René_SartorioRené_Sartorio Member Posts: 44 PRO
    @NeilCooke can you confirm that professional onshape users have both settings active?

    Edit value in version
    Edit value in workspace
  • NeilCookeNeilCooke Moderator, Onshape Employees Posts: 4,369
    @René_Sartorio yes both those options are available but each property will have different settings
    Director, Technical Services, EMEAI
  • René_SartorioRené_Sartorio Member Posts: 44 PRO
    yes but the possibility to activate or deactivate them is only available for enterpise users.
  • NeilCookeNeilCooke Moderator, Onshape Employees Posts: 4,369
    yes but the possibility to activate or deactivate them is only available for enterpise users.
    Pro and Enterprise are the same in this respect. Any built-in properties (with the "On" icon) cannot be changed, only new custom properties can set these values.
    Director, Technical Services, EMEAI
  • René_SartorioRené_Sartorio Member Posts: 44 PRO
    Thanks a lot 
    Now I understand
  • billy2billy2 Member, OS Professional, Mentor, Developers, User Group Leader Posts: 1,835 PRO
    It's more than properties. Versions do not lock down configurations. You can change a configuration value after it's been versioned. When you version a document that has a configuration, it's best to note what the configuration variables values were otherwise you won't know what the values were set at when the document was versioned.

    Another oddity is that when branching a document that has configurations, it applies the default values of the configurations. Infact, any creation of a new instance of a document that has configurations will be created from the configuration default values and not the current values.

    I'm not sure if this is right or wrong.

    In the beginning of OS a version was an immutable state. I'm not sure that's true any longer.


  • eric_pestyeric_pesty Member Posts: 423 PRO
    billy2 said:
    It's more than properties. Versions do not lock down configurations. You can change a configuration value after it's been versioned. When you version a document that has a configuration, it's best to note what the configuration variables values were otherwise you won't know what the values were set at when the document was versioned.

    Another oddity is that when branching a document that has configurations, it applies the default values of the configurations. Infact, any creation of a new instance of a document that has configurations will be created from the configuration default values and not the current values.

    I'm not sure if this is right or wrong.

    In the beginning of OS a version was an immutable state. I'm not sure that's true any longer.


    Configurations are by definition a "variable": you can switch configuration on the fly in a read only document so it wouldn't make sense to "lock it down". Default values are as the name implies what it will revert to displaying in absence of you switching to a specific configuration so that's why when you insert a configured part of an assembly it will "default' to the default configuration, same if you create a branch of it.

    When you create a version of something that uses a configured component it does lock it down (eg: inserting a configurable part into an assembly, that version of the assembly will always refer to the same configuration of the part.

    If you want truly immutable, you have to do a release, which does lock everything down (including metadata) and applies to specific configurations independently, unlike versions.
  • billy2billy2 Member, OS Professional, Mentor, Developers, User Group Leader Posts: 1,835 PRO
    edited September 10
    @eric_pesty that all makes sense. I played around with it again with your ideas:

    after versioning:


    the same configurable part:


    If you insert a new instance, it's the default. If you copy n paste an instance, it's a copy of what you copied. I can live with that.

    I released a block and inserted it back into the assembly and it's immutable:



    Since versions are documents and version aren't immutable, then versioned documents are mutable?
    Parts are released and immutable.

    Are released assy immutable?



    Doesn't look like it but I think I've made a mistake.

    What I desire is a top level assy in an immutable state. I think releasing an assy with parts not released is problematic. I've made this mistake in the past. I need to work on this some more, possibly read the manual again.

    A long time ago, an immutable state in OS was easy to achieve. It probably still is and I just need to figure it out.

    I like your reasoning with configs being mutable. When I stick a version on my website, users can still make changes to the configuration. This means I can point to a version from my site and others can change it.

    We still need an immutable state. I haven't achieved it yet now that we can release stuff. It's my fault. I'm going to see if I can get this top assy in an immutable state, properties and all. 






  • billy2billy2 Member, OS Professional, Mentor, Developers, User Group Leader Posts: 1,835 PRO
    edited September 10


    I have all released parts & assy in top and it's released. I added a released assy into the test assy and a part in top moved. It's mutating. I guess I don't know how to make a non-mutating assembly.


    Fixed & grouped everything in top assy and released.


    I have updated test assy and things seem to have stopped mutating. Maybe I've figured it out.

    I'm usually not driving manufacturing any longer and tend to do 1 off stuff. I'm going to look for examples of projects being released locking all into a immutable state. I might read the documentation again and see if they have more about this subject. Anyone with a project example showing this off? @adrian_vlzkz did you ever figure it out?


  • eric_pestyeric_pesty Member Posts: 423 PRO
    @billy2
    Not sure what you mean by your assembly "mutating" but one thing to consider is that if your assembly has any degrees of freedom these are free to move in a released assembly, and that is by design as assemblies must be able to represent motion! So I wonder if that's what you are seeing...

    For example if you model a hinge with a revolute mate it can still (and needs to be able to!) move when released. Onshape also lest degrees of freedom carry through the assembly levels so if your sub-assembly has any degrees of freedom you will still be able to move these from a higher level.

    If you want to show it in a specific position you can create a "named" position, or a configuration where a mate stops the rotation from happening.

    If you don't want anything to be able to move you have to make sure everything is fully constrained (fastened/grouped, with at least one component fixed from your top level). One more thing to be aware off: you can't mate something to the origin of an assembly directly as this will still move in higher levels (because the origin doesn't exist at higher levels), this one is kind of weird...

    Also note that if you have an assembly and you release a part, the current workspace of the assembly won't automatically switch to using the released part, you have to manually set it to use the released version.

    What you can do is release the assembly, and this will include any unreleased child components so these will all get released at the same time (rather than releasing parts individually first). This even works if your parts are in different documents (i.e. a release can span multiple documents).
  • billy2billy2 Member, OS Professional, Mentor, Developers, User Group Leader Posts: 1,835 PRO
    edited September 11
    @eric_pesty you bring up a good point about assembly motion. In my mind, your complaints, they're bugs and need to be fixed. I'm still not comfortable with releasing and need to understand it better. Every engineer will have to master it to successfully control a project. Do you think it's easy enough for everyone, casual users, to use it effectively?

    If you're developing a medical product you have to show the milestones when developing a new product. Many industries have to show stages in a development environment. These stages need to be immutable and not be allowed to change. It's important.

    A long, long, long time ago we sold pro/pdm to abbott to control all the files created by a parametric modeling system (pro/e). Abbott asked the FDA how to validate pro/pdm? It was a simple explanation, just make sure you retrieve what you submitted. It can't mutate in the vault. It's a simple thing but these parametric systems allow change, they're difficult to lock down properly.

    Have you ever opened an old released project and had no idea what was going on?

    I think OS will be the 1st parametric system to do it correctly because it sits on top of a database vs. a file system. If you read the manual, the immutable state is a rolling lock down, the design continues even when there's a release candidate submitted.

    I'm rereading the manual and it's extensive with a lot of new concepts.

    From the manual "version are immutable":


    So we've both realized that a version can now mutate using configurations. A configuration is a variable? Ok, now what? I don't think versions are immutable. I'm trying to figure out how to lock down a design by releasing things.

    I flew across the country on 2 red-eyes to visit OS and discuss release management a few years ago, we spoke about everything other than release management and I'm not sure I get it yet. @adrian_vlzkz went to OS with me and is more involved in release management than I am. His problem is unique and I'm not sure other file based systems can control the permutations that he's trying to control. 

    I wish he'd share what he's learned about this topic, he's quite good at it.

    Here I am again trying to figure it out. All cad systems must be able to create an immutable state. What are we building today? Manufacturing has to build things that are immutable. Often it's not true but we try.





  • billy2billy2 Member, OS Professional, Mentor, Developers, User Group Leader Posts: 1,835 PRO
    edited September 11
    https://cad.onshape.com/help/Content/release_management.htm?Highlight=release

    It never talks about a released candidate as immutable, they say the version is immutable. Are we wrong?

    OS can you please clarify?


  • billy2billy2 Member, OS Professional, Mentor, Developers, User Group Leader Posts: 1,835 PRO

    If you're using a mixed-mesh environment you'll need to allow errors in your releases because you can't get rid of an open mesh error. 

    What other conditions are you using?

  • eric_pestyeric_pesty Member Posts: 423 PRO
    billy2 said:

    So we've both realized that a version can now mutate using configurations. A configuration is a variable? Ok, now what? I don't think versions are immutable. I'm trying to figure out how to lock down a design by releasing things.

    I think maybe it depends what you mean/expect by "immutable".
    Think of it that way: the set of available configurations and resulting geometry that can be produced ARE immutable in a version (i.e. you cannot add a new configuration after the fact, or change any of the value limits etc...). The same can be said of the degrees of motion and "content" of an assembly.

    So basically what you can do with it (switch configurations, move parts) when you create the version cannot change after the fact. Some of the metadata attached may be able to change depending on the your settings (as is required for certain workflows) but the available set of geometry cannot change. 

    Configurations are currently required to each have a unique part number in order to be released (we actually have several examples where we would prefer to have a single part number for several configurations but that's another story...) once you release a specific configuration of something, it is truly immutable, with the exception of any allowed degrees of freedom within an assembly (i.e. if you don't want anything to be able to able to move it's up to to you to ensure everything is constrained properly before releasing it).
    Even then, anytime you pull up a released version of an assembly, I believe it will show up with the degrees of freedom in the same starting position. 

    The good thing too is that because there is a "single source of truth" you can't "fake it". In SolidWorks PDM you can open a released drawing from the vault and modify a part (even if you can't save) and print a paper copy and you would have no way to tell is different from the release, and this can happen accidentally fairly easily. You literally can't do this using Onshape, definitely not accidentally.

    I haven't been using Onshape for that long but so far everytime I have pulled up something "old" it was exactly like it was left at the time. Unlike in SW where if you open something you haven't touched for a couple years, there is a pretty good chance you'll encounter some errors that weren't there at the time... (mind this can also happen with something you opened the day before...)

    The one thing that is missing right now is that it can be hard to tell if something is under-constrained as there is no visual feedback. It would be nice to have a "report" showing everything that can move so that you can check that you don't have any unexpected allowed motion.


  • billy2billy2 Member, OS Professional, Mentor, Developers, User Group Leader Posts: 1,835 PRO
    @eric_pesty

    I like your 1st  answer better.

    Immutable= it did not mutate.

    Changing a configuration variable changes the geometry= it mutates. 

    SW with epdm is not immutable. They force rebuild everything coming out of the vault. Do you think a rebuilt model is the same as the original? Ok, maybe 1 update back, I'll give them that. Now check out something that's 5 updates back. That's 5 upgrades and then there's no errors and it's the same geometry? No way. I think today you should be required to have something better than epdm to store SW data or go back to saving step files like so many did back in the day.

    I've read the OS "release" manual again and it all seems to be there. It's complicated but it's well done. Just because I don't understand it doesn't mean it doesn't work. I'm going to start playing around with releasing again and trying to create an immutable state.


  • adrian_vlzkzadrian_vlzkz Member Posts: 177 PRO
    edited September 12
    billy2 said:


    From the manual "version are immutable":


    So we've both realized that a version can now mutate using configurations. A configuration is a variable? Ok, now what? I don't think versions are immutable. I'm trying to figure out how to lock down a design by releasing things.

    I flew across the country on 2 red-eyes to visit OS and discuss release management a few years ago, we spoke about everything other than release management and I'm not sure I get it yet. @adrian_vlzkz went to OS with me and is more involved in release management than I am. His problem is unique and I'm not sure other file based systems can control the permutations that he's trying to control. 

    I wish he'd share what he's learned about this topic, he's quite good at it.

    Here I am again trying to figure it out. All cad systems must be able to create an immutable state. What are we building today? Manufacturing has to build things that are immutable. Often it's not true but we try.





    I haven't explore Configurations in depth yet, but if it's true that you can configure (change) a component after a version is created thru Configurations, it is NOT GOOD... it completely goes against the concept of immutable state.

    My assumptions  (and hope) is that this "change" only happens in the read-only cache of opening a version, meaning if that Version is referenced in assemblies or drawings, it doesn't propagate there.
    Adrian V. | Onshape Ambassador
    CAD Engineering Manager
  • eric_pestyeric_pesty Member Posts: 423 PRO
    adrian_vlzkz said:

    I haven't explore Configurations in depth yet, but if it's true that you can configure (change) a component after a version is created thru Configurations, it is NOT GOOD... it completely goes against the concept of immutable state.

    My assumptions  (and hope) is that this "change" only happens in the read-only cache of opening a version, meaning if that Version is referenced in assemblies or drawings, it doesn't propagate there.
    There are many cases where the configurations represent "states" of the same thing so you need to be able to adjust configurations! 

    Don't confuse a version and a release, they are very different!

    A version is a snapshot in time of the document and that snapshot is immutable (except for any metadata specifically allowed to be changed). However if that document can produce a set of geometry through configurations (or degrees of freedom in assemblies), then that "set" is immutable, but you can still chose to view/use a specific configuration from that version.
    The usefulness of configurations would be severely limited if you could only use (for example insert in an assembly in another document) the configuration of the part was in when you created the version!

    However a release applies at the component level (i.e. part or assembly) and currently requires each released configuration (i.e. each unique permutation of configuration parameters) to have a unique part number.
    This is actually too restrictive for us as we do have several uses cases where something needs to have different "states" even though it is one part number. For example a wiring harness might be used in two places and needs to have a different "shape" in the assembly in order to look right but is only a single part number.
    Obviously if an assembly has degrees of freedom you can still drag things around in the released assembly (as should be the case) but it will always show in it's default starting position when you open it.


  • billy2billy2 Member, OS Professional, Mentor, Developers, User Group Leader Posts: 1,835 PRO
    @adrian_vlzkz great you're here.

    Without respect to configurations, have you got anywhere with releasing? I've heard good things. Seems like its coming together.


  • billy2billy2 Member, OS Professional, Mentor, Developers, User Group Leader Posts: 1,835 PRO
    edited September 13
    @eric_pesty I keep thinking and reading about releasing in OS. It's not easy and not sure it will ever be easy. I keep looking for a one-click release and I don't think it'll ever exist.

    Immutable is the wrong word for a version. John McEleney supposedly came up with immutable for the versions. But now with configurations, I'm not sure it's the right word to use for versions. I think staged is a better terminology for what's happening during a version. Release candidates come from versions and hopefully create an immutable state.

    High production companies need to track what was built with what down to the nut and bolt. Most will create a build list which is time consuming and often inaccurate. It'd be better to automate the process by tying it back to CAD.

    Having versions & releases on a build sheet is a question for quality control. They'd probably approve it if the procedure was documented. 

    I suspect many engineers just buy things and stick them together, myself, but larger companies need better control. At the end of any project, the immutable state is such a great state to achieve and we should all be working towards this goal. Ending a project properly isn't something most CAD systems achieve and there needs to be focus on this.


  • eric_pestyeric_pesty Member Posts: 423 PRO
    @billy2
    Fair enough, the "final release state" being locked down is definitely something to strive for. However you mention most CAD systems don't actually do it well so the industry knows how to work around the limitations. As far as "immutable" being the wrong word, sure... but once you understand what it means in this context it's not hard to understand so I wouldn't get too hung up on the semantics.

    If you are worried about configurations not being "immutable enough", there is a simple option: don't use them. Or in the case of a part, you can create a new part where you derive in a specific configuration of your "master" configurable model and use it in your assembly, now the geometry is immutable in the version. We do this quite a bit with family of parts that have configuration variables (i.e. "infinite" configurations) where you can effectively version the "master" and create specific sizes (or sub families of parts where one or more of the variables are locked down) without affecting the master model.

    As far as "one click release", the CAD system can't read your mind or know what your specific company workflows are so that doesn't seem like something that really achievable. Different companies will need different amounts of flexibility and the combination of versions and releases does a good job giving you options.

    The release candidate is also a great place to double check that you didn't mess something up as it's your last chance to change things before it becomes immutable so I'm not sure the "one click" option would be desirable.

    I'd rather have the software ask me something along the lines of: "hey dummy, are sure you want to release something called "Part1" with a blank description?"

    I guess my point is that while it's good to always push for improvement, there is always going to be a tradeoff between flexibility and "lock down ability" and I feel a lot more confident in my ability to go back and know what was done at a certain date in Onshape than in SW PDM (which is effectively the "standard" for smaller companies out there today)!
  • billy2billy2 Member, OS Professional, Mentor, Developers, User Group Leader Posts: 1,835 PRO
    edited September 13
    I think we're in agreement. Knowing what immutability was before releasing and configurations were added, it's hard to accept some lesser degree of immutability. 



    I spent 2 years designing this machine a few years back and it's only 25% of the total machine. There was a track drive, holder & tube loader equally as sophisticated. I don't have the other pieces and wish I'd spent a week cleaning up the project for archiving. I like the idea of immutability for a parametric model and think we should have had this concept a long time ago. Maybe I'd have the whole machine today if I spent the time to pack it up.
Sign In or Register to comment.