How does Solid Edge Family-of-Parts differ from Solidworks configurations?

[mike miller]

I understand there are some key differences, but I would like to hear from users who have experience with both. Do you prefer one over the other?

@Ry-guy
@matt
@uk_dave

[matt]

If you go to my dezignstuff.com website I have a write up on Toolbox. It's basically a text on the evils of SolidWorks configurations.

Solid Edge approach is far more conservative, but it's a lot less risky. Again emblematic of the differences between the two companies.

[bnemec]

If you go to my dezignstuff.com website I have a write up on Toolbox. It's basically a text on the evils of SolidWorks configurations.

Solid Edge approach is far more conservative, but it's a lot less risky. Again emblematic of the differences between the two companies.

@matt , That's disheartening to hear as we took the leap of faith and manually built out most of our hardware parts as configs in several files, SCREW.sldprt for example. You say "...evils of Solidworks configurations" I hope that's just in context of using toolbox and that hand made configured hardware files can be good if done properly?

I searched your website for toolbox and got a lot of results, you seem to have a fondness of it?

Hope you don't mind posting a screen shot of one of your blogs here: If this is a joke, I think I get it, and made me chuckle.

Continue reading, nope, looks like other image links were broken too. Anyway, aside from the blog that is an excerpt from the sw bible on toolbox most shine a negative light on toolbox for multi user environment.

If I search for "configurations" I get two articles named similar to Configurations VS Family of Parts

from May 2012
https://dezignstuff.com/configurations- ... -of-parts/

from Nov 2013
https://dezignstuff.com/configurations- ... -round-1/

[Glenn Schroeder]

@matt , That's disheartening to hear as we took the leap of faith and manually built out most of our hardware parts as configs in several files, SCREW.sldprt for example. You say "...evils of Solidworks configurations" I hope that's just in context of using toolbox and that hand made configured hardware files can be good if done properly?

I searched your website for toolbox and got a lot of results, you seem to have a fondness of it?

Hope you don't mind posting a screen shot of one of your blogs here: If this is a joke, I think I get it, and made me chuckle.
image.png

Continue reading, nope, looks like other image links were broken too. Anyway, aside from the blog that is an excerpt from the sw bible on toolbox most shine a negative light on toolbox for multi user environment.

If I search for "configurations" I get two articles named similar to Configurations VS Family of Parts

from May 2012
https://dezignstuff.com/configurations- ... -of-parts/

from Nov 2013
https://dezignstuff.com/configurations- ... -round-1/

Far be it to disagree with Matt, but my hardware files have multiple configurations and it works just fine (and has been for about 10 years). I'll be happy to help with any questions you have about them.

[matt]

Far be it to disagree with Matt, but my hardware files have multiple configurations and it works just fine (and has been for about 10 years). I'll be happy to help with any questions you have about them.

It's actually more fun when people disagree. Part of my schtick when I write about opinionated stuff is point of view. When you see a cloud from one hilltop, it looks like a bunny rabbit. From a different hilltop it looks like an airplane. Even best practices can be seen differently by people who use the software differently. So don't be afraid to say something different.

My point of view came from doing support for customers who would install Toolbox with all of its defaults, and then eventually someone opened up an assembly where all the screws reverted to the largest configuration available because they didn't have the same configs in their model that everybody else had in theirs.

And then there's PDM. Configs can work with PDM, but you have to be very disciplined, because the software doesn't keep track if your changes effect this config or that config.

[Glenn Schroeder]

It's actually more fun when people disagree. Part of my schtick when I write about opinionated stuff is point of view. When you see a cloud from one hilltop, it looks like a bunny rabbit. From a different hilltop it looks like an airplane. Even best practices can be seen differently by people who use the software differently. So don't be afraid to say something different.

My point of view came from doing support for customers who would install Toolbox with all of its defaults, and then eventually someone opened up an assembly where all the screws reverted to the largest configuration available because they didn't have the same configs in their model that everybody else had in theirs.

