Using configured part file for screws, nuts, washers, pins, etc. too many configs? too many where used for PDM?

[bnemec]

We took a leap of faith as we were starting out in SW and went down the path of using configurations for our hardware part numbers. At this time our SCREW.SLDPRT file has over 300 part numbers and close to 500 where used files. We're starting to run into some issues and getting the old familiar feeling of "oh, the software wasn't intended to function in that way..."

1) The Where Used tab in PDM can be very very slow, as in Vault View is unresponsive for over a minute some times before displaying the WU after selecting one of these hardware files.
2) To find the where used of a specific screw (part numbered configuration) we must first select a single version of the SCREW.SLDPRT file. Well, that file is at version 46 and the where used is scattered across most of the versions, so the user must know to search the correct configuration of each version to get a correct where used list. This is a very frequent process as many changes are swapping out hardware in a subset of the where used or similar. This pretty much disables the where used functionality of PDM for configured parts.
3) Too many configs in one file? There are about 330 screw configs and it's still growing, the file is around 13MB which I don't think is a problem, but not sure. The biggest problem is that it is FAR too easy for the user to update all or too many configurations when editing one part.
4) We've been trying to find a way to inspect changes across all of the configs from the previous version to the local edit file to confirm only the desired configurations have been edited. We don't have much collective experience with configuration tools such as design table. I think that could be used to compare two versions of the file, but it takes about 20 minutes for it to generate.

Anyway, is that all normal stuff for configured part files? We are strongly considering leaving the configured hardware file path now before we have thousands of where used files to update instead of hundreds that we would need to update now.

Has anyone switched from configured hardware to individual files and updated all the where used from the configured file to the unique individual files? We need the models' geometry IDs to stay the same so that the assembly mates and drawing annotations do not break when updated.

Thank you.

[MJuric]

Anyway, is that all normal stuff for configured part files? We are strongly considering leaving the configured hardware file path now before we have thousands of where used files to update instead of hundreds that we would need to update now.

Has anyone switched from configured hardware to individual files and updated all the where used from the configured file to the unique individual files? We need the models' geometry IDs to stay the same so that the assembly mates and drawing annotations do not break when updated.

Thank you.

Are you creating individual parts for every newly created part? I don't use design tables for this type of thing so not sure if this is possible but can you do this in a manner that doesn't create a new part each time and just refers back to the table?

I only mention this because there are a few ways to setup the toolbox, which we use. One way is to "Create part", which I would assume would trigger a "Where used" and another does not create a new part.

My Metric SHCS in my toolbox presently has ~125 configurations in it and one listing for "Where used". When you open an assy with a bunch of metric SHCS it looks at this one file and pulls the configuration from that single file.

Pro's and cons to using, not using the TB and using not using this type of configuration of the TB. One pro to the TB and this setup is avoiding everything you're talking about. My model with ~125 configs is 1.3MB.

[Merovingien]

i worked long time ago with SW only, and some "Library" part had hundreds or thousands configs.
the files were only some Mo.

SW have no problem with, and for people who are using the file too.
after for big-config-file, there is the "config publisher" that can help the need of scroll through the conifg list,
but "publisher" has some limitation with the use of others advanced features.

in your case, it's "PDM where used" the problem.

but why do you have the need to see that "where used" for screw ? you have to change some ? do upgrade ?

if you manage the config with "SW internal identifier".
you can copy the file to a new.
and use it in the new ASM.

old = screw
new = screw_2021

so it will begin with only "one version in PDM", and the same internal ID.

[Merovingien]

and when you open an old ASM, and want to use the new file,

you just do "Replace part" in SW.
and when you will "archive" the file into PDM, PDM will use the new screw_2021

[bnemec]

i worked long time ago with SW only, and some "Library" part had hundreds or thousands configs.
the files were only some Mo.

SW have no problem with, and for people who are using the file too.
after for big-config-file, there is the "config publisher" that can help the need of scroll through the conifg list,
but "publisher" has some limitation with the use of others advanced features.

in your case, it's "PDM where used" the problem.

That is one of the main issues we have yes.

but why do you have the need to see that "where used" for screw ? you have to change some ? do upgrade ?

Yes, regularly we need to do where used of a part (often hardware parts) to determine the scope of work (number of affected assemblies) that will need to be updated or affected.

if you manage the config with "SW internal identifier".
you can copy the file to a new.
and use it in the new ASM.

old = screw
new = screw_2021

so it will begin with only "one version in PDM", and the same internal ID.

Apologies, I'm not following this part: if you manage the config with "SW internal identifier". Is that a specific way of managing configurations in a file?

I think I under stand the rest in that to save out a config from the screw.sldprt file to a serial number named file I need to save the configured file as a new file then delete all the configs except for the configuration that I want. That way I still have the feature tree and the internal IDs will remain?

[bnemec]

Are you creating individual parts for every newly created part? I don't use design tables for this type of thing so not sure if this is possible but can you do this in a manner that doesn't create a new part each time and just refers back to the table?

In our case, every screw gets a part number in our "ERP" system so it get's a part number in PDM/CAD. Currently each part number is a config name in one of these files. If we dissolve the configured files then each part number would be in it's own part file with a serial number file name and the ERP part number on data card.

I only mention this because there are a few ways to setup the toolbox, which we use. One way is to "Create part", which I would assume would trigger a "Where used" and another does not create a new part.

We decided to not use toolbox. We tried to learn what we could about it in the planning phases, but decided it was not what we wanted.

My Metric SHCS in my toolbox presently has ~125 configurations in it and one listing for "Where used". When you open an assy with a bunch of metric SHCS it looks at this one file and pulls the configuration from that single file.

I don't think that would work for us, we really need to have the where used search functionality for specific part number.

Pro's and cons to using, not using the TB and using not using this type of configuration of the TB. One pro to the TB and this setup is avoiding everything you're talking about. My model with ~125 configs is 1.3MB.

I'm sorry, I don't understand from what you're saying that the TB generated model with 125 configs would avoid the problems we're facing. Ah, it would automatically produce the new configurations as new part numbers are added or change configurations when a part is revised so we wouldn't rely on a user to accidentally apply a change to "all configurations" or "all descendant configurations" We couldn't figure out if we could add our own "stuff" to the tool box, such as locking patch and plating/coating spec. I don't recall the details, but I think that is one of the places using TB started going off the rails.

