Announcements
Attention for Customers without Multi-Factor Authentication or Single Sign-On - OTP Verification rolls out April 2025. Read all about it here.
jtylerbc
in reply to: chandra.shekar.g

Will try to work up a simple example later today.  This is part of a home-brew flexible, Adaptive hose modeling system that we developed before we gained access to Inventor Professional.  We continue to use it currently because it works well enough for our purposes, and our hydraulic work is infrequent enough that we haven't yet gotten around to customizing Tube & Pipe to suit our needs.  The technique consists of (at least) three levels:

 

  1. Top level assembly, which contains all the hoses as well as other hydraulic and structural components.
  2. Hose Subassembly, which always contains exactly three parts (the hose material itself, and two end fittings).
  3. Hose Part.

The hose part contains a rule that assigns values to parameters based on the part material.  The rule also writes the part's volume to a parameter, which is then used to calculate the hose's cut length.  This rule is triggered before save, on geometry change, and on material change.  It has no known performance issues.

 

The hose subassembly contains a rule that compiles information from the hose part and the end fittings, to produce a "model code" based on a company standard, and assign it to the Part Number property.  This rule is set to trigger before save.  It works properly if the hose assembly is opened and edited separately.  It will also work during an in-place edit if manually forced to run.  However, it will not trigger automatically during an in-place edit, and there is no equivalent "geometry change" trigger for an assembly rule.

 

There is a practicality issue with your proposed solution.  I think it would work in a specific case.  However, these rules exist in template files that are used repeatedly, and there is no way to predict in advance what the subassembly's name will be, so it doesn't work well for a general case.  This means that the triggering rule would have to be edited individually for each assembly, which makes it even less friendly for infrequent users than our current methods.

 

Perhaps if it could iterate through all subassemblies and run the rule in any subassemblies where it exists, that could solve the problem.  I tried setting something like that up a few days ago, but didn't get it to work.  I didn't spend that much time on it, and was probably just doing something incorrectly.