Frame Generator - Members Rotated 45 degrees G_L won't update

[Curtis_Waguespack]

We just ran into an issue with Frame Generator where components placed rotated (at 45 degrees in this example) will not update the length. Components placed not rotated update as expected.

Is this a known issue? We checked this in Inventor 2015 and Inventor 2017 and see the same results.

Results:

Video of the issue:

Dataset:

FG_45 Deg Bug.zip (2,262 KB)

Is this the same bug as reported here? :

http://forums.autodesk.com/t5/inventor-general-discussion/g-l-frame-generator-param-loose-driven-dim...

Thanks,
Curtis

[Mark.Lancaster]

@Curtis_Waguespack

I see the same thing..  So just don't rotate your frame members 45 degs.    Update:  But the issue is related to adding the end treatment.  If you do rotate the members and do not apply a end treatment then its okay.

I never came across a case where I needed to do that but yeah the parameter G_L is not updating.  But the parameter B_L looks correct.  Are you seeing that?

[Curtis_Waguespack]

---

@Mark.Lancaster wrote:

So just don't rotate your frame members 45 degs.    Update:  But the issue is related to adding the end treatment.  If you do rotate the members and do not apply a end treatment then its okay.

I never came across a case where I needed to do that but yeah the parameter G_L is not updating.  But the parameter B_L looks correct.  Are you seeing that?

---

Hi Mark.Lancaster,

Thanks for checking this for us.

You are correct B_L is updating as expected, but G_L is not.    B_L is the base length and so we never pay attention to it for parts list and bill of material needs, and instead only reference G_L.

So, I know you were just joking about not rotating by 45 degrees, but I'll just add this for general interest:

In industrial food equipment design flat surfaces are not preferred, as spillage accumulates on them, whereas an angled face allows (most) spillage to flow to floor, reducing the amount of accumulation and therefore the potential for contamination. 

Lastly, I did find this link (from 2011 ), which has a macro that updates the G_L parameter:

http://beinginventive.typepad.com/being-inventive/2011/06/double-mitered-frames-report-the-wrong-fra...

The problem with it is that it doesn't properly update the part number which references the length, and therefore the part number grouping gets messed up.

So it appears that maybe this bug has been around since 2011?

Thanks again,

Curtis

[Mark.Lancaster]

@Curtis_Waguespack

Just ran another test.  If I place the members without rotating them 45 deg and miter them.  Everything works as required when the frame changes.  If I go and change each member and rotate them 45 degrees.  Parameter G_L will update when the length and/or width of the frame changes.  Odd..  If you do it in the beginning it will not work but if you do after, it does work.

Yes I was joking...    Our frames from my last job..  We couldn't drill/tap  or have any openings in the major structure for the same reason.

[pcrawley]

