How to properly do dumb numbering for configs and multibody parts?

[laukejas]

I know this topic has been beaten to death, but I wanted to ask something very specific that has not been covered yet as far as I was able to find. I'm working without PDM for my personal/hobby/contracted projects, and I've recently abandoned descriptive file naming for semi-dumb numeric convention for physical products - a simple counter, for example A000150.SLDPRT, A000151.SLDASM, etc. This works great for basic stuff.

First consideration is part/assembly configurations - they make things a bit messy. If a part/assembly has multiple configs representing physical products, ideally I'd like to assign the next number in the counter. For example, if part file name is A000150.SLDPRT, then first/default config would also be A000150, second config would be A000151, etc. Unfortunately this makes tracking very difficult, since there is no real way of knowing that product A000151 is actually inside part file A000150.SLDPRT unless I store that info somewhere manually.

So instead I had to resort to naming configurations A000150-0, A000150-1, A000150-2, etc. Which avoids the traceability issue, but now the numbering is not as dumb as I want it to be, and it exposes the numbering logic to the drawings, which makes things more confusing. This is my first question - is there a way to avoid that second layer of numbering while still retaining traceability?

Second consideration is multibody parts, where each (unique) body represents a separate physical product and should have it's own number. These bodies may or may not be exported with Save Bodies/Insert Part/Insert into New Part to a separate file, but if they are, then the numbering inside multibody part should match the exported file names. The end goal is to have the same numbering convention for traditional assemblies and multibody parts, meaning they would appear the same on the drawing and allow the freedom to choose either modelling strategy.

There are several issues here:
1. If a part has only one body, it doesn't make sense to assign a new number to that body, because the part is not mocking an assembly in this case. The body should have no number, or a number that matches the file name. However, if there are two or more bodies, then this part is mocking an assembly, and now bodies should have different numbers. For example part is A000150.SLDPRT, body 1 is A000151, body 2 is A000152, etc. This change in numbering scheme when the number of bodies becomes >1 feels dirty. Often when designing the product you don't know if you'll be able to keep it as 1 body, or if it will need splitting for manufacturability.
2. If there are geometrically identical bodies in a multibody part, then it doesn't make sense to number bodies; it is probably better to use Weldment feature to group them, and assign numbers to cut-list items instead. However, this again begs the question of what to do when part has only 1 body. Still use Weldment feature for the sake of uniformity? Even if so, this still retains the #1 issue.
3. Every now and then, SW decides that the bodies / Cut-List items need to be re-created upon rebuild, which loses their names and all associated cut-list properties. In this case, it includes the assigned number. Restoring these numbers is a headache.
4. Things get pretty complex if multibody part has multiple configurations, where each config has a different number of bodies/cut-list items. Say, part is A000150.SLDPRT, config 1 is A000151 and it has 2 cut-list items, A000152 and A000153. Config 2 is A000154 has the same first item A000151, but also a unique item A000155. Config 3 is A000156, and also has the same first cut-list item, but no other items/bodies - so it is not mocking an assembly, and it means that cut-list item number should match the config number (A000156). But it already has a number (A000151) from the other config, it obviously cannot have two numbers.

(I know this last point is very confusing, but it illustrates the flaw with my scheme)

I would love your input on this, I feel I am a bit re-inventing the wheel here, and I'm sure someone else has already figured out the best way to handle these cases, but like I said, I wasn't able to find much info on this forum or elsewhere.

I know some companies just don't use multibody/master modelling and configurations to avoid this complexity, but for me that would be sacrificing some of the most powerful functionality that SW has to offer. I definitely want to keep using configs and multibodies, but I'd like to build a robust numbering scheme that covers all potential pitfalls, so I can then automate all this numbering with API.

Looking forward to your thoughts

[TRKemp]

If you havent already, you might try posting this on the official forum. You may get more traction.

Its an interesting question, just not one I have any constructive feedback on for you unfortunately.

[Frederick_Law]

I use numbering with Assembly, Sub-assembly, part: 00-00-00
Add order number in front: 12345-00-00-00
And don't try to get continuous number. Parts are added and removed during design. Renumber everything will be painful.