And then there's PDM. Configs can work with PDM, but you have to be very disciplined, because the software doesn't keep track if your changes effect this config or that config.

I'm definitely not afraid to disagree, but I try to be respectful about it.

I abandoned Toolbox years ago, for a variety of reasons. Many of my library Parts started out life as Toolbox parts, but I removed the Toolbox designation from them and moved them to our network drive.

My experience with PDM is exactly zero, so I can't address how that affects anything.

[bnemec]

And then there's PDM. Configs can work with PDM, but you have to be very disciplined, because the software doesn't keep track if your changes effect this config or that config.

That is one of our concerns with configs right now. Fortunately we only need to edit hardware files a couple times a week so it's something that can be controlled by just two or three people instead of wide open.

I got the feeling from the articles that the toolbox generated configurations were the problem. Nor so much configs in and of themselves.

Concerning Solid Edge POF, we seldom used them because of file refs, (same reason we don't use top down modeling methods, parts live forever and have many where used) If I recall correctly, and someone please correct me, Solid Edge Family of Parts was a master part file with all the "configurations" that would manage the "children" files that were just dumb solids. As Matt pointed out, Solid Edge doesn't keep all of them in on file, I'm pretty sure the configurations must be populated out into files. I became a little familiar with them while working on indexing file refs. SE files track referenced files (like a assembly references components or a mirrored part references back to the file that was modeled) but also sometimes keep track of files that reference it. Like "reverse" references. This is how the master or "parent" in a FOP has an awareness of the "children" that reference it. The parent needs this to be able to tell the children to update. I think the children are just automated part copies of a certain "config" in the master part.

[mattpeneguy]

I'm definitely not afraid to disagree, but I try to be respectful about it.

I abandoned Toolbox years ago, for a variety of reasons. Many of my library Parts started out life as Toolbox parts, but I removed the Toolbox designation from them and moved them to our network drive.

My experience with PDM is exactly zero, so I can't address how that affects anything.

I disrepectfully disagree with this approach!

The big benefit to having all your screws, bolts, nuts, whatever in one file is that you can quickly and easily change size, and because all the geometry is the same it updates correctly. I don't do it exactly as Glenn does. I like to have ALL my body diameter and lengths in one file. I believe he has it broken down by body diameter files. Either way works, but if you go my route, definitely look into Configuration Publisher, it makes sorting much easier (you can select the body diameter from a drop down, then only the lengths of that diameter are available in the Length drop down, much easier than sorting through 1000 configs).

Though, I can easily see Matt Lombard's point about data management. It's all pros and cons, and ya gotta find works for your workflow.

[Arthur NY]

Having to do a 90 presentation about Toolbox a while back, having only dabbled here and there over the years prior, definitely gave me a new set of eyes and appreciation. Much like Matt I helped out many a customers get their Toolbox set up while doing tech support at a VAR. There are a few base things that caused numerous "bad implementations" of the ToolBox.

1) Back in the day: Solidworks did a horrible job and installing and guiding people how to properly set up the methods by which the hardware could be used. One of THE biggest bumps in the road was local vs network location for storage of new configs once hardware/sizes were generated by a users.

2) The Toolbox NEEDS to be configured so that hardware that's never used isn't available to users.

3) The Toolbox is one big excel sheet of configurations. It is 100% possible to actually go in and generate every possible piece of hardware possible. BUT that's a waste of time, effort, AND disk storage space. Based on the above #2 approach, IF this had to be done then it should only happen after the unnecessary hardware is eliminated. It is even possible to export out said excel sheet and add any company specific information and then import that back.

4) ...I've got more but it's late and I have an early day. More toolbox TBC

[KennyG]

I disrepectfully disagree with this approach!

The big benefit to having all your screws, bolts, nuts, whatever in one file is that you can quickly and easily change size, and because all the geometry is the same it updates correctly.

