My team has been working on revising our part naming system and I’ve had a couple questions CD can hopefully clear up:
What’s the difference between a revision and a version? Could you provide an example with a common FRC application? (I looked this up and just got more confused.)
When people create a CAD, there’s often a lot of messing around before there’s something solidified. When does an assembly/part get a number and when do you change that number? Is it just a ton of tacking on revisions/versions? (Obviously in the context of your team.)
Say your re-use your 2022 drivetrain in your 2023 season. Do you give it the same name (by renaming the original to exclude year)? Say your re-do the gearboxes but the bellypan is the same. Does the bellypan have the 2022 year in the name or the 2023 year?
Full disclosure - I’ve never done this for CAD, only software. But I think there’s a lot that is the same between the two.
Simple answer - it means whatever you want them to mean!
Traditionally, “revision” implies some internal tracking system - something your company would use inside to track the smaller iteration cycles. “Version” is external facing - slower-paced, larger updates that an end user would care about. Many Revisions happen before a new Version comes out.
However - in FRC - your team is both the “internal” and “external” customer. So making a distinction between the two might not be meaningful.
Similar answer - whenever you want it to!
Traditionally, the intent of putting down a new version is to communicate to another person that a certain quantity of work has been completed, and (with well-known caveats) your work is ready to be taken up by another person and used.
For example, if your team is divided up such that CAD team designs a part, then makes a drawing, and walks it down to someone in the mechanical area to make… it would be a good idea for CAD to ensure there’s a unique number on every drawing it sends for fabrication, just so you can uniquely identify each physical part that gets made.
Again though - it’s just a form of communication. If you’ve got only a few people on the team, or the same people are doing both fabrication and CAD… a rigorous process might not make much sense.
For most FRC teams, at a minimum, I’d recommend marking each revision of hardware that makes it on a robot. Again, just to ensure that if you remember “oh yea the last part we made was better than this one”, you can get back to re-make that last part easily.
This is a question of “clone and own”, or make a true “common library”.
For most FRC applications, I’m a fan of clone and own. It’s rare-to-never that we want to make design updates to old robots, so it’s not important that if we improve this year’s robot, the old one gets the update too. Furthermore, we only want to be thinking about one year’s robot at a time, and don’t want to consider how changing this year’s robot might impact a common design from a previous year (because… in the context of the season… it doesn’t matter).
Because of this, we clone-and-own content forward each year. That is to say, anything from last year that will be reused gets copied forward and renamed. We treat it as though we had designed it from scratch that year.
Other teams (971 comes to mind) have a different philosophy on how they keep their software up to date, and as a result have a different process.
All of these questions are really about “process” - the steps you as a team collectively decide to take to ensure good communication during the design and build process. Note that processes only exist because humans are forgetful. If everyone on the team was infinitely good at communicating and remembering, all the necessary information would always just be known, and no one would need a process to remind them what to do. Processes come into play because people either forget necessary steps (even the best of us do!) or because the team is so big that you can’t rely on people to “just happen to get it right usually”. Processes come with overhead, though. If you have lots of extra steps in your process, it takes up valuable time doing work which ultimately doesn’t help the team.
As you research processes online, keep in mind a lot of them are written for industries and team sizes which are very different than FRC teams. Read them for the intent of what the process covers, not for the literal steps they indicate. Build and form a process specific to your team which takes the best ideas, and blends them in a way that helps you remove your own internal pain points.
That external/internal differentiation helped clear stuff up, thanks. I guess for our team (we have about 60 members total, 5-ish doing CAD, maybe 15+ on manufacturing) it wouldn’t make sense to have Revisions for CADders and Versions for manufacturing drawings because of team size (we’re a large team, but not that big).
Haha, I didn’t think of this before. I never really used revisions but that certainly helps explain their purpose.
We have a common parts library, but that’s for COTs stuff (and some few things like box tube extrusions).
This is an interesting approach, but the more I think about it, the easier it sounds: no mixing years. It’s not like we need to remember when the part was designed in the part name, anyways – older members/mentors can.
Thanks again for all your comments. I’ll still leave this thread open in case someone has other views/processes.
Lot’s of great advice in this thread already and if you were wondering about or tempted to put part numbers on the actual physical part and track those different parts there is some good advice on the Internet for example: is it a new part or a revision?
A quick example that is almost but not quite realistic is you make a part numbered 1001 and it’s some color, say yellow" because the usage needs a light color (maybe you’re shining a sensor at it).
You run out of yellow material and substitute “white.” You really should update the drawing and change the reference from yellow to white. The part still works great - it’s light colored. The white version is called part number 1001 rev A.
You want more parts and can’t find any material except black. (You soon find out that) Black doesn’t work in the application so it isn’t part number 1001 anymore - it’s part number 1002. (Sorry this is slightly contrived and I know you’d now document on the drawing the part is supposed to be light-colored and black doesn’t work and you’d toss out the bad part without giving it the respect of a new number.)
What’s the difference between a revision and a version?
Whatever your team defines it to be. Define versioning terms internally and have everyone use them for consistency.
When does an assembly/part get a number and when do you change that number?
I’ve mainly done programming so I’m thinking in code terms here, but this seems like the difference between saves and commits. You can save code many times, but you only commit once you want to have a new version to go back to from the future. Translating this to CAD, I’d expect to save parts often, but only increment the version of the part once it’s ready to update the part in whichever assembly it is a part of.
Say your re-use your 2022 drivetrain in your 2023 season. Do you give it the same name?
I’d keep separate directories for each year’s CAD and copy a file from the old year to the new year without keeping the year in filenames. That way all the latest CAD is in one place and you can go back and see how the CAD was in previous years. You could go as far as making the old years’ directories read-only if you want to keep history over updating old parts.
Again pulling from programming, I’m a huge fan of Semantic Versioning. Each version is MAJOR.MINOR.PATCH, where each of those three is a whole number (e.g. 2.9.0).
Using this system guarantees that each version gets a unique name as well as having the version number indicate whether the new part is backwards-compatible with the old part (“drop-in replacement” / same MAJOR version) or whether it breaks backwards compatibility and requires other parts to be redesigned as well (higher MAJOR version). Using the MINOR and PATCH fields accurately also shows whether the changes are fixes (PATCH) or new additions (MINOR).
Another advantage of semantic versioning is that it helps give an easy-to-communicate name to versions (“part two point nine point zero” is easier to remember for me than “part one thousand twenty two”). The name also indicates how many revisions a part has gone through, both for MAJOR changes and MINOR changes within each MAJOR version.
The final advantage is that you can specify just the MAJOR version for assemblies (and use the latest version under that MAJOR version), since MINOR and PATCH versions must be compatible per the semantic versioning spec.
For anyone who’s wondering what our part naming is now:
I like the a.b.c version as well, but it isn’t as practical from a CAD standpoint: we’re going to use a similar version of 254’s take (which 1678 also uses).
It’s a little better optimized for CAD/manufacturing tasks, though reading the names gets tedious as your pointed out.
A revision is an interation on the same part. Say you change a part length, add extra holes, ect. Those are revisions on the original part.
A version is generally more of interation on the assembly as a whole. Think like making a new shooter where you add new features like a moving hood or hood rollers. Enough about the assembly is different that it warrants its own unique assembly, and thus a unique set of part names.
Neither of these are strictly necessary for FRC, it’ll depend on your workflow.
We generally know the part naming scheme for each subassembly ahead of time. My team designs parts using the Mastersketch workflow, which is a top down workflow where we design the subsystem as whole starting with critical geometry (intake ex; compression, rough roller positions, placement inside/outside frame perimeter) and then we continue adding complexity until individual parts are designed all through a series of layered sketches.
It is only until the Mastersketch is mostly done that we start creating individual 3D parts derived from the Mastersketch and then we track and name those parts at that time. So sometimes a week can go by before a single part is created and named for a given subassembly.
If a custom part/assmebly is used on the 2023 robot, it will have a 2023 part name, so in the scenario you describe the 2022 drivetrain parts would be copied into the 2023 folder and renamed (we’d do this work before the season starts sometime in December).
Many companies use a combination of letter and numbers for their CAD files. A couple of our customers use # numbered revisions until the drawings are finalized. So we’ll have drawing revisions for 30%, 60%, 90% at Revs 0, 1, 2 and so on, as many are as needed, and when the drawings are issued for manufacturing, they switch to a lettered Rev, A. Any revisions thereafter are lettered Revs, and if it’s an upgrade to the system, they’ll go say Rev A1, A2 and so on, and then at the completion of the project, it will get bumped to the next letter. Rev. B.
I don’t think semantic versioning and cheesy naming are mutually exclusive. Cheesy naming is for giving each part a consistent name while semantic versioning is to give each part a visible version number/history. Semantic versioning is useless on its own—“version 2.3.0”… of what? “climber spring assembly version 2.3.0”… oh! Replace the name with whichever naming system you team likes best and now you get both consistent names and a record of part versions over time.
Yeah, I think we’ll tack on versions/revisions onto the end of the Poof’s existing style via “-version.revision” (we probably won’t need a CAD-corresponding patch number.)
Sorry; I don’t think I explained this clearly – we’ll have both part numbers and versioning.
