Commercial parts best practices?

[jayar]

What are all y'alls best practices for utilizing commercial parts for speeding up your design work?
Do any of you regularly utilize commercial catalog components? If so, do you keep them in a specific folder and point SWX to it? Any rhyme or reasons?

Many times I have downloaded parts from McMaster-Carr and dropped them into my designs, works pretty well even if they aren't the most efficiently modeled or defeatured the best. I just downloaded the 80-20 parts catalog for SWX b/c I'm working on a project using those components. I just unzipped it into some folder and am playing around with developing the design from that.

Note - I'm working by myself w/o any network access (odd situation, don't ask.)

[zwei]

Just sharing some of my experience with the library parts...

Library COTS parts is like a can of worms for us...
We have a library but only a handful people really use it...

One of the main reason is because we have several CAD software and version. (what software we use will depend on our customer)...
For some reason, mixing different version file in SOLIDWORKS seem to cause a lot of performance issue...

We tried using configuration for some of the screws, but that also caused a whole lot of issue with our PDM

Not to mention sometimes some of the customer want to use their own pn/CAD for those COTS parts...

So in the end what we normally did was:
1. Store all the COTS file use in a project in an assembly (eg: Assembly with all screw use in the project)
2. Whenever user want to add some hardware, there will search in the assembly first.
3. If the hardware is not in the assembly, then the user will access whether to add a new hardware or adjust the design

Other best practice that we are also trying to implement on COTS part:
1. Whenever possible, have the user to download the COTS CAD as SOLIDWORKs file (STEP file can be a performance hit sometimes), after importing the file, group the feature in a folder and renamed as "IMPORTED" so that other do not edit..
2. Have the user defeature the CAD if needed (eg: remove spherical ball in ball bearing, remove thread, etc etc)

Not the best practice, but it work better than i expected.

[Glenn Schroeder]

Many of my projects use the same Parts, so I have a large library of them that are used by multiple projects. Much of it is hardware, with bolts, nuts and washers. Almost none of the bolts have threads modeled, and the few that do have them only to show in the occasional drawing, so there's always a configuration with the threads suppressed that's used in assemblies.

Occasionally I have a project that uses an off-the-shelf component that I haven't needed before. In those cases I will download the file from McMaster-Carr if it's available. I will add my custom properties, and also clean up the model if I just can't stand leaving it as-is.

[mattpeneguy]

Posts like this and the ZTG one make me wonder if we need a "can of worms" emoji.
The answer to this question really depends on what you do. If you've got an ERP in place, you may have very strict requirements that no part has more than one configuration. I like to use a single bolt file with many configurations... But someone like @AlexLachance may not be able to do that because his ERP system may not handle it well.
So, the "best practices" may be workflow dependent...I have my old SW Bible at work, @matt, seems like this may have been in there? If I remember I'll look tomorrow.

[Glenn Schroeder]

Posts like this and the ZTG one make me wonder if we need a "can of worms" emoji.
The answer to this question really depends on what you do. If you've got an ERP in place, you may have very strict requirements that no part has more than one configuration. I like to use a single bolt file with many configurations... But someone like @AlexLachance may not be able to do that because his ERP system may not handle it well.
So, the "best practices" may be workflow dependent...I have my old SW Bible at work, @matt, seems like this may have been in there? If I remember I'll look tomorrow.

I also have multiple configurations in my bolt files, but it's not a single file. That would run into hundreds of configurations and I don't want to deal with that. I have a single Part file for each bolt diameter, with configurations for different lengths.

[mattpeneguy]

Posts like this and the ZTG one make me wonder if we need a "can of worms" emoji.
The answer to this question really depends on what you do. If you've got an ERP in place, you may have very strict requirements that no part has more than one configuration. I like to use a single bolt file with many configurations... But someone like @AlexLachance may not be able to do that because his ERP system may not handle it well.
So, the "best practices" may be workflow dependent...I have my old SW Bible at work, @matt, seems like this may have been in there? If I remember I'll look tomorrow.

