I'm having an issue with the dimensions in my parts list in one assembly. All of my parts were created with the frame generator. Some of the sizes shown in the parts list are not correct. The strange thing is this is only happening with some of the parts in this assembly.
For this particular part in question, d0 is the exact length of the line in the sketch. G_L is checked to export so I see why this is reading this length. Since the math works out d0-d2=d7. 27.166 in is the actual length of the part and should be showing in my parts list. My big question is where does G_L (28.85723856 in) come from? This dimension isn't anywhere in my assembly (that I can find). Has anyone seen this before?
Thank you.
I ask you a question, are you using a custom structural member? I usually customize the structural member and to avoid errors in the automatic calculation of the length G_L
I create a user parameter in the custom structural member, for example "NewLength". Then I add an ilogic rule like the following
On Error Resume Next oDoc = ThisDoc.Document InventorVb.DocumentUpdate() oDoc.ObjectVisibility.AllWorkFeatures = False oDoc.ObjectVisibility.ConstructionSurfaces = False oDoc.ObjectVisibility.Sketches = False oDoc.ObjectVisibility.Sketches3D = False 'Assign the measured value to the user parameter NewLength NewLength = Measure.ExtentsHeight oDoc.ObjectVisibility.AllWorkFeatures = True oDoc.ObjectVisibility.ConstructionSurfaces = True oDoc.ObjectVisibility.Sketches = True oDoc.ObjectVisibility.Sketches3D = True RuleParametersOutput() InventorVb.DocumentUpdate()
Finally, I put the event triggers so that changes to parameters or geometries are updated before saving the document.
I export the NewLength parameter to use it as the actual length of the document.
Maybe this could be useful. regards
Sergio Daniel Suarez
Mechanical Designer
| Upwork Profile | LinkedIn
I have other parts in the assembly from the same family that aren't affected. See attached for the part in question.
Hi! Steve,
Two things. It is possible the G_L comes from end treatment. Or, it is from the skeletal geometry. Could you share the frame assembly here?
Many thanks!
The G_L parameter should be driven by a reference dim., d7 in your case. That reference dim, d7, is a driven dim. from sketch 9, and is a measure of the distance between the Start Plane and the End Plane. Those two planes move around depending on the end treatments of the member, so that sketch adjusts with movement of the planes to report the length when modified with frame generator. I can't say what caused G_L to loose its d7 parameter link, but if you enter d7 in the equation for G_L it will fix the length issue for that part. See attached for an example of parameters from a custom profile i use.
I am going to give you the benefit of the doubt and assume it is not user error and truly some glitch somewhere. This is very strange. If you can repeat the issue you might post a screen cast of the issue in action as you take the steps of creating the frame and maybe someone from Autodesk will chime in.
I will share with you that i had some issues with exporting the G_L parameter (checking the export button in parameter dialog box) so as to include the formatted fractional length in the description. The dimension's format would change randomly from fraction to decimal. I had to create a new user parameter (I called LENGTH) and enter G_L in equation for that parameter. I could then export (and format) the new LENGTH parameter and use it in my description without the funky formatting behavior. FWIW, The pic I included is from a different computer using an old content center from before i implemented the changes discussed above, so it shows the G_L parameter exported instead of my new LENGTH parameter.
Hi Johnson:
I can't understand how this length could be calculated from any combination of end treatments. I've gone over this several times. How would you like me to share? Do you want the sketch only or the entire assembly?
I just took the original sketch, put it into am assembly and populated it with the part in question, along with the part it sits up against as an end treatment. I put it into a new .IDW, inserted a new parts list and now it shows the correct length!
If I open the original assembly and create a new .IDW and create a new parts list it still shows the old (incorrect) length. This means something in the original assembly is controlling this.
If you use both Trim and Notch end treatments, are you doing the trim before you do the notch? In my experience, it has always been the case that notching before you trim a frame member will mess up the G_L value and give you the incorrect cut length in your parts list. Got burned a few times by this with bad values hitting the weld shop.
Chris Benner
Inventor Tube & Pipe, Vault Professional
Cad Tips Tricks & Workarounds | Twitter | LinkedIn
Autodesk University Classes:
Going With The Flow with Inventor Tube and Pipe | Increasing The Volume with Inventor Tube and Pipe | Power of the Autodesk Community | Getting to Know You | Inventor Styles & Standards |Managing Properties with Vault Professional | Vault Configuration | Vault - What is it & Why Do I Need It? | A Little Less Talk - Tube & Pipe Demo | Change Orders & Revisions - Vault, Inventor & AutoCAD | Authoring & Publishing Custom Content
I'm not using any notch treatments, just one trim treatment.
Hi Steve,
Please share the files here or send them to me directly (johnson.shiue@autodesk.com). I would like to understand the behavior better.
Many thanks!
Hi Steve,
Many thanks for sharing the files with me and Joseph! I took a look and I saw something unusual. G_L parameter, which is the BOM QTY, should be equal to the driven (reference) dimension in the sketch in the frame member file. In your case, G_L parameters are all static. It seems that it was overwritten somehow. I guess there was an iLogic rule overriding the value. Or, the value was overridden in the PartsList back to the BOM. But, I don't see any iLogic rule in the files except a unrelated global form.
To link the G_L to the length parameter, you will need to open each frame member file and overwrite the static expression of G_L to the corresponding reference parameter (length). If you find a workflow reproducing the static behavior, please let us know asap. I notice that you are still on 2019.2 update. Please install 2019.4 update.
Many thanks!
Can't find what you're looking for? Ask the community or share your knowledge.