[laukejas]

If you havent already, you might try posting this on the official forum. You may get more traction.

Its an interesting question, just not one I have any constructive feedback on for you unfortunately.

You mean the one on the 3DX platform? Which one exactly? I'm finding it difficult to find anything there

I use numbering with Assembly, Sub-assembly, part: 00-00-00
Add order number in front: 12345-00-00-00
And don't try to get continuous number. Parts are added and removed during design. Renumber everything will be painful.

So you mean if Assembly, Sub-assembly, Part is 00-00-00, then Assembly, Sub-assembly, Part, Configuration, Body would be 00-00-00-00-00?

I had considered a similar smart numbering scheme, but it doesn't really work for my case, because:
1. I have to know the exact assembly structure before assigning numbers. I often have to reorganize, sometimes late in the project, moving parts in an out of assemblies, forming new subassemblies, dissolving old ones, etc., which means re-naming parts to make the scheme make sense. The only alternative is to assign these numbers at the end of the project, but that means renaming literally everything, which is a lot of work and carries the risk of breaking stuff.
2. This scheme implies that a component has a single place in the assembly structure, but what if I am using it in multiple subassemblies, on different levels, in that project? Also, adding order number in front means that component now belongs to this project, but if I want to reuse it in another project (without creating duplicate file), naming gets messy.

Not criticizing this scheme, I know it makes a lot of sense for some companies and workflows; but for my case, dumb numbering that doesn't encode any metadata in the part number / file name makes everything a lot more flexible.

I'm just trying to find a good way to keep things tidy with configurations and multibodies. Ideally, if part has no configs and one body, then the part number is the file name, simple. If part has several configurations, then part number is configuration name, while the file name matches the name of the first configuration. If part has two or more bodies (mocking an assembly), then the part number is weldment cut list custom property, since it seems to be the only way to assign it to a body that may have geometrically identical instances in the model.

So basically there may be three different sources of part number (file name, configuration name, cut list property), and I need it to be one source so I can adapt my drawing and BOM templates to it. Or else I'd have to have 3 different drawing templates for each case, which is a PITA to maintain.

The only sensible solution I was able to come up with is to always use cut-list property as part number source, regardless of whether the part has configs and multiple bodies or not. The logic goes like this:
1. If part has no configs and one body -> cut list property is A000150, inherited from default config which is also A000150, inherited from file name which is A000150.SLDPRT.
2. If part has multiple configs and one body -> cut list property is A000150 for first config, A000151 for second config, A000152 for third config, etc., inherited from config names, which are also A000150, A000151, A000152, and file name is A000150.SLDPRT (inherited from first config).
3. If part has multiple configs and multiple bodies -> first cut list property is A000150, second is A000151, third A000152, etc., config names are A000153, A000154, A000155, etc. (no link with cut list properties), and the part name is A000153.SLDPRT (inherited from first config).

This kind of works, but like I said, it has issues when things get complex (multiple configs with different number of bodies, where some are identical and some are not, etc.). So it isn't an ideal solution.

[Frederick_Law]

1. I have to know the exact assembly structure before assigning numbers. I often have to reorganize, sometimes late in the project, moving parts in an out of assemblies, forming new subassemblies, dissolving old ones, etc., which means re-naming parts to make the scheme make sense. The only alternative is to assign these numbers at the end of the project, but that means renaming literally everything, which is a lot of work and carries the risk of breaking stuff.
2. This scheme implies that a component has a single place in the assembly structure, but what if I am using it in multiple subassemblies, on different levels, in that project? Also, adding order number in front means that component now belongs to this project, but if I want to reuse it in another project (without creating duplicate file), naming gets messy.

You want dumb number but you are giving meanings to the numbers.
Even with order number, what's wrong using it in different project? Yes, I've done that before.
As long as you got a way to search part number, you're good.

The dumbest number will be {GUID}. A random long no duplicate "number".
Just use a random number generator. 20 digit, alpha numeric.

Some "intelligent" may be good.
You need to decide and set the rules.