I also have multiple configurations in my bolt files, but it's not a single file. That would run into hundreds of configurations and I don't want to deal with that. I have a single Part file for each bolt diameter, with configurations for different lengths.

That's why God created design tables.

[CarrieIves]

We currently are storing everything on our network drives by project. We have been bringing any anything we need for a specific project and saving it in that project's folder. If I have used it somewhere else, I will copy it to the new project. We do work for a variety of customers so each project is likely to be its own completely separate design.

If I worked a for a company that made things for ourselves, we would definitely set up a library. I would expect to have it sorted into folders by type of component so it was easy to find if the component already existed. I will also say that companies that have bought others, may have very different part numbering schemes and more than one part number for what is essentially the same part. One place I worked had a board on the manufacturing floor (or near it) with samples of different hardware and the part number listed underneath. That made it much easier to determine if the hardware I needed already existed and what the part number was. A good search tool on the part number database would have also been a help. I don't remember if that was one of the companies that I worked for that used a very old database that tied all the parts, bills of material, options, sales orders, and specific things being built together. I had a cheat sheet for the commands since there was no GUI for that.

[HerrTick]

• Always check downloaded models vs. drawings and known part.

• Always check downloaded models vs. drawings and known part AGAIN if it's an electronic item. Those guys are just plain sloppy!

• Don't be shy about including documentation. Add vendor docs to Design Binder. Maybe throw a small screen shot pic into the model for quick reference.

• Use multibody parts for anything that is rigid or static but has multiple pieces. Why compound your file management problems?

[Glenn Schroeder]

Posts like this and the ZTG one make me wonder if we need a "can of worms" emoji.
The answer to this question really depends on what you do. If you've got an ERP in place, you may have very strict requirements that no part has more than one configuration. I like to use a single bolt file with many configurations... But someone like @AlexLachance may not be able to do that because his ERP system may not handle it well.
So, the "best practices" may be workflow dependent...I have my old SW Bible at work, @matt, seems like this may have been in there? If I remember I'll look tomorrow.

I also have multiple configurations in my bolt files, but it's not a single file. That would run into hundreds of configurations and I don't want to deal with that. I have a single Part file for each bolt diameter, with configurations for different lengths.

That's why God created design tables.

I have had excellent luck with the simplified design tables that we reach by right-clicking on a feature (or dimension) and selecting "Configure feature" (or "Configure dimension") from the drop-down. Excel-based ones, not so much.

And even if they worked perfectly, I still wouldn't want all my hex head bolts in one Part file. I just checked. My 5/8 bolt file has 23 length configurations. I have 14 hex head bolt Part files. Admittedly 5/8 is at the upper end of the number of configurations, but even if they average 10 configurations (which is probably a low estimate), that's still quite a few.

Having said all that, if you have (or someone else has) a file with several hundred configurations that works just fine, I certainly wouldn't say "You're doing it wrong!"

[KevinC]

Hello,

We use McMaster fairly often and usually as-is, as our fastener counts are generally too high.

Internally, we use the McMaster part number, as do some of our customers.
Their files are set up for config to display the Mc p/n in the BOM w/o any added effort.

For bulk fasteners purchases, our reps take Mc p/n's in an RFQ and furnish equals w/their p/n (although the Mc p/n remains in model and in drawing).

For all commercial downloads, I recommend setting up a folder structure by type outboard of the project so future downloads of the same type aren't scattered and it's easier to find a previously download part.

I've only mention McMaster, but this applies to any available purchased part model.

Kevin

[jcapriotti]

Having said all that, if you have (or someone else has) a file with several hundred configurations that works just fine, I certainly wouldn't say "You're doing it wrong!"

Our fasteners have up to 200 configurations. Been working that way since 1998. Generally we have a separate file for each type of fastener, material, and finish. So the configurations are just sizes. Design tables manage it and if we need to add a custom property, its easy to add a column and apply it to all configurations. Downside is the file size, especially if you are rebuilding most of the configurations.