[MJuric]

In our case, every screw gets a part number in our "ERP" system so it get's a part number in PDM/CAD. Currently each part number is a config name in one of these files. If we dissolve the configured files then each part number would be in it's own part file with a serial number file name and the ERP part number on data card.



We decided to not use toolbox. We tried to learn what we could about it in the planning phases, but decided it was not what we wanted.



I don't think that would work for us, we really need to have the where used search functionality for specific part number.


I'm sorry, I don't understand from what you're saying that the TB generated model with 125 configs would avoid the problems we're facing. Ah, it would automatically produce the new configurations as new part numbers are added or change configurations when a part is revised so we wouldn't rely on a user to accidentally apply a change to "all configurations" or "all descendant configurations" We couldn't figure out if we could add our own "stuff" to the tool box, such as locking patch and plating/coating spec. I don't recall the details, but I think that is one of the places using TB started going off the rails.

No idea if it works for you or not but here's what we did.

1) Copied an existing standard and created our own. Hid everything we didn't want. Copied to make extra for clarity/Ease of use. For instance I have two copies of SHCS. One has all the course threads enabled the other has all the fine threads enabled. Since this also controls the Hole Wizard this made it more difficult for people to place an M8 X 1 rather than an M8 X 1.25 since they had to purposefully go into either course or fine thread to get those.

2) Added custom properties, For us that was mainly plating/Material. We have Zinc, Black oxide, bare, Stainless steel. You can make these available or not available by fastener. For instance we would never use an unplated screw, but we might use an unplated dowel pin.

3) Applied Part number and descriptions to all possible configurations. I did this in an excel spreadsheet using a "Smart number" and then uploaded the data back to the Tool Box. Another custom property we added was "Additional Description". So our BOM's have "Description" which will be something like Screw, Socket Head Cap and an additional description which gives size, pitch, length, plating and specifically marks "Full thread" and "Fine thread". This is used more by purchasing because prior to this it would display the ISO or ANSI callout and for the most part purchasing and even the vendors had no idea what these where. Now if we want an M8 X 60 and it needs to be a fine thread that is fully threaded it's in the description.

I'm not by any means saying that the TB is the way to go but I think it has a bad rap from it's earlier disasters. It definitely has it's issues as well though.

[josh]

At my last job we used a single file for all configs of the same "family" (SHCS, standard nut, thin nut, etc). Of course, these come in a somewhat limited range of possibilities (there's no M9.37 nut), so all of the possible configurations can be easily created using a design table. The beauty of this is:

1. The config name does not have to match the part number. This is great for if you use, say, McMaster screws where the part number has no relation to the size. This also allows you to easily change vendors or part numbering schemes without screwing up all of your existing assemblies. Also your feature tree has meaningful names (like SHCS M6x25) but your BOM can have 86K5937 or whatever. If your part numbers do have some intelligence, you can use Excel functions to easily build the correct part numbers. If you are lucky and you can find a table that has all the possible sizes with their dimensions, with a little careful setup you can just paste the whole thing into the design table and automatically create all the configs.

2. You can set the option to "block model edits that are controlled by design table" and keep people from accidentally applying edits to all configurations and making a big mess.

3. Creating configurations by design table adds very little to the file size. Configurations really only add to file size once they have been activated and rebuilt. At that point, SW actually generates the geometry and saves more data about the configuration. If, after years and years, your file gets bloated from having lots of configs rebuilt, you can do a "Save-As" on the file. That will actually strip out all the generated geometry data about all the configurations and reduce the file size. This should not cause you any issues because the config is still there and valid. If you open an assembly that contains configs of that part, they will rebuild just fine. If you write-protect the file in PDM (because nobody needs to actually edit it since all possible configs already exist), then it will never bloat.

I would recommend that parts that are really a commercially different part (like stainless vs black oxide SHCS) be different files. Otherwise, managing configs vs part numbers can become difficult.

[bnemec]

At my last job we used a single file for all configs of the same "family" (SHCS, standard nut, thin nut, etc). Of course, these come in a somewhat limited range of possibilities (there's no M9.37 nut), so all of the possible configurations can be easily created using a design table. The beauty of this is:

1. The config name does not have to match the part number. This is great for if you use, say, McMaster screws where the part number has no relation to the size. This also allows you to easily change vendors or part numbering schemes without screwing up all of your existing assemblies. Also your feature tree has meaningful names (like SHCS M6x25) but your BOM can have 86K5937 or whatever. If your part numbers do have some intelligence, you can use Excel functions to easily build the correct part numbers. If you are lucky and you can find a table that has all the possible sizes with their dimensions, with a little careful setup you can just paste the whole thing into the design table and automatically create all the configs.

2. You can set the option to "block model edits that are controlled by design table" and keep people from accidentally applying edits to all configurations and making a big mess.

3. Creating configurations by design table adds very little to the file size. Configurations really only add to file size once they have been activated and rebuilt. At that point, SW actually generates the geometry and saves more data about the configuration. If, after years and years, your file gets bloated from having lots of configs rebuilt, you can do a "Save-As" on the file. That will actually strip out all the generated geometry data about all the configurations and reduce the file size. This should not cause you any issues because the config is still there and valid. If you open an assembly that contains configs of that part, they will rebuild just fine. If you write-protect the file in PDM (because nobody needs to actually edit it since all possible configs already exist), then it will never bloat.

I would recommend that parts that are really a commercially different part (like stainless vs black oxide SHCS) be different files. Otherwise, managing configs vs part numbers can become difficult.

oh boy.
1) Our config names don't have to match the part number but they sure should, otherwise how would we know which config to use? Every part has a part number and is set up in MRP and connected to BOMs. So no McMaster screws! Actually this is one of the minor pains is making sure that the part number on the data card and the config name match so that the user selects the correct config from the dropdown when placing a component for example.

2)This I wish we would have made time to get a better understanding of before we set up the configured files.

3)I forgot to mention eDrawings and such, so to get the proper stuff to show up in eDrawings for non CAD people looking we need all the configs to have display data turned on.
I'm not sure why nobody needs to edit it. I think this is where I don't understand tool box, everyone says to me that "you don't revise your hardware" to which I'm thinking "yeah we do"

I would recommend that parts that are really a commercially different part (like stainless vs black oxide SHCS) be different files. Otherwise, managing configs vs part numbers can become difficult.