Solid Edge's approach gives you the same benefit. Since the source body is the same, relationships are mapped to the same faces and thus update reliably on replacement of another member, and since all members are linked to the same master, when you replace a member in an assembly, it will present you with a list by default of the other members of which you can choose. Really comes down to method of storing the members... all in one file or all in linked reference files.

[matt]

....I got the feeling from the articles that the toolbox generated configurations were the problem. Nor so much configs in and of themselves.

The configurations in toolbox are only a problem if everybody doesn't have the same ones. The way Toolbox installs by default is that everybody gets their own library, and the libraries start out unpopulated. Each size is created for each library as it is needed. So if one person needs a 1/4" and another person needs a 1/2", then they trade assemblies, they don't have the correct sizes.

There are ways to do this correctly, but the default setup is the WORST POSSIBLE arrangement, and people would open an assembly and get HUGE SCREWS. I think they did eventually fix this bug, but it persisted for over a decade, and A LOT of customers lost A LOT of assembly fastener data because of this.

My objection to combining configurations with PDM is different. I think if you're going to control revisions on a configured part, with each configuration as a separate part number, you need to use separate files. If you delete a plane in one configuration, it is deleted in ALL configurations. If you change a dimension, the PDM software doesn't know if that affected all configs or just the part number you're working on.

SolidWorks did a nice job of creating a lot of cool functionality, but they never thought down the road about what to do when you combine the methods. Like in-context and configurations, or in-context and PDM or the freeze bar, or ... lots of ors...

That's why in general, except for special situations, I prefer the Solid Edge FOP method, even though it's less convenient, it's also less dangerous. This is another one of the differences in the products that sums up the differences in the companies. Fast and loose vs careful and much safer. One plans ahead, the other is full speed ahead without consideration for the consequences. You have to figure out the consequences for yourself. Which is great if you already know everything, but new customers fall into the demo trap every time. It looks good in the demo, so we're going to build a company's entire modeling strategy around flashy demo techniques.

[jcapriotti]

My objection to combining configurations with PDM is different. I think if you're going to control revisions on a configured part, with each configuration as a separate part number, you need to use separate files. If you delete a plane in one configuration, it is deleted in ALL configurations. If you change a dimension, the PDM software doesn't know if that affected all configs or just the part number you're working on.

I think there are a couple of ways to do this in PDM.

1. Fasteners have a data card where the revision can be different per configuration. You have to edit the whole file (new version) but you only change the revision on the configuration affected. In general, a fastener change wouldn't happen often, if at all.
2. Part family numbering for a given fastener type and all configurations share the prefix number and all have the same revision. This is what we do. The file changes frequently to add new part numbers to sizes as needed for new designs.

Our fastener files are over 20 years old, most were created in 1997-1999

[matt]

1. Fasteners have a data card where the revision can be different per configuration. You have to edit the whole file (new version) but you only change the revision on the configuration affected. In general, a fastener change wouldn't happen often, if at all.

Personally, I would not assign a revision to a library part, especially if it is purchased.

The point was really that there is no guarantee that your change to one configuration doesn't affect other configurations. If I were CAD admin, I would not assign separate revisions to configurations at all, even if the PDM allowed it.

[Jim Elias]

My point of view came from doing support for customers who would install Toolbox with all of its defaults, and then eventually someone opened up an assembly where all the screws reverted to the largest configuration available because they didn't have the same configs in their model that everybody else had in theirs.

Yes, there can be quite a few unpleasant surprises when the toolboxes don't match. The paradigm is definitely not ideal.

FOP has a lot of arguments for it -- but often in the context of something that is already done. A cap screw doesn't need to be engineered, it only needs to be modelled. Where SW configurations shine for me is during the what-iffing phase of layout and part conceptualizing -- but later on, discipline needs to take over and clean-up of both configuration structure and model tree needs to occur.