[mattpeneguy]

Hey @Glenn Schroeder (and anyone else),
Try dropping this fastener into an assembly and see what you think. If you use Configuration Publisher, you can have it filter the size and then the lengths for that size. Best of both worlds, IMO. If you need to change it right click it and select "Configure Component" (top right icon) to get the dialog back.
If people are interested, Hawkridge has a nice how to:
https://hawkridgesys.com/blog/how-to-us ... -publisher

[Frederick_Law]

Each version of SW NEED its OWN folder for hardware/library files.
I had 4 version of SW running.
Don't put them on network. Sync them daily. Only admin can add to the folder. To make sure all properties are filled in.

[bnemec]

Having said all that, if you have (or someone else has) a file with several hundred configurations that works just fine, I certainly wouldn't say "You're doing it wrong!"

Our fasteners have up to 200 configurations. Been working that way since 1998. Generally we have a separate file for each type of fastener, material, and finish. So the configurations are just sizes. Design tables manage it and if we need to add a custom property, its easy to add a column and apply it to all configurations. Downside is the file size, especially if you are rebuilding most of the configurations.

Ok, now I'm following this. Where I work we are headlong down the hardware configuration file tunnel. Not only do we have dozen lengths/grades for a HHCS of a certain thread, we also have various finishes and locking patches. And the patch isn't just true/false, due to situations patch has type, start thread, stop thread and degrees of coverage. I'm still worried about what part of our configured hardware files will be the "learning experience" some day.

[mattpeneguy]

@bnemec,
Have you downloaded my file above? Seems like it could help in your case immensely. There's also DriveworksXpress you could look into.

[matt]

...I have my old SW Bible at work, @matt, seems like this may have been in there? If I remember I'll look tomorrow.

My best practice stuff tended to be very general, since I was usually talking to a wide range of industries. I would only get specific when I did consulting for a specific company, and they asked for a set of recommendations. Best practice varies a lot from one place to another, and can even be contradictory depending on what kind of work people are doing.

Everybody thinks they have a reason for breaking the rules or going against general best practice.

The real truth is that if you're good enough you can get away with anything, aside from bugs and limitations. Best Practice is meant to be inclusive, so that even the noobies can work with your models.

I think the books did have some best practice mentions sprinkled through out, but I don't remember a single all-inclusive list, except maybe in the Administration Bible, which, as Curt Cobain said, most of you didn't buy. I did a number of user group presentations, but all of that stuff is pretty old, and again, non-specific.

[zwei]

Each version of SW NEED its OWN folder for hardware/library files.
I had 4 version of SW running.
Don't put them on network. Sync them daily. Only admin can add to the folder. To make sure all properties are filled in.

This sound interesting....
If you keep 4 folder, do you have them as the same file name? Eg: 12345.sldprt (SWX2016), 12345.sldprt (SWX2018).
Asking this because my initially thought is to have something similar, but ditch the idea halfway because we are using file name as our PartNumber and our PDM dont like non-unique file name

[bnemec]

@bnemec,
Have you downloaded my file above? Seems like it could help in your case immensely. There's also DriveworksXpress you could look into.

Yes. We have something like that, I think. There is a lot of functionality in Solidworks around configurations the we just don't know/understand yet. Setting up configured hardware isn't exactly covered in the 5 day SW classes.

The features and variables are not done quite right in ours so the design table has columns that should be condensed.

We do not include the washer and nut as there are limitless combinations if those are added in.

Our SCREW.sldprt file is about 6MB in size and the design table takes about 30 minutes to load. We just started the file a few months ago. We already see a bunch we did wrong with it, but still need to learn more about using configurations for this purpose before a revamp. Also concerned about how to do that without breaking mates and/or annotations, ie. only edit the features that exist, no deleting existing. If I understand that correctly.