I get the feeling this last note applies to 99% of our hardware.

[JSculley]

We took a leap of faith as we were starting out in SW and went down the path of using configurations for our hardware part numbers. At this time our SCREW.SLDPRT file has over 300 part numbers and close to 500 where used files. We're starting to run into some issues and getting the old familiar feeling of "oh, the software wasn't intended to function in that way..."

1) The Where Used tab in PDM can be very very slow, as in Vault View is unresponsive for over a minute some times before displaying the WU after selecting one of these hardware files.

That seems slow. I have a 'UNC SHCS.SLDPRT' model with 282 configurations. A where used search (all versions) takes 25 seconds and returns 25538 results.

2) To find the where used of a specific screw (part numbered configuration) we must first select a single version of the SCREW.SLDPRT file. Well, that file is at version 46 and the where used is scattered across most of the versions, so the user must know to search the correct configuration of each version to get a correct where used list. This is a very frequent process as many changes are swapping out hardware in a subset of the where used or similar. This pretty much disables the where used functionality of PDM for configured parts.

Yes, this is a major flaw. We should be able to search for a particular configuration, regardless of version. I think this information can be extracted from the database, provided that you have set your configuration properties up correctly. For example, I have a configuration named '0.250-20 UNC-3A 0.500 LONG' which corresponds to part number 400028. My config properties look like this:

I quickly threw together this SQL query:

Code: Select all

SELECT DISTINCT Xrefs.DocumentID, Documents.Filename      
  FROM XRefs
INNER JOIN dbo.Documents on XRefs.DocumentID = Documents.DocumentID
  where XRefID  in (
	SELECT distinct XRefID FROM XRefConfiguration
	where XRefConfigurationID in (
		SELECT ConfigurationID FROM DocumentRevisionConfiguration where AlternateName='400028'
	)
  )
  ORDER BY Filename
 

Running this query returns 380 results, which seems reasonable. I don't have a good test data set to validate against, so I can't vouch for the correctness, but I think I got it right.

The key bit of data in the query is the 'AlternateName' field. I suspect that it corresponds to the 'Part number displayed when used in a bill of materials' field of the configuration properties as highlighted in my image, but again, I'm not 100% sure.

Now that I've done this much, I'll probably create a custom PDM report when I get a chance. Then users can simply run the report, enter the part number and get a list of files where that config is used.

3) Too many configs in one file? There are about 330 screw configs and it's still growing, the file is around 13MB which I don't think is a problem, but not sure.

My model is 16MB. We've been using it for 15+ years. The file size isn't a problem.

The biggest problem is that it is FAR too easy for the user to update all or too many configurations when editing one part.

I decided early on that this model was too important and ubiquitous to allow anyone and everyone to alter it. If a new size is needed, users send me an email with the details and the part number and I add a new configuration. The part is driven by a design table so it is usually a matter of inserting a new row, copying the row above and tweaking the necessary values in the table. It takes a minute or two at the most.

I use derived configs (through the design table) to group screws of the same size together. So, the default 18-8 stainless screw may have multiple derived configs with different materials or other options (such as the locking patch).

Anyway, is that all normal stuff for configured part files? We are strongly considering leaving the configured hardware file path now before we have thousands of where used files to update instead of hundreds that we would need to update now.

For what it's worth, our configured hardware models have served us well for 15+ years. I wouldn't think of changing. It is simply too convenient to CTRL-drag an existing screw in an assembly, change the configuration, mate it and move on. Or quickly change a screw length and have the BOM part number and description update accordingly.

[josh]

oh boy.
1) Our config names don't have to match the part number but they sure should, otherwise how would we know which config to use? Every part has a part number and is set up in MRP and connected to BOMs. So no McMaster screws! Actually this is one of the minor pains is making sure that the part number on the data card and the config name match so that the user selects the correct config from the dropdown when placing a component for example.

I guess this one sort of depends on your environment. I come at it from a machine design background. As the machine designer, I need to know what size the screw is. I couldn't give two rips what its actual part number is until it's time to order. It's possible to drive your BOM and MRP etc. from a custom property that's specified in the design table rather than the configuration name. So all my screws configs are like "SHCS BO M6x30". As the designer, this tells me everything I need to know about the thing to do the design. If all my config names looked like 86K69432, how would I know which config to use? :-D The actual part number that goes in the BOM and drives the ordering process comes from a custom property driven by the table. That number can be whatever I want. If today I'm ordering that part from McMaster and tomorrow the bean counters decide we need to order them all from Grainger instead, all I have to do is edit the design table and change the part number and vendor for all configs of that black oxide SHCS. Then, when I open any assembly using that file I don't have any issues becasue the config names didn't change. Only the custom property displayed in the part number field of the BOM changes. In fact, they could decide "Anything up to M8 comes from McMaster, and anything bigger is from Grainger. I just fix the custom properties in the design table and I never have to worry about which vendor sells which size. I just pick my "SHCS BO M10x50" and keep designing.

[josh]

2)This I wish we would have made time to get a better understanding of before we set up the configured files.

3)I forgot to mention eDrawings and such, so to get the proper stuff to show up in eDrawings for non CAD people looking we need all the configs to have display data turned on.
I'm not sure why nobody needs to edit it. I think this is where I don't understand tool box, everyone says to me that "you don't revise your hardware" to which I'm thinking "yeah we do"