I'm using ModelState in Inventor, same as SW Config.
File name got nothing to do with part number because there are 200+ different size parts/assemblies in there.
All part numbers are in the ModelState/Config.
All drawings has file name same as part number.
I'm building cabinets. Each part and assembly are ModelState/Config.
I've code to generate are drawings (save as and change ref) from the ModelState/Config.
Just setup a form to pick sizes and options to get quick custom cabinet.

Don't worry if you get it right or wrong.
The first try is 100% "wrong".
It's always evolving.
Keep trying and keep evolving.

[AlexLachance]

We work in this sort of manner;
4 letters for categories, a dash to seperate, 4 characters for part numbering, 3 or 4 characters for configuration numbering(when used)
So for instance:
SUSP-1313-254

Would mean
Suspension category
1313 being the part increment
254 being the configuration increment, representing 25 inches and 4 eights(25 1/2")

[laukejas]

You want dumb number but you are giving meanings to the numbers.
Even with order number, what's wrong using it in different project? Yes, I've done that before.
As long as you got a way to search part number, you're good.

The dumbest number will be {GUID}. A random long no duplicate "number".
Just use a random number generator. 20 digit, alpha numeric.

Some "intelligent" may be good.
You need to decide and set the rules.

I'm using ModelState in Inventor, same as SW Config.
File name got nothing to do with part number because there are 200+ different size parts/assemblies in there.
All part numbers are in the ModelState/Config.
All drawings has file name same as part number.
I'm building cabinets. Each part and assembly are ModelState/Config.
I've code to generate are drawings (save as and change ref) from the ModelState/Config.
Just setup a form to pick sizes and options to get quick custom cabinet.

Don't worry if you get it right or wrong.
The first try is 100% "wrong".
It's always evolving.
Keep trying and keep evolving.

Well, my numbers don't really mean anything, they are just sequential, but yeah, you are right, I could be using GUID or something similar with no real difference.

I suppose my question is not so much about how to number, but what to number, in other words - what should be storing the number: is it the part (custom properties or part name), configuration (configuration custom properties or configuration name) or cut list properties. If I understand correctly, in your case (ModelState/Config) you are storing this in configuration-specific part custom properties.

But how do you deal with multibody parts where bodies represent products that need their own numbers? And what do you name the file itself then?

We work in this sort of manner;
4 letters for categories, a dash to seperate, 4 characters for part numbering, 3 or 4 characters for configuration numbering(when used)
So for instance:
SUSP-1313-254

Would mean
Suspension category
1313 being the part increment
254 being the configuration increment, representing 25 inches and 4 eights(25 1/2")

And if the part dimensions change, you need to rename the configuration? And how do you deal with multibodies then?

[matt]

Personally, without knowing exactly what you're trying to do, I would avoid especially the multi body stuff that you described. The problem with bodies getting renamed I think just prevents that from being a practical plan. It's bad enough just using bodies as part of your modeling process without trying to use them for separate products within a single part file as well.

I might even go further and only use this scheme for parts that use what we used to call a "dash number". So if a top level generic ball bearing is part 1001, the 1/4" ball bearing might be 1001-4. And that might be driven by configurations.

I really don't like using configurations in that way, but some people do, and claim to get away with it. SW is set up to make great use of configs, but everybody has to be really careful all the time. It just takes one mistake to really mess things up, and without PDM automating things, mistakes are easy to make.

For some of this, you might think about semi-intelligent numbers, but I'd still avoid bodies as end products, and don't get too carried away with configurations. Try reading this article, and see if it adds to your discussion or just makes things more muddy: https://dezignstuff.com/manual-file-management/

[laukejas]

Personally, without knowing exactly what you're trying to do, I would avoid especially the multi body stuff that you described.

Well, what do you propose as an alternative? There are many designs with complex geometries shared between parts that are impossible or impractical to build as separate parts. Sure, I can save these bodies to separate parts from the main part (master model technique), but they can still disappear/lose references in the same way. And for some parts, like weldments, that might result in a ton of part files, and if you try to build an assembly from them to re-create the original structure, that's a lot of mates to create. And it still doesn't protect from the danger of losing references when SW decides to disappear the original bodies from which the parts are derived.

[Frederick_Law]

No multibody.
SSP and Master Sketch/Skeleton create and maintain links so multibody is not necessary.

All you need with multibody is "ground at origin" don't need to mate.

For weldment, I only have frame parts in there. Whatever add to it is in next level assembly.

Multibody is a pain in every opening in SW. Once you started, you got one shot to finish it correctly.

If possible, don't delete anything in the sketch. Only add to it.
Also don't delete weldment parts, hide them.
From my observation, SW keep everything in a index list. Index is the internal "part number".
So if "3" is deleted, everything after it move up and reference go crazy. 1 and 2 will be ok.

[laukejas]

No multibody.
SSP and Master Sketch/Skeleton create and maintain links so multibody is not necessary.

All you need with multibody is "ground at origin" don't need to mate.

For weldment, I only have frame parts in there. Whatever add to it is in next level assembly.

Multibody is a pain in every opening in SW. Once you started, you got one shot to finish it correctly.

If possible, don't delete anything in the sketch. Only add to it.
Also don't delete weldment parts, hide them.
From my observation, SW keep everything in a index list. Index is the internal "part number".
So if "3" is deleted, everything after it move up and reference go crazy. 1 and 2 will be ok.

Well, I would like to see how someone would design something like this

Or this

Or this

...without multibodies. If there is one-way link between two bodies, then sure, you can create the "main" part, import it into separate part documents, and then cut around to only leave what is necessary. But if body A needs geometry from body B, and body B needs geometry from body A that cannot be placed into some layout sketch, then multibodies are inevitable.

In my use case, 90% of the designs I make are multibodies just because of how closely the geometries are related. Giving up multibodies would make some designs impractical, and some outright impossible to do.

But I understand what you're saying, maybe your experience is with different industries where this is rarely an issue. But in my case, multibodies are essential.

[matt]

Well, what do you propose as an alternative? There are many designs with complex geometries shared between parts that are impossible or impractical to build as separate parts. Sure, I can save these bodies to separate parts from the main part (master model technique), but they can still disappear/lose references in the same way. And for some parts, like weldments, that might result in a ton of part files, and if you try to build an assembly from them to re-create the original structure, that's a lot of mates to create. And it still doesn't protect from the danger of losing references when SW decides to disappear the original bodies from which the parts are derived.

If you have a set of features that are common to several parts, you can take that portion and insert it into multiple parts, and then make the differences from there. Separate parts seems so basic and silly, but in the end, it's the most reliable way to go. I've had a lot of problems with configurations with crashes, features getting turned off, deletes wiping out a lot of work... If you're really disciplined, you can make configs work, but you're always one little problem from a big problem.

[laukejas]

If you have a set of features that are common to several parts, you can take that portion and insert it into multiple parts, and then make the differences from there. Separate parts seems so basic and silly, but in the end, it's the most reliable way to go. I've had a lot of problems with configurations with crashes, features getting turned off, deletes wiping out a lot of work... If you're really disciplined, you can make configs work, but you're always one little problem from a big problem.

Well, the kind of parts I make, features are shared between bodies most of the time, there is no real way to separate them. As for configs, take this recent project of mine (rope blocks):

Can this be done without configs..? Yeah, sure, copy-paste files and make the changes. But what if I discover a design flaw and need to fix it in all variants? Now there's at least 4 files to fix (assuming I can at least use external relations, otherwise that's 16 files to fix). And that's just 4 configs. What if I have a project that has dozens, maybe hundreds of configurations? Separate file for each? That's a maintenance nightmare. Sure, I get what you mean, I know you have to be really careful with this stuff with SW, but the alternative - not using multibodies or configs - is far worse (in my case).

[DanPihlaja]

Well, the kind of parts I make, features are shared between bodies most of the time, there is no real way to separate them. As for configs, take this recent project of mine (rope blocks):

image.png

Can this be done without configs..? Yeah, sure, copy-paste files and make the changes. But what if I discover a design flaw and need to fix it in all variants? Now there's at least 4 files to fix (assuming I can at least use external relations, otherwise that's 16 files to fix). And that's just 4 configs. What if I have a project that has dozens, maybe hundreds of configurations? Separate file for each? That's a maintenance nightmare. Sure, I get what you mean, I know you have to be really careful with this stuff with SW, but the alternative - not using multibodies or configs - is far worse (in my case).