[Frederick_Law]

This sound interesting....
If you keep 4 folder, do you have them as the same file name? Eg: 12345.sldprt (SWX2016), 12345.sldprt (SWX2018).
Asking this because my initially thought is to have something similar, but ditch the idea halfway because we are using file name as our PartNumber and our PDM dont like non-unique file name

Yes, I don't use PDM.
They're under different folders for each SW version.
Of course I need to setup file location properly.
Also need to relink when I move it from on version to next.

[HerrTick]

Helps to have custom properties for source and source p/n.

[bnemec]

Helps to have custom properties for source and source p/n.

sometimes. We did that when Endries was the in-house supplier, guess the number of non-value-added hours spent updating stuff and how many were missed when Purchasing decided to switch to Fastenal. Depending on the scenario, it is sometimes best to let ERP, MRP, SCM, (or some other acronym) manage, sort, filter and search that data and just let CAD to CAD stuff.
Like Matt said, we all find reasons to deviate from best practices. It sounds like "best practices" really mean "This specific software will perform the best if you do these things and not those things." Unless CAD is the only link in the chain, then it's best practices may not be the over ruling factor. I wish it were, I really do.

[Tom G]

Nearly all my assembly components fit your description of commercial parts - we are assembling and not making that piece, except for structural weldments and pipe / tube.

My library is categorized by folders into major part types, sometimes secondary part types, then by brand, and if necessary further within per context.

"DL > Valves > Ball Valves > [Manufacturer Name]" contains all sizes of valves in all specifications by that MFR. Some configured, and some singular.
"DL > Hardware" has lots of components named to sort by size - most of which were downloaded from McMaster-Carr.
"DL > Fittings > Swagelok > Straight Adapters (MNPT x tube) > 1-2 in tube" contains all thread sizes for a 1/2" tube male threaded adapter.

My broader point here is that you need some rules, but not all rules apply across all categories. Tailor your DL organization to reflect how it's used.

If my model really sucks, like scaled from a terrible drawing and given only two dimensions, then it doesn't get added into library until the product is received and inspected. Sometimes I have a placeholder component which will be replaced with one that the MFR eventually will provide me, which sometimes is delayed until after we place the order for it. The part lives in a Subcomponents folder within the project it belongs to, until it's good enough to belong in the library.

I liked @HerrTick 's use of the Design Binder for extra documentation. Personally, I prefer to include file hyperlinks in custom properties for this purpose: Source, Contact, CutSheet, Manual, AltManual1 ... , MSDS, etc. Properties are tiny, but design binder contents increase the file size.

[HerrTick]

Helps to have custom properties for source and source p/n.

sometimes. We did that when Endries was the in-house supplier, guess the number of non-value-added hours spent updating stuff and how many were missed when Purchasing decided to switch to Fastenal.

Firstly, I would consider that properties as reference only, subordinate to whatever specs or drawing or MRP or other documentation says.

Also, this applies more to non-hardware parts. Hardware can come from anywhere. Hardware is spec-driven, not catalog-driven. That's one of the defining characteristics of "hardware" vs "part".

[Lapuo]

We use separate parts for all components because of ERP system.
So for example we will have separate parts for bolts which are same size (but one of them is galvanised steel , other one is not etc... )

[AlexLachance]

Posts like this and the ZTG one make me wonder if we need a "can of worms" emoji.
The answer to this question really depends on what you do. If you've got an ERP in place, you may have very strict requirements that no part has more than one configuration. I like to use a single bolt file with many configurations... But someone like @AlexLachance may not be able to do that because his ERP system may not handle it well.
So, the "best practices" may be workflow dependent...I have my old SW Bible at work, @matt, seems like this may have been in there? If I remember I'll look tomorrow.

There's always ways to work around things. Thankfully the SW-to-ERP module we have was built in a close relationship between me and the programmer who worked on it, so having multi-config bought components was one of the thing I had to work around.