can a feature read a version number?

EvanReese

I'm kicking around an idea for a feature that labels parts with metadata, which I'd use to keep track of prototype iterations. One of the main bits of info that would be nice to automatically fill is the version number. Is there a way I can read it with FS and convert it to a string? I'm guessing no, for stability reasons, but does anybody have a trick? Another one that I doubt is possible for the same reason would be the date. Any ideas?

Yes, I realize I can set up a variable, and configure the text to make it change lots of places, but setting it up is more work than telling myself I'll use a sharpie, then not labeling the 3D print at all. I am interested in making it frictionless enough to use and more importantly, get a whole team to use.

ilya_baran

This is impossible by design: keep in mind that we want geometry in a version to be fixed.  The version name can change.  So if FS could read the version name, it would mean that you could change what's in the version just by renaming it, which would be undesirable.  (This is also why regenerating FS can't read metadata).  I don't think you could automate this with FS.

tim_hess427

I think this would be awesome, but I seem to remember some discussion around similar things in the past that weren't promising. You're essentially trying to have a features that's evaluated after the version is created right? Otherwise, you have a feature that's evaluated inside of a workspace that, by definition, is not a version. 

Even if you had something that could look at the previous version and assume the current version is the next value from a list (eg. the last version in history is 5, so the current version must be a draft of version 6), I don't know if that would still work when you start branching, merging, and restoring versions. Seems like you run into some time travel paradoxes or something. 

I think it would have to work like revisions and revisions tables, where the table shows the the next revision in your scheme with an asterisk and "in progress" watermark. But, that seems like it all operates at a higher level somewhere. 

I know this doesn't probably doesn't add much value to the conversation, but I do think it would be awesome functionality to work in at some point. If drawings can do it with Revision data, it shouldn't be impossible with the part studios...  ¯\_(ツ)_/¯

ilya_baran

This is impossible by design: keep in mind that we want geometry in a version to be fixed.  The version name can change.  So if FS could read the version name, it would mean that you could change what's in the version just by renaming it, which would be undesirable.  (This is also why regenerating FS can't read metadata).  I don't think you could automate this with FS.

EvanReese

@ilya_baran
I thought that was the case. Thanks for confirming.

tim_hess427

@ilya_baran - Do you think there will ever be a day that it would be possible to treat some properties and geometry the similarly to a revision property? I'm sure it wouldn't be easy, but conceptually, the revision of a document seems like a property that is assigned and fixed at the time the version is created (and the revision listed on a drawing can be updated and fixed at that time). It doesn't seem impossible that 3D data could be handled in a similar manner. 

In a future world, where 2D paper drawings are less relevant, and manufacturing uses MBD, digital twins, and automated part serialization at the time of manufacturing, wouldn't it make sense to allow for something in the 3D model to be treated the same way as the revision level is treated on a drawing? 

kenn_sebesta167

I think @tim_hess427 and @Evan_Reese are onto something here. Expecting the human to do a mechanical click-based action every time before printing/manufacturing is the opposite of what we expect from automation. It is hugely beneficial to automatically embed a git hash and clean/dirty descriptor in any program which gets generated. Likewise, the ability to pick up a part and be able to know its exact provenance is equally beneficial. Esp. in the day and age of 3D printing where dimensions are as squishy as the material. Good luck measuring a printed part to 100um of accuracy.

A couple thoughts on how this could be done:

1) Just like a timestamp in a git commit, this information is added after the fact but is still a critical part of the file descriptor. Some sort of scaffold could be integrated to allow this.
2) The feature could be generated as part of an export, much like a pre-compiler reading the git hash and substituting it for a text string in the source code, before compiling.

In general, I can see how this is a bit of a delicate issue because the manufacture of the part could actually lead to different part performance. No one wants to track a failed part back to a crack propagating from the letter `I` which has sharper edges than the previous `O`. Still, this is a rare occurrence, and one the designer is responsible for. Much more common is to find a part which fits and to know you want to reproduce that exact part, but struggle to find the original version number.