I do things like this, but go one extra step.

I use the multibody part, and call it a MASTER file (example: if my assembly # is MF-02946, then this multibody part is called MF-02946_Master).
For this example, lets say that the multibody part has 8 bodies in it.

I then create 8 empty parts, and, using Insert-->Part (this is the ONLY part in part way to preserve hole wizard data), I insert the MF-02946_Master part into each of them. Select the body that I want that part to represent, and use the "Keep bodies" function of the delete bodies command. This way, if, down the road, any other bodies are added to the master, it won't affect that particular part except for an update.

Now I have 8 separate parts all derived from a single multibody part.

If those parts are part of an assembly, then I will generally also add the master part to the assembly, but only as an envelope part (so that it isn't added to any BOMs). This way, if someone opens the assembly, the master file is automatically loaded in case any updates need to happen.

Now I can control each of these parts separately with regards to custom properties.

[laukejas]

I do things like this, but go one extra step.

I use the multibody part, and call it a MASTER file (example: if my assembly # is MF-02946, then this multibody part is called MF-02946_Master).
For this example, lets say that the multibody part has 8 bodies in it.

I then create 8 empty parts, and, using Insert-->Part (this is the ONLY part in part way to preserve hole wizard data), I insert the MF-02946_Master part into each of them. Select the body that I want that part to represent, and use the "Keep bodies" function of the delete bodies command. This way, if, down the road, any other bodies are added to the master, it won't affect that particular part except for an update.

Now I have 8 separate parts all derived from a single multibody part.

If those parts are part of an assembly, then I will generally also add the master part to the assembly, but only as an envelope part (so that it isn't added to any BOMs). This way, if someone opens the assembly, the master file is automatically loaded in case any updates need to happen.

Not I can control each of these parts separately with regards to custom properties.

That is very smart, and a good advice, thank you. I also use Insert->Part wherever possible, it seems a lot more robust than Insert Into Part or even Save Bodies. Also allows transferring lot more than just solid bodies.

What about naming/numbering these bodies/parts? How do you manage that?

[DanPihlaja]

That is very smart, and a good advice, thank you. I also use Insert->Part wherever possible, it seems a lot more robust than Insert Into Part or even Save Bodies. Also allows transferring lot more than just solid bodies.

What about naming/numbering these bodies/parts? How do you manage that?

For us, we have projects that don't share components (they are basically one off fixtures).


So a main assembly # would be MF-02850
Then each make part under that assembly would be MF-02850-D01, MF-02850-D02, MF-02850-D03, etc...

So, once I have the number of bodies set in stone, I just hit F2 and rename the bodies with the suffix of the part number (D01, D02, D03, etc...)

Then, once the D01 body has been inserted into the part, the part file is named MF-02850-D01

Later, once I know that updates are unlikely, I can lock the File references and freeze the Feature trees so that opening and closing of the files isn't too time/resource consuming.

[laukejas]

For us, we have projects that don't share components (they are basically one off fixtures).


So a main assembly # would be MF-02850
Then each make part under that assembly would be MF-02850-D01, MF-02850-D02, MF-02850-D03, etc...

So, once I have the number of bodies set in stone, I just hit F2 and rename the bodies with the suffix of the part number (D01, D02, D03, etc...)

Then, once the D01 body has been inserted into the part, the part file is named MF-02850-D01

Later, once I know that updates are unlikely, I can lock the File references and freeze the Feature trees so that opening and closing of the files isn't too time/resource consuming.

Right, I see, I initially thought of doing this as well (naming bodies), but then realized if there are multiple identical bodies in the part, it gets a bit weird which body should be named, and what to name the other bodies, so now I went to using weldment feature so that bodies are grouped into cut lists and can have number assigned there.

But your workflow is pretty similar. How do you solve the issue #4 from my first post in this topic, if it ever happens?

[DanPihlaja]

Right, I see, I initially thought of doing this as well (naming bodies), but then realized if there are multiple identical bodies in the part, it gets a bit weird which body should be named, and what to name the other bodies, so now I went to using weldment feature so that bodies are grouped into cut lists and can have number assigned there.

But your workflow is pretty similar. How do you solve the issue #4 from my first post in this topic, if it ever happens?

That has not happened so far here. If I need to use configurations to drive something, I do it at the assembly level and suppress parts inside the assembly, not the multibody part level. For me, the mulitbody part level (The Master level) is ONLY for creating the bodies so that they are referencing each other.

I think that if I HAD to do something like that, I would add extra bodies in the Master file, so that it already has the maximum number of bodies in it.

In other words, if I made a cut in the master file, that created 2 bodies, but then wanted to create a config that later removes that cut, then instead, I would simply recreate that body with the original sketch (even a derived sketch) and add in the extra body with new features.

From my experience, messing with configs and changing the number of bodies in a file really messes things up downstream.

[jcapriotti]

Late to the party as usual but numbering is something I've given a lot of thought to. I'm only going to speak to the config numbering. It's what would be called a "family of parts". Typically similar parts with just a few variations in sizes, features, colors, etc. Fasteners being the most obvious use.

This is my preferred numbering that is dumb and its similar to your example. You have an "A" prefix so not sure if that means something, hence not dumb?

<8 digit sequential number>.<3 digit sequential>

(This is 1356th part family created)
00001356 (Drawing number for the family)
00001356.001 (First part number)
00001356.002 (Second part number)
00001356.003 (Third part number)

The separator is optional but I like it for longer numbers for the same reason social security numbers and phone numbers have them.

Where I work, we use this but the family/drawing/part number is smart. Its a 3 digit number code for the part type (Screw, bracket, plate, etc) followed by two alpha characters, then a 3 digit sequential numeric. The alpha characters break up the number, and also give you 400 combinations instead of 100 that a numeric gives. We still ran out and had to go to AAA which in hindsight we should've started with, that would've given us 8000 part families per part type.

<3 digit Part Type Code><2 digit alpha sequence><3 digit numeric sequence>

115AA
115AA001
115AA002

Next family
115AB
115AB001

All of this still requires some part number policing. The first dumb method just because some user that is "in the know" needs to know if a new family number is needed, or to add to an existing family number. The second smart number needs someone to ensure the part ends up in the correct type.

Since we have gone to Windchill and a new product structure, we are using 8 digit sequential and have the same issue with SolidWorks configurations with different numbers not matching the file name. Windchill has the links so you can figure it out but for people just looking at BOM lists, its not as efficient. Everyone here loves the smart numbers in our legacy systems. They can glance at BOMs and parts lists in various system and have some idea of what it is. In the new system, its difficult to know that for part 50012456, its inside part family/drawing 50012312 because it was added to the family a year later.

[AlexLachance]

And if the part dimensions change, you need to rename the configuration? And how do you deal with multibodies then?

These are for dimensions that will not change, so the configurations remains the same. It's generally for a part that varies in height, so we have a part with all heights by 1/8" so that we can use it in patterns.

For multibodies, we work differently. The file name is the "assembly" of the multibody, or the part if you prefer. The multibodies are identified by their increment, being 001, 002, 003 etc...

[CarrieIves]

It sounds to me like you have two things you need to keep track of - what part numbers have been assigned, and what file that number is in.
I would track that outside of trying to do it just with SolidWorks.
You need a master list somewhere that says what numbers have been assigned (this can be an excel spreadsheet). That list could also say where the SolidWorks file is that has that number in it. In the example above with Windchill, it knows what numbers have been assigned and then has links saying what to look at to find that number.
In excel, I would track the assigned numbers and the filename they are in. It's your numbering system. Make it work for you.
Where I work, we do a lot of work for customers. Each customer and project is the start of the part number. We then have different sections that are for types of things -0xxx are assemblies, -4xxx are mechanical parts.