Rule in Subassembly Doesn't Trigger from In-Place Edit

[jtylerbc]

I have an issue I'm trying to solve with one of our iLogic rules.  I'm stumped, throwing it out here for suggestions.  This is a problem we've actually had for a couple of years now, but previously only two people were commonly using the files that cause it.  Now more people are beginning to use it, increasing the possibility of mistakes being made by those who don't understand the quirks of how it operates.  I'm trying to resolve the problems before they happen.

The scenario is this:  Top level assembly, Subassembly, Parts.  The Subassembly contains the rule.  The rule triggers before save. 

The rule gathers information from the parts to generate the Part Number of the subassembly (which is sort of a model code).  The rule itself works flawlessly.  However, there is a very common scenario when the rule doesn't run at all, which has the potential to result in an incorrect Part Number.

The problem is that the parts in the subassembly are often in-place edited from the top level assembly to adjust their geometry in context.  When this is done, the subassembly doesn't seem to get "dirtied", so Inventor doesn't default to saving it. 

If you save the subassembly while still in the in-place edit, the rule works fine.  If you return back out  to the top level assembly, save it, and force it to save the subassembly (even though it defaults to not saving), it will work.  But in-place editing is the most common way to work with these files, and that's what is unreliable. 

Does anyone have any suggestions for how I could get this to trigger after an in-place edit?

[chandra.shekar.g]

@jtylerbc,

Try to run below iLogic rule to trigger before saving top assembly. The code triggers rule from subassembly in top assembly.

iLogicVb.RunRule("SubAssembly:1", "ruleName")

For further investigation, can you please provide sample assembly files to test? also steps to trigger the rule.?

Please make sure that files are non confidential.

Thanks and regards,

[jtylerbc]

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.

[MechMachineMan]

@jtylerbc

It's possible it's something in your code that's causing it to skip.

I just made a dummy assembly with a top level. In a sub-assembly I added a message box on save to the sub-assembly.

I did an in place edit on the sub-assembly, quickly changed some model geometry, then returned to top level.

After clicking the save button, the save for the sub-assembly was already set to yes. When I pressed okay, it ran the rule appropriately in the sub-assembly.

So it DOESN'T look like it's an issue of the file not dirtying... unless there are specific cases that make it behave oddly.

[jtylerbc]

@MechMachineMan, that's certainly possible.  Complicating matters slightly, I didn't write the assembly-level code (a former coworker did), so I'm not extremely familiar with it.  However, I think it's also possible that you're not exactly duplicating my scenario.

Just to make sure we're speaking the same language as far as testing:  In-place-edit twice to get down to the part in the subassembly.  If you actually edit something directly in the subassembly, the rule runs and everything updates as expected.  I have on occasion used this to force the rule to trigger by making an insignificant change (such as rotating a cylindrical part about its own axis) before returning back to the top level.

In actual use, the part is edited in-place two levels deep from the subassembly, then you return back to the top level and save.  The top level assembly and the part will show as needing a save (defaults to Yes), while the subassembly will default to No. 

Typically, no changes are made at the assembly level.  If there are changes made at that level, it is generally to swap out end fittings, in which case the problem goes away because the sub will want to save anyway.

Interestingly, the rule is triggered properly when changes at the top level force a change via Adaptivity.  As a result of this, larger geometric changes to the model as a whole generally update correctly, while tweaks specifically to the hose's sweep path do not.  This means that large errors in hose length are generally prevented, but smaller errors are incredibly easy to create.

[MechMachineMan]

@jtylerbc

In place editting twice made no difference; all files still want to save and all rules fire appropriately.

Are you on 2018.2.3?

If so, I'm really thinking it's your code or that your even triggers aren't set up quite how you think they are.

To reiterate, here's my structure that works just fine.

Top Asm

- Asm 1 - OnSave runs rule in Asm1 that shows a msgbox

- - Part 1 - OnSave runs rule in Part1 that shows a msgbox

When i edit in place down to part 1, then click return twice, then click save, it prompts for all 3 files to save.

[jtylerbc]