The reason G_L stops updating is because initially G_L = d18 (or d28, or d17... it varies with the family you're using) where d18 is a driven dimension representing the length.  As you perform step 3 below, G_L suddenly stops being equal to d18 and becomes equal to a numeric value.  From this point on, G_L never updates unless you make it equal d18 again.

I've found an easy way to replicate this problem:

1. Create two frame members in an "L" shape
2. "Trim to Frame" (to cut one part back to the face of the other)
3. "Change" (and just rotate one member by 90 degrees)
4. Miter the joint.  (In this case you'll get an error - but this is the point where G_L gets broken.)

Has anyone on this thread logged this with Product Support?  The code shown on Being Inventive (from 2011) just looks for the first driven dimension in a part and makes G_L equal it - so it's a fix of sorts, but not ideal.

Not wishing to divert the discussion too much, but I'm also seeing description not updating after changing a member (E.g "Change" an existing member for one of the same shape but a different size).  Having trouble replicating (and understanding) this one though because the new part is a completely new file!  However, it appears to be happening at the least convenient time (like most good bugs are trained to do.)

[admaiora]

I have tried too. Same result. Amazing.

Beacuse of these issues, limits and difficulties that companies don't like very much FG.

They would like to use it, but they give up.

FG module can and needs to improve. It has potential.

[Curtis_Waguespack]

---

@pcrawley wrote:

Has anyone on this thread logged this with Product Support? 

---

Hi pcrawley,

I did not do so directly, but this thread has been marked as "escalated", at some point. I have not heard anything concerning this topic from Autodesk though, so I do not have any sort of confirmation that they have looked at the issue, or have documented the issue in their tracking system.

Thanks for the investigation and follow up information on this as well.

I hope this helps.
Best of luck to you in all of your Inventor pursuits,
Curtis
http://inventortrenches.blogspot.com

[jtylerbc]

Issues like these are why (several years ago) I moved us away from relying on G_L at all.  Instead, we use an iLogic rule that measures the extents of the part in the Z direction, then writes that to a User Parameter.  We export and use the User Parameter in our descriptions, parts lists, etc. instead of using G_L.

The real beauty of this method is that it doesn't care how the part gets to its final length.  Frame Generator commands, extruded cuts, Direct Edits - doesn't matter what tools you use, you get the right length.  It is far more reliable than G_L.

[pcrawley]

I just revisited this problem for a customer and thought I would post the iLogic code for measuring part length just in case anyone else needs it. 

I chose to re-use G_L because everything else about Frame Generator works - from the the BOM, to Vault Items, to drawing parts lists etc.  Picking another parameter would just generate extra work.

My huge iLogic routine reads:

G_L = Measure.ExtentsHeight

(Yep - my first 1 line iLogic rule!)  And it works because every Frame Generated component is essentially an extrusion from the XY plane, so ExtentsHeight will always be the length (worth remembering if adding custom profiles to a CC library.)

Add the code to an empty part file - set the trigger for "Part Geometry Change" - Replace Family Template in CC - job done.

What I like best is that I can pre-format the output of G_L now, like rounding it up to the nearest whole number,E.g. The following tweak rounds up to the next whole number. 

G_L = Ceil(Round(Measure.ExtentsHeight,0))

[Curtis_Waguespack]

We just had a user run into this again today.

[Sofia.Xanthopoulou]

Hi guys,

I will try to get some information on this. Bear with me 

Best regards

[Sofia.Xanthopoulou · Accepted solution]

Ok, 

here we go...

According to a report that I have found two things must be done:

Install Inventor R3 and "The user should check “Delete existing treatment” option in the Miter dialog."

Can you please check and report back?

Thanks

Sofia

[pcrawley]

Thanks Sofia. Yes, this works perfectly, even prior to R3.

The real problem is that G_L breaks its relationship with the driven parameter in some circumstances, and you don't know it's broken until steel gets cut to the wrong length.

The example of rotating the member 90 degrees was simply to show a process that would cause the problem.

Check your forum private mail, I sent you a case ID.

[cbenner]

Frame Gen, IMHO, has always been twitchy about updating parameters such as G_L when making changes.  As @pcrawley mentioned above, changing a member profile size doesn't necessarily update the description.  I've been bitten by this more than once.  We have to be extra vigilant with our BOM's before releasing anything to the weld shop.  We also noticed early on that if you need to perform both a trim and a notch on the same beam.... always do the trim first.  If you do the Notch first and then trim, the cut length will be wrong.  Probably related to what you're seeing here @Curtis_Waguespack.

[Curtis_Waguespack]

---

@Sofia.Xanthopoulou wrote:

Install Inventor R3 and "The user should check “Delete existing treatment” option in the Miter dialog."

---

Hi Sofia.Xanthopoulou,

Thanks for looking into this. I've demonstrated an easily re-producible bug in the original post. Did you try reproducing it?

Install Inventor R3 ?

Can I assume you mean R3 of Inventor 2017? We have not currently rolled out Inventor 2017, but have been testing it. In our previous tests this issue persisted in Inventor 2017, but I have not checked recently. Have you confirmed that these issues are resolved in Inventor 2017.3 ? I looked for some mention of it in the release notes, but saw no mention of it:

http://help.autodesk.com/view/INVNTOR/2017/ENU/?guid=GUID-9BB66107-2706-4B8B-8645-9D3307FBE4C7

I'll try to jump over to the test machine to see if 2017.3 is relevant to this issue.

Delete existing treatment ? 

In the video and data set I included with the original post, there are no existing end treatments. I don't see how this suggestion is relevant.

Thanks again,
Curtis

[Sofia.Xanthopoulou]

Hi @Curtis_Waguespack,

I have got this suggestion out of our incident case. I haven't tried to reproduce your example, just wanted to give you a heads up and get more information. 

@pcrawley, did you post on the idea station? Can you send the link?

I will do my best to get more information on the progress of this issue. And I will install Inventor 2017 R3 on my machine to test the dataset 

Best Regards

[pcrawley]

The description iProp issue was fixed in one of the updates for Inventor 2016 (@cbenner - sorry, I can't remember which one).

I found the iLogic code placed in the CC members template works well for fixing the G_L issue and you can notch & trim in any order because the length comes from the range box, not a driven parameter pushing it's value to G_L.  This means you can add your own extrusions and cuts to FG members without using FG tools - and the length is still correct.  

Just be sure to check and recheck on a few test frames.  I found a very small number of times the iLogic code would run, but left the part needing to be updated rather than updating itself.  

The downside is that this "fix" doesn't work for existing FG designs.  For these, I've written an external iLogic routine that runs on any assembly -  finds FG members - compares G_L to Range Box - and only fixes those members whose lengths are wrong.  I'm reluctant to post it here on a public forum because it's only been tested by me in a very isolated manner - but happy to share via pm. (And maybe publish it later if you think it's any good. Maybe  @Curtis_Waguespack can lend his iLogic genius to cleaning it up!)

@Sofia.Xanthopoulou - Re your pm:  No, I didn't post on the Idea Forum.  I probably should, but I don't see this as a new "Idea", it just needs fixing.

[Curtis_Waguespack]

Just a quick update after trying a new suggestion:

First, I think there are a few issues that have been discussed on this thread, so for the sake of clarity, let me restate the original thread topic issue briefly:

• We have a simple frame where we want the frame members placed at 45 degrees (see data set )
• Once placed we miter all of the members.
• At this point the G_L value is correct.
• Next, to see the issue, change the frame base sketch to stretch or shrink the frame.
• Now the G_L value does not update correctly.

Per the suggestion from @johnsonshiue 

I tried using the Align option to set the angle when creating the rotated members as shown here, but it does not seem to resolve the issue.

Thank you,

Curtis

 

[johnsonshiue · Accepted solution]

Hi Curtis, I think I might have given you ill-informed suggestion. This has nothing to do with the Alignment issue in FG. I have taken a look at the issue. This is a bug. Basically, the Miters on the angled members cause the G_L to be static. G_L is supposed to reference a length parameter. But, somehow it becomes static. This is wrong. I am able to reproduce it on 2015 and 2016, but not on 2017. It seems to have been fixed there. I will contact the project team to see if we can do anything with 2015 and 2016. In the meantime, you might need t open the member files and relink the reference parameter to G_L. Many thanks! Johnson

[Curtis_Waguespack · Accepted solution]

Hi johnsonshiue,

Hey thanks for looking at this.

So originally we'd looked at 2017 and were able to see the issue, but I don't recall which update level ( likely 2017 RTM ).  On 11-10-2016, I told Sofia.Xanthopoulou, that we would check 2017.3, but I think we simply didn't get around to it.

In any case, we just checked in 2017.3 and it is fixed, and works as expected!  

Thanks to everyone for the replies and the time spent looking into this. - Curtis