Flexing sub-assembly relation-driven parts in top-level assembly

[ndele]

We're using Creo 8.0.6.0 at this time.

I'm running into an issue using a relation-driven sub-assembly, but feel like it's close. The first stud & nut in the patterns aren't flexing properly, but the rest are and I'm unsure what the issue is. I've changed & moved relations around, added and removed flexible dimensions/variables up until this point, this is the closest I've gotten.

Some background: we originally used a family table for all of our stud & nut assemblies but found a few issues using them - they often really slowed down our large assemblies, and sometimes ran into odd regeneration issues. I've taken a look at intelligent fasteners, but I don't think it has what is required.

We're testing using a single sub-assembly that drives the part dimensions of the stud and nut. FLG_CALLOUT and GASKET are restricted, string parameters that are pre-flexed. Users can change them via a drop down menu. These two parameters will be changed when added to an assembly, with relations on the sub-assembly level driving the changes. This will change the stud location, depth, size, and quantity, along with the nut.

I also included some of the relations I used (I need to clean this up, but any suggestions are also welcome). Originally I placed the relations in the parts so that certain string parameters (STUD_VAR & NUT_VAR) would be variable. Those string parameters would be read and that information placed in integer parameters. Then using formulas, a real-number parameter would be generated that would control the part dimensions. I tried making it so the sub-assembly relations would change the part variables, but found the last placed sub-assembly in the top-level assembly would modify all the other sub-assemblies parts placed in it (ex: all studs would be Ø1" X 6" long as per the last assembly added). Moved those relations to the sub-assembly and set up sub-assembly parameters and this is where I'm at currently.

99% of the time, we want the user to use the flange size & pressure rating to specify the size, but I also wanted to create a custom size/length option as well (IF FLG_CALLOUT == "CUSTOM", then some other, changeable parameters will drive the STUD_VAR & NUT_VAR), as sometimes the connections aren't standard flange-to-flange connections.

Thanks for any guidance, happy holidays!

[ndele]

 

 

 In case the images didn't load properly, I can never get the preview to work properly.

[pausob]

Hmm, if you were troubled by longer regeneration times when using family table instances, then this new solution that uses flexible components - it will have similar problems.  In my experience, flexible components will cause strange slow-downs and the inexplicable need to regenerate assemblies upon retrieval (I mean, they were stored while the "green light was on" ?!?)

And after all, flexible components are basically "behind-the-scenes-family-table instances" so that your report of these wonky cases where already existing instances adopt the state of the last one placed does not surprise me.

[ndele]

Ahh, that is quite unfortunate.

Yes, we had a family table for the studs, a family table for the nuts, and a family table of them patterned together. Yes, it was green light on when we checked it in, but I found something about reference patterns that caused issues occasionally if we added a cut to the model (we have found about zones, but sometimes custom cuts are required).

The current test only has 3 different flange configurations with many more to add. Was hoping with less parts in memory, hopefully the regeneration would be better. Once the initial stud/nut issue is resolved and the other flange sizes added, I'll update this on how the test goes for regeneration times / general usage.

[tbraxton]

If you are looking for a way to decrease regeneration time, then a couple of things to consider come to mind. Notebook (formerly layout files) can be used to configure your flange, bolt pattern etc. at the top level of your design. You should be able to put all of the needed relations in the notebook file. Notebook do not contain any geometry and regenerate very fast. The notebook is then declared to any file that needs access to the parameters/relations. You can even define assembly constraints via notebooks, Notebooks can be undeclared at any time.

I have been told that there are Windchill issues with using Notebooks so check that out if it matters for your scenario.

The other option is to set features/models to read only when they are stored such that they are not regenerated when retrieved in the future.

[ndele]

Hey tbraxton, thanks for the reply. I haven't heard of notebooks, so I will definitely check it out. That sounds like it would be really handy.

We currently have the configuration settings/option set to ignore read only objects, but still find it takes a lot of time to go through the objects. Perhaps something more to explore though.