Forgive the silliness of the attached example - we don't typically run hydraulic lines between ports on a piece of plate, but it's an easy way to show what is happening.  If you get any Unresolved References, it is probably just an iPart child looking for its mommy, and isn't really part of the problem.

The sample file set consists of an assembly containing a plate with a couple of SAE ports.  Elbows are installed in the ports, and a hose subassembly connects them.  When viewed from the Top view, the upper left elbow is constrained angularly, while the lower right one is not.  For the purposes of the example, a message box has also been added to let you know when the "Hose Assembly Number" rule runs, so you don't have to check the iProperties every time.

Test 1

• Look at the iProperties of the hose subassembly (Test-HS-01.iam).  The last portion of the part number is a cut length for the hose material.  In the sample provided, the initial length is 73.50 inches.
• Use Grip Snap (or add an angular constraint) to rotate the elbow in the lower right port by any arbitrary amount you choose. Note:  The cut length is rounded to the nearest 1/4", so don't make the rotation angle extremely small or the cut length update might disappear into the rounding error.
• Save the assembly.
• Check the Part Number of the hose subassembly again - note that the cut length has now changed.  You should also see the message box.

This test demonstrates that the rule runs as intended when geometry changes are forced by the top level assembly.

Test 2

• Note the cut length obtained by your change from Test 1 for comparison.
• Edit the hose assembly in-place, then edit the hose part (Test-HS-01.ipt).
• Under the "HoseSweep" feature, edit "3D Sketch1".  This sketch makes up most of the sweep path for the hose.
• The spline has a control point added to it.  Move that point (or delete it) to change the path length by a noticeable amount.
• Finish the sketch, then Return to Top without making any changes at the subassembly level.
• Click Save.  Note that Test-HS-01.iam defaults to "No", which results in the rule not running, the cut length not updating, and no message box.

This test demonstrates that the rule does not run after an in-place edit on the hose part.

As for software versions - This has been a known issue we've been living with in Inventor 2016.  We are in the process of updating to 2018.  My test laptop is up to date with 2018.2.3, with no change in the behavior we've been used to from this rule. 

[MechMachineMan]

Hmm. Weird. I see what you mean.

However, if you go into Application options > Save > Prompt To Save for Recomputable Updates, it will prompt to save, thus "fixing" the issue.

[jtylerbc]

---

@MechMachineMan wrote:

Hmm. Weird. I see what you mean.

However, if you go into Application options > Save > Prompt To Save for Recomputable Updates, it will prompt to save, thus "fixing" the issue.

---

It is strange.  The creator of the rule was aware of the issue when we first introduced it, but for a long time it was just the two of us using it.  So long as that was the case, fixing it wasn't that high of a priority because we knew how to deal with the quirky behavior.

That is interesting.  Not sure I like it as a permanent fix because it's difficult to enforce across the department, but it does seem to solve the issue.  I'm going to suggest it to those currently working on hydraulic projects as an interim solution while continuing to search for a more reliable (less user-dependent) one.

[chandra.shekar.g]

@jtylerbc,

In top assembly, try a iLogic rule which runs iLogic rule of sub assembly. It also triggers on saving top level assembly. For more details, refer the screencast record in the below link.

https://autode.sk/2q3oDzz

Thanks and regards,

[MechMachineMan]

@chandra.shekar.g

I think the underlying issue is that inplace editting the adaptive hose and then returning to the containing assembly does NOT dirty the document with the "editted" flag as seen through the Diagnostics Window (About > Ctrl+D) whereas rotating a fitting does.

Can you explain this behaviour?

It would make sense to me that the "editted" flag would change because although the transformation of the child part didn't change in the containing assembly, the containing assemblies MASS, VOLUME, and AREA would have all changed, which seems like it should have been enough to make it more than just a simple "recomputable update".

Note: After saving, then editting the hose in place & moving the spline of the sweep, the only Diagnostics flags that are set IN THE ASSEMBLY are "View Change" and "Update", which don't seem to be classified as more than a "recomputable update" by Inventor.

Your suggested solution of running the rule doesn't really do much to solve the problem as the problem is the fact the rule isn't TRIGGERED properly to begin with, so even if they added in the rule at the top level to run the sub rule, I don't think it would accomplish their desired outcome.