2) You can actually do this after the fact. Just insert a design table with the option "Auto-create". It will make a column in the DT for every parameter that varies across any configs, and it will make a row for every config. Then you can still check the box for "block model edits for parameters controlled by DT" (or whatever it's called.)

3) As far as people needing to edit the file, IF you set it up from the start to contain every valid size of screw (surely you don't have infinite variability?) then why would anyone need to edit it? This is not referring to toolbox either. I'm just talking about modeling up a screw, then making a design table to generate every size.

[SPerman]

3) As far as people needing to edit the file, IF you set it up from the start to contain every valid size of screw (surely you don't have infinite variability?) then why would anyone need to edit it? This is not referring to toolbox either. I'm just talking about modeling up a screw, then making a design table to generate every size.

At the place I worked before, the cad admin decided to make bolts up to a certain length and diameter. This covered 99.9% of our needs. Every once in a while someone would need something out of the ordinary, and the admin would create it as needed.

[Merovingien]

me too, i never used Toolbox, because too long to work with, it takes too many time,
i use "PRT with Excel" design table since more than 15 years,

with Excel, you can access to powerfull advanced things
(equations, automated descriptions, invisible datas... and plent other things)
toolbox can't do that (toolbox dumbiness)
(toolbox is like a baby feature for people discovering SW software).

that's why majority of advanced SW users only work with "PRT Excel" files.

and as josh said
"You can set the option to "block model edits that are controlled by design table" and keep people from accidentally applying edits to all configurations and making a big mess"

when you have habbits working with "PRT Excel" for library fasteners, you anticipate a lot the future need,
and when you have a create a new size and length, sometimes it's better to create the whole length.
to avoid creating tons of version under PDM.


with "SW internal identifier" you reach the end of how SW works to calculate BOM (ASM)
and of course to enable it in BOM, you have to select "mode 3" under bom setting (i forgot the name)

with that, if you use "screw_old" and "screw_2021" in an ASM, SW will evaluate them correctly (merge the correct config)
so in the BOM, the trick will be invisible.

of course i don't talk about the PDM-dumb-BOM calcultation, because PDM is absolutely not working like SW for BOM.
(that's why some features become "forbidden" under PDM).

if you don't care for PDM-(dumb)-Bom, it's the best,
will save you a lot workarround, or won't force you to "truncate" the possibility of SW feature, or with the state "that feature is now forbidden"... etc...

the thing with "screw_2021" it is just a simple copy-paste (rename).
you don't have to delete configs inside. keep the file as it is.
under PDM, it will be "version 1" only.
so after, for new project, use only the "screw_2021"

and for old project (ASM), if you really need, open and replace the file (logged as an ADMIN)
so no new revision is created.
and don't forget, when job done, to "log out as an admin", and retun to your "normal user log in"


you can also (if all ASM aren't extracted) rename the "screw" to "screw_old"
PDM will update all the links.
and then, you copy-paste, so the new file name will be "screw" (version 1 under PDM)
and the old is aside "screw_old" (version 46 under PDM).
as your choice...

[Frank_Oostendorp]

And this is the amazing BOM with thumbnails if you use Toolbox Configurated Parts.

[Merovingien]

the preview doesn't match with the line (your preview seems M8 x 12),
the last one is M16 x 160 mm length...

preview increase a lot the Bom-line thickness.

[Frank_Oostendorp]

Not sure what you mean by "preview increase a lot the Bom-line thickness.".
My point was that the previews don't match the configuration. Also with left and right configs of sheet parts, this makes the thumbnails useless for me, they create more confusion than clarification.

[Merovingien]

yes, more confusion

[matt]

AT one job I made huge configured files for various types of screws with different materials, heads, drives, thread lock, dog point, finishes, etc... The files were huge.

Solid Edge does configurations, which it calls Family of Parts, but it does each as a separate document. It seems more tedious, but in the end, it's a lot safer, easier to work with, less hassle, and fewer crashes or other problems. And I think it's less ambiguous when it comes to PDM, BOMs, uses potentially less memory, etc.

I think the whole question kind of typifies the differences between the products and the companies - one is just flashier and easy, but "fast and loose", while the other is a little more structured, safer and more stable.

[SPerman]

Solid Edge does configurations, which it calls Family of Parts, but it does each as a separate document. It seems more tedious, but in the end, it's a lot safer, easier to work with, less hassle, and fewer crashes or other problems. And I think it's less ambiguous when it comes to PDM, BOMs, uses potentially less memory, etc.

NX uses a similar part family approach. IMO, it makes much more sense than the way SW handles it, but that could by my bias from starting with NX and moving to SW.

[MJuric]

AT one job I made huge configured files for various types of screws with different materials, heads, drives, thread lock, dog point, finishes, etc... The files were huge.

Solid Edge does configurations, which it calls Family of Parts, but it does each as a separate document. It seems more tedious, but in the end, it's a lot safer, easier to work with, less hassle, and fewer crashes or other problems. And I think it's less ambiguous when it comes to PDM, BOMs, uses potentially less memory, etc.

I think the whole question kind of typifies the differences between the products and the companies - one is just flashier and easy, but "fast and loose", while the other is a little more structured, safer and more stable.

Not specifically to you, but in general, what are the advantages/Disadvantages to using a .PRT/Design table over the toolbox? Every place I've worked has always used the TB so I have very little experience with other methods.

Does .PRT/Design table provide the same "On the fly" configurations as TB or do you have to pick exact parts, IE lengths, sizes etc? If so hows does that work? Is the interface specially created thru API/Macro?

For instance when I use TB I place the fastener and 90% of the time it knows what size and mates based on hole wizard. All I need to change is the length. Pretty much everything is a simple drop down if I want to change it, Size, length, thread length, thread display and any custom features, IE we added plating and material.

Someone mentioned working in TB and can't use excel. I never work in TB and export everything to Excel. I then created everything I wanted, Descriptions, Part numbers etc using Excel equations and then just imported it back. In short anything that can be done in excel can be done in TB statically, not dynamically obviously.

[matt]

Not specifically to you, but in general, what are the advantages/Disadvantages to using a .PRT/Design table over the toolbox? Every place I've worked has always used the TB so I have very little experience with other methods.

Does .PRT/Design table provide the same "On the fly" configurations as TB or do you have to pick exact parts, IE lengths, sizes etc? If so hows does that work? Is the interface specially created thru API/Macro?

For instance when I use TB I place the fastener and 90% of the time it knows what size and mates based on hole wizard. All I need to change is the length. Pretty much everything is a simple drop down if I want to change it, Size, length, thread length, thread display and any custom features, IE we added plating and material.

Someone mentioned working in TB and can't use excel. I never work in TB and export everything to Excel. I then created everything I wanted, Descriptions, Part numbers etc using Excel equations and then just imported it back. In short anything that can be done in excel can be done in TB statically, not dynamically obviously.

Toolbox has a lot of great advantages, especially when used with Hole Wiz, I think we've already covered a lot of that in another thread.

BUT in order to use those benefits, you have to use the configurations approach in toolbox, you can't use the individual parts. And in Toolbox, if you don't have everyone set up using either a network install or exact copies of the database, you can run into some really bad side effects.

In short, Toolbox is great, but you have to know how to set it up. The defaults are I think the worst possible options available, and most dangerous from a data integrity point of view.

The advantage of skipping toolbox is that you don't get the possibility for the automated stuff in toolbox to bite you. For example, the auto-creation of sizes/configurations you haven't used before. If every user has their own Toolbox installation, then people probably don't have the same parts active in their database, so if someone opens an assembly with configurations they don't have, Toolbox substitutes the largest sizes (or they used to do this anyway), and you get the "Huge Screws" in your assembly. If you save it that way, you're "screwed" in a big way. If you don't have a backup, you've got to go back through and reset all the hardware sizes.

That, and maybe some other quirks are why a lot of people avoid toolbox. But the automation options when combined with hole wiz are really amazing.

[Frank_Oostendorp]

In case you work in a group, spread out over the globe, using toolbox parts is almost impossible to control. So we always create a single part for every fastener, and let this travel the world, together with the assembly. Working 100%.

[MJuric]

Toolbox has a lot of great advantages, especially when used with Hole Wiz, I think we've already covered a lot of that in another thread.

BUT in order to use those benefits, you have to use the configurations approach in toolbox, you can't use the individual parts. And in Toolbox, if you don't have everyone set up using either a network install or exact copies of the database, you can run into some really bad side effects.

In short, Toolbox is great, but you have to know how to set it up. The defaults are I think the worst possible options available, and most dangerous from a data integrity point of view.

The advantage of skipping toolbox is that you don't get the possibility for the automated stuff in toolbox to bite you. For example, the auto-creation of sizes/configurations you haven't used before. If every user has their own Toolbox installation, then people probably don't have the same parts active in their database, so if someone opens an assembly with configurations they don't have, Toolbox substitutes the largest sizes (or they used to do this anyway), and you get the "Huge Screws" in your assembly. If you save it that way, you're "screwed" in a big way. If you don't have a backup, you've got to go back through and reset all the hardware sizes.

That, and maybe some other quirks are why a lot of people avoid toolbox. But the automation options when combined with hole wiz are really amazing.

Thanks.

I just keep hearing people say they are using something other than the TB and it seems like they are doing little more than....well, re-creating the toolbox and then ending up with something that has fewer options.

Completely agree on setting it for configuration use. If you're using TB and making a new part and saving it, it can get messy and at the same time kind of defeats many of the advantages.

Also completely agree on a single universal TB, but I can't imagine any engineering department not doing this. Having everyone using whatever fasteners they want seems like a recipe for disaster. In fact what I did with ours is to create and entire new standard and hid everything else. That way people aren't using DIN, ISO etc etc. Not only are we all using the same TB, but if they place an M10 X 50...it's the same one no matter who places it....because they only have one choice.

TB is not without it's issues and possibly those issues make it less robust than other methods, but from what I can tell it also seems to have a lot of benefits that are not as readily available with other methods.

My biggest complaint with TB is that adding parts to it is not more easily done. Being able to add fittings and other often used items and have those items be placed and modified just like fasteners would be a huge improvement.

[MJuric]

In case you work in a group, spread out over the globe, using toolbox parts is almost impossible to control. So we always create a single part for every fastener, and let this travel the world, together with the assembly. Working 100%.

Curious why you would say that. As long as single person or group of people are in control of the TB and responsible for it I wouldn't see it different as any other approach.

In the past whenever we have subcontracted engineering we simply sent along a copy of our TB. They just redirect their TB to ours while working on our stuff.

As long as there is someone controlling revisions of the TB and making sure those revisions are done across all locations it's no different than any other library of parts that is not pulled from the same source.

[Frank_Oostendorp]

"If you're using TB and making a new part and saving it, it can get messy" .
If you create the part new, with minimum features, minimum file size, it's as clean as it can be.
Controlling the toolbox of multiple companies all over the world is not that easy. They are not always partners, they can be suppliers to, even running other versions of SolidWorks or other programs.
Our fastener parts/files show all essential details we expect. Standard, Material, Surface Treatment, etc.

[MJuric]

"If you're using TB and making a new part and saving it, it can get messy" .

My point here was in response to matt talking about "How TB is set up". You have several options like "Create new part" or "Refer to the Toolbox". The former creates new models and places them. The later does not and when you open the model it looks at the toolbox for fasteners. This way, at least IMO, is the more effective way to use TB and avoids some of the issues many people see with the TB.

If you create the part new, with minimum features, minimum file size, it's as clean as it can be.

All of those options are available in the TB as well. Again the point is not "How clean is the model" the point is you can use TB without creating TB fastener models at all.

Controlling the toolbox of multiple companies all over the world is not that easy. They are not always partners, they can be suppliers to, even running other versions of SolidWorks or other programs.

Maybe I'm missing something but all of the issues above you would be faced with using any method, no? You can't send a Design table in SW2021 and expect someone using F360 to be able to use it. At best they can look at the spreadsheet and redraw/Recreate the fastener. Furthermore if they are in a completely different system you're not getting a SW file back anyway.

Our fastener parts/files show all essential details we expect. Standard, Material, Surface Treatment, etc.

So do ours. You can add custom properties to the TB and make it whatever you want. Furthermore all those options pop up as drop downs when you place the fastener. Our stock number, desired material, plating, primary and secondary descriptions are all in our TB and are sent to our BOM's.

[Merovingien]

as you said, MJuric

Not specifically to you, but in general, what are the advantages/Disadvantages to using a .PRT/Design table over the toolbox? Every place I've worked has always used the TB so I have very little experience with other methods.

Excel work advanced formulas, etc...
the formula stay into the file,

no need to rewrite it,
or copy-paste between "TB to Excel", do the work, then copy-paste "Excel to TB"


for the automatization, it's possible to do the same, and even more, than TB,
by using the adequate advanced features available with SW,
and easy to manag it with Excel.

when you master "PRT with Excel" you don't have time to loose with the "slowly TB interface"

[matt]

Thanks.

I just keep hearing people say they are using something other than the TB and it seems like they are doing little more than....well, re-creating the toolbox and then ending up with something that has fewer options.

Some users who have been around more than 10 years haven't forgiven toolbox for previous sins, and I haven't checked it to see what new wonders are in there. It was broken badly for a long time, and people just wrote it off.

[Merovingien]

an example for this problem https://www.cadforum.net/viewtopic.php?f=16&t=582
it's so easy to solve with "PRT + Excel"
and impossible with TB (toolbox)

[MJuric]

an example for this problem viewtopic.php?f=16&t=582
it's so easy to solve with "PRT + Excel"
and impossible with TB (toolbox)

I'm not following. The solution was a sketch driven component pattern, which can not only be done with TB but actually has nothing to do with TB. Plop in one fastener, do the sketch, pattern. Doesn't matter how the fastener was placed or with what.

[MJuric]

as you said, MJuric



Excel work advanced formulas, etc...
the formula stay into the file,

no need to rewrite it,
or copy-paste between "TB to Excel", do the work, then copy-paste "Excel to TB"


for the automatization, it's possible to do the same, and even more, than TB,
by using the adequate advanced features available with SW,
and easy to manag it with Excel.

when you master "PRT with Excel" you don't have time to loose with the "slowly TB interface"

What "Advanced formulas" are you using for the fasteners? I'm genuinely curious as to what you're doing as I'm just using TB to place fasteners. I'm not using any formulas, nor do I find any need for formulas, to do that.

Again, I've not used PRT/Excel for fasteners so I haven't any idea what difference in performance there is.

[MJuric]

Some users who have been around more than 10 years haven't forgiven toolbox for previous sins, and I haven't checked it to see what new wonders are in there. It was broken badly for a long time, and people just wrote it off.

I understand that as well as companies/people, that developed their systems prior to this TB/Fixed TB already have a system in place and no need to change it.

I only started using SW in 2016 and everywhere I've worked has used the TB.

I certainly don't consider myself an expert but it seems like whenever the discussion comes up I feel I must be missing something with non TB systems or advantages of them. It seems everything people say "Can't be done in TB" can be, at least to my understanding and so far I've not seen a significant advantage to non TB systems.

[JSculley]

I certainly don't consider myself an expert but it seems like whenever the discussion comes up I feel I must be missing something with non TB systems or advantages of them. It seems everything people say "Can't be done in TB" can be, at least to my understanding and so far I've not seen a significant advantage to non TB systems.

One advantage of non-TB systems is that they don't require SW Professional. We have 18 seats of SW standard, so Toolbox has never been an option.

[Merovingien]

I'm not following. The solution was a sketch driven component pattern, which can not only be done with TB but actually has nothing to do with TB. Plop in one fastener, do the sketch, pattern. Doesn't matter how the fastener was placed or with what.

don't look at the "choosed answer" but i took that problem as an example,
the user have a specific need.

with "PRT + Excel" in less than one minute, i modified the PRT.
then users just have to use it with "one clic" under ASM (one clic, about one lazzy-second)

with TB = impossible to do it

with "sketch pattern" : each time the users will uncouter that problem,
he will have to spend many seconds : to create sketch, points with relation, activate sketch-pattern, choose the correct option-reference...

[MJuric]

One advantage of non-TB systems is that they don't require SW Professional. We have 18 seats of SW standard, so Toolbox has never been an option.

Good point, I never really understood why that is the case. Seems like a pretty basic function that they just don't include.

[MJuric]

don't look at the "choosed answer" but i took that problem as an example,
the user have a specific need.

with "PRT + Excel" in less than one minute, i modified the PRT.
then users just have to use it with "one clic" under ASM (one clic, about one lazzy-second)

with TB = impossible to do it

with "sketch pattern" : each time the users will uncouter that problem,
he will have to spend many seconds : to create sketch, points with relation, activate sketch-pattern, choose the correct option-reference...

If I'm understanding you correctly you went into the PRT and created another config with the offset in the part. While I can see this being helpful if for some reason you had the exact same offset all the time if you have to go back and make a config for every new offset I don't see the time savings.

Furthermore I think you could do this in TB by modifying the model and adding some additional dims to it. Then you all you would have to do is change that dim for whatever the offset is etc.

All that being said certainly if you create a specialized system that you have complete control over, of course you are going to have more options. However that is like saying we shouldn't be using "Draw line" in SW because you can make a macro that does something additional that SW draw line does not.

[Per S]

My experience is that its better make one part for each scew and give a dum number like P00xx for al purchased part. Then give description name that can be changed not affekt the file.

I add nut and wascher in same part and give gap a configuration. So order a M6S 12x25+ BRB +M6M is one file. Opening gap between head and wascher can be like 15, 18etc from config

I realy hate this solidwork demo with a grinder there part name is not number. Ok it work if do some job in garage at home.

[bnemec]

I guess this one sort of depends on your environment. I come at it from a machine design background. As the machine designer, I need to know what size the screw is. I couldn't give two rips what its actual part number is until it's time to order. It's possible to drive your BOM and MRP etc. from a custom property that's specified in the design table rather than the configuration name. So all my screws configs are like "SHCS BO M6x30". As the designer, this tells me everything I need to know about the thing to do the design. If all my config names looked like 86K69432, how would I know which config to use? :-D The actual part number that goes in the BOM and drives the ordering process comes from a custom property driven by the table. That number can be whatever I want. If today I'm ordering that part from McMaster and tomorrow the bean counters decide we need to order them all from Grainger instead, all I have to do is edit the design table and change the part number and vendor for all configs of that black oxide SHCS. Then, when I open any assembly using that file I don't have any issues becasue the config names didn't change. Only the custom property displayed in the part number field of the BOM changes. In fact, they could decide "Anything up to M8 comes from McMaster, and anything bigger is from Grainger. I just fix the custom properties in the design table and I never have to worry about which vendor sells which size. I just pick my "SHCS BO M10x50" and keep designing.

I'd guess we use hardware about half the time by metrics (size, thread, features) and the other half by part number. I'm not talking about mfg, or McMaster or fastenal part number. The part number is set up in our "MRP" system (completely outside CAD and PDM) but that is how the object is identified within the scope of our company. We don't buy screws here or there or wherever, they all come from the inhouse Fastenal Store, used to be Endries. Well, even that has exception when they cannot source something that meets the requirements, but that's off topic.
Anyway, nearly all EC's reference hardware by part number, I cannot think of an example that didn't, so we generally talk about fasteners in terms of the part number more than the description/size.

[bnemec]

2) You can actually do this after the fact. Just insert a design table with the option "Auto-create". It will make a column in the DT for every parameter that varies across any configs, and it will make a row for every config. Then you can still check the box for "block model edits for parameters controlled by DT" (or whatever it's called.)

We're trying to learn that now. That is the table that takes nearly a half hour to generate for the screw file. When it finished I displayed it full screen on my 43" 4k and the text was dots. There are way too many columns which leads me to believe there are a lot of redundant parameters. I think a path could be to use global variables then set the parameters to the global variables?

3) As far as people needing to edit the file, IF you set it up from the start to contain every valid size of screw (surely you don't have infinite variability?) then why would anyone need to edit it? This is not referring to toolbox either. I'm just talking about modeling up a screw, then making a design table to generate every size.

Infinite? Theoretically, no. But pretty much, there is no way I can predict all of the potential variations we could possibly need in the future.
Also there seems to be an assumption that hardware models are never revised, our hardware part numbers and models get revisions.

[bnemec]

Not sure what you mean by "preview increase a lot the Bom-line thickness.".
My point was that the previews don't match the configuration. Also with left and right configs of sheet parts, this makes the thumbnails useless for me, they create more confusion than clarification.

I think he meant the row height is bigger to accommodate the thumbnail.

Also, I think he might have missed the sarcasm, I know I missed it. That is why Matt created the SARC button (it colors the text bluish/purple). Thing is, thumbnails are great so I too the bait, problem is getting them to be accurate which lead to your affectionate comments concerning them in the BOM.

[Frank_Oostendorp]

@bnemec the toolbox is slow, big tables are even slower. If you already have 1 single screw of a certain standard, type, material and length, how much time is involved to create a sister or brother with different length? 30 seconds? Complete with drawing containing all specs, purchase info, etc.
sorry for not being bleu all the time but still learning.

[josh]

We're trying to learn that now. That is the table that takes nearly a half hour to generate for the screw file. When it finished I displayed it full screen on my 43" 4k and the text was dots. There are way too many columns which leads me to believe there are a lot of redundant parameters. I think a path could be to use global variables then set the parameters to the global variables?


Infinite? Theoretically, no. But pretty much, there is no way I can predict all of the potential variations we could possibly need in the future.
Also there seems to be an assumption that hardware models are never revised, our hardware part numbers and models get revisions.

OK, this may relate back to what I said earlier about different "families" of parts being different files. I keep mentioning SHCS because that's the thing I use most, but... I would never dream of trying to have SHCS and, say, Phillips countersink screws be the same file. Having all that many features suppressed/unsuppressed etc would be a mess for sure. If you have that many columns that auto-generate, it sounds like that's the sort of thing you have in your file.

I'm also trying to understand how hardware models get revised. Unless you are having custom fasteners made, harware is hardware, governed by outside standards. You can't just decide that an M6x30 screw is actually 37mm long... The only thing I can imagine is that your part numbers are actually somehow driven by their function in your design? Such that "The screw that holds widget "A" onto sprocket "B" is defined as part number GNQ2534" or something like that. So that your BOM always says GNQ2534, but then if the design changes you have to revise GNQ2534 to be a slotted cheese head screw instead of a self-tapping hex head sheet metal screw, and you edit your screw model to try to match?

[Merovingien]

when using Excel-DT,
it needs some (many) times to experience it, make mistakes,
understand more how Excel-design-table works, change/correct things or how you use the Excel-DT, etc...

generally for Library-PRT, Excel-DT settings have specific settings to do that work, and work it faster (master-slave).
if you keep using the default setting for Excel-DT, this is normal it runs slow.
that mean you have to practice it more, explore "that branch-feature of SW"

[bnemec]

Sometimes I think the "You're doing it wrong" clause would apply to much of how this company does part numbers, CAD, etc. But it's been a slowly evolving thing for several decades and sudden changes are beyond the scope of any one department, except sales or inventory control, I digress. Anyway, I want to thank you all for the comments. So many times the WWW of How To's lack context of how the "best practices" are applied so it takes some digging.

OK, this may relate back to what I said earlier about different "families" of parts being different files. I keep mentioning SHCS because that's the thing I use most, but... I would never dream of trying to have SHCS and, say, Phillips countersink screws be the same file. Having all that many features suppressed/unsuppressed etc would be a mess for sure. If you have that many columns that auto-generate, it sounds like that's the sort of thing you have in your file.

Yeah, sigh, we have every single screw in our system in SCREW.SLDPRT. We did that because it's common to switch between one head to another. So breaking it out into more than one file would very much undermine the ease of switching from one screw to another, there is no category that we might not switch to/from, head style included. I think you're spot on about why there are so many columns and the cells are blank for most of the rows.

I'm also trying to understand how hardware models get revised. Unless you are having custom fasteners made, harware is hardware, governed by outside standards. You can't just decide that an M6x30 screw is actually 37mm long...

They're not all custom. But since you put it that way, I guess most of our hardware is custom; even though 99% of our hardware comes from Fastenal, majority of it is not in their catalog. You would need to have their part number for that specific part to find it. Yeah, we have odd lengths sometimes. The concept that "hardware is hardware" is tossed in the same can as "you don't revise hardware"; both of those premises do not apply where I work.
When you combine all the possibilities, Here's a list of things other than thread, length, head, thread start type normal stuff that tend to make our hardware not "off the shelf".
- locking patch material
- locking patch start
- locking patch end
- locking patch coverage angle (example 90 deg, 180, full, etc)
- plating type
- plating thickness

These are not data card variables, maybe they should be, but it's hard to know the end from the beginning especially when we don't yet know if/how to use all the functionalities in CAD and PDM. In Solid Edge we knew which features we could make use of and which ones were taboo. Trying to get a lay of the "mine field" concerning how to use configurations.

Revisions to hardware part numbers are not a weekly occurrence here, but probably 5 - 10 times per year. We add or obsolete part numbers probably two or three times that per year. So one person could be the keeper, but we would need a backup or two incase that person is out of office. Oh, obsolete, so we can only use hardware that is "in the system" ie has a part number. For new designs we can get whatever, but before that product can go into production all of the hardware must be loaded into MRP/MES (whatever it's called) and be set up through purchasing as well as stocking locations in the work center(s) where it is consumed. So if a screw part number is no longer used it will be obsoleted from the system and that needs to be obvious to the designers that it is not a part number we have.

As far as determining the specs for a specific hardware, it all depends. I've been on projects where we will use <15 of that part a year, you can bet I do not get to spec a custom part number for that. So it's a matter of finding something that we already have that meets the requirement. This is the situation where we look up by description rather than part number. If I need 1000 hr salt spray and locking patch I might be using a 3/8 where a 5/16 would be more than enough, we don't have a 5/16 but have a 3/8 that meets requirements and has a last year usage of 100k pcs so it would be a fraction of the cost of a low volume 5/16 plus the overhead of setting up and maintaining a new part number. Another case is for a product with expected sales of 50k and will need half-dozen of a specific screw each. In that case I can specify exactly what would work best for the design. The third case is my least favorite, the customer requirements lead to a situation where we need a custom screw with an EAU of 50 but they are willing to pay for it, Purchasing really hates those. Those three cases are the norm, the first two probably evenly share 90% of hardware usage, third case being the rest (and the most revised)

We probably don't have a 37mm long M6x30 but I picked "SCREW,3/8-16X1" out of the blue and we have 15 unique part numbers for a 1" long 3/8" UNC screw. Six of them for HHCS. I didn't look for any other examples, don't want to know.

[JSculley]

Yeah, sigh, we have every single screw in our system in SCREW.SLDPRT. We did that because it's common to switch between one head to another. So breaking it out into more than one file would very much undermine the ease of switching from one screw to another, there is no category that we might not switch to/from, head style included. I think you're spot on about why there are so many columns and the cells are blank for most of the rows.

I would argue that the time it takes you to hunt for the config you want would be about the same as a Replace Component operation.

The good news is that since you have all the different screw types in one model, you should be able to split it out into separate files, and not cause mating issues in existing assemblies. This assumes that the key mating geometry is the same for all the different screws (e.g. the thread OD and the edge or bottom face of the screw head.

And, if you keep the config names the same across the files, the Replace Component command can choose the config of the replacement part automatically.

[MJuric]

Yeah, sigh, we have every single screw in our system in SCREW.SLDPRT. We did that because it's common to switch between one head to another. So breaking it out into more than one file would very much undermine the ease of switching from one screw to another, there is no category that we might not switch to/from, head style included. I think you're spot on about why there are so many columns and the cells are blank for most of the rows.


They're not all custom. But since you put it that way, I guess most of our hardware is custom; even though 99% of our hardware comes from Fastenal, majority of it is not in their catalog. You would need to have their part number for that specific part to find it. Yeah, we have odd lengths sometimes. The concept that "hardware is hardware" is tossed in the same can as "you don't revise hardware"; both of those premises do not apply where I work.
When you combine all the possibilities, Here's a list of things other than thread, length, head, thread start type normal stuff that tend to make our hardware not "off the shelf".
- locking patch material
- locking patch start
- locking patch end
- locking patch coverage angle (example 90 deg, 180, full, etc)
- plating type
- plating thickness

Again, seems to me this is really easy to do in the TB unless for some reason you have some very odd fasteners that could not be created/Modified from a standard TB fastener. The real drawback to TB is that you CANT add completely new parts. You can make changes, say for some reason you had a SHCS with an oddball head size that's a pretty easy change.

All the custom options you have listed could be added as custom properties and all would be drop downs while placing the fastener.

Instead of digging thru a mound of configs you would have the typical graphic TB display. You could pick the family, type etc and place the fastener. It would attempt to figure what size you actually wanted and place it. All the options would be available for the first placement.

[bnemec]

I would argue that the time it takes you to hunt for the config you want would be about the same as a Replace Component operation.

Now that we've been using it for a while, I would not argue against that.

The good news is that since you have all the different screw types in one model, you should be able to split it out into separate files, and not cause mating issues in existing assemblies. This assumes that the key mating geometry is the same for all the different screws (e.g. the thread OD and the edge or bottom face of the screw head.

That is good news as we went to great lengths to make sure the proper geometry was used to locate the parts, even colored the faces that are to never change no matter the length of thread (full or not) or head style.
What I'm not sure about is we thought is was a good idea to organize the screws by size then length so all the actual part number configs are buried under generic "folder" configs. We were learning as we went and learned a little too late there there is no way to move them around.

And, if you keep the config names the same across the files, the Replace Component command can choose the config of the replacement part automatically.

The hope was that each of the dispersed files would only have one config, but keeping the name the same is not a problem. The Replace Component is what scares me. Many files, Many components, many of them in released state (revision control).

[MJuric]

Sometimes ....

I spent a few minutes throwing your list into custom properties. I have zero experience using the Excel/PRT approach so have no idea how this compares to what you're doing. This is how it would work if you used the TB.

Any of those added properties can be used to create a new configuration, in descriptions etc etc. If you set up the TB to not create parts and only run on Configurations when you add the custom properties to configurations is automatically creates all the possible configurations in the part. When make selections it updates the config.

There are also several other options you can use in the TB as well, custom config names etc etc.

The graphics area to the right is also complete configurable. This allows you to create "Families" of parts which is alot easier than having everything in one file.

You can also export the entire thing into excel and do any other type of operation you want to create the database initially. For instance I export the information and used Excel to create all of our part numbers and descriptions based on a "Smart number" system I created and by concatenating fields made the description. I then uploaded that back into the TB.

[bnemec]

Again, seems to me this is really easy to do in the TB unless for some reason you have some very odd fasteners that could not be created/Modified from a standard TB fastener. The real drawback to TB is that you CANT add completely new parts. You can make changes, say for some reason you had a SHCS with an oddball head size that's a pretty easy change.

All the custom options you have listed could be added as custom properties and all would be drop downs while placing the fastener.

Instead of digging thru a mound of configs you would have the typical graphic TB display. You could pick the family, type etc and place the fastener. It would attempt to figure what size you actually wanted and place it. All the options would be available for the first placement.

I had to dig back in my notes now to see where we were with toolbox. At @JSculley mentioned, toolbox is not available in Standard which I had forgotten about and was helpful reminder because I wasn't looking back to before we purchased SW. It was a matter of chicken and egg. We couldn't get contextual examples of how we would set up TB and how it would work in our case with PDM and revising hardware and so on. Can't test it without buying it. Since we heard a lot of "hardware aren't revised" type comments we decided it wasn't for us. And, because there was nothing else in Pro or Prem that we needed we bought Standard.