Inventor 2010 CC "length" changes to decimal from fraction

[cadman777]

Hi All,

Can someone please help me figure out how to fix a recurring problem in Inventor'sContent Center?
It happens when I change structural shapes in the Frame Generator.

The default Custom CC length is FRACTIONAL @ 1/16".

When I change the member, the program changes the length FORMAT from the default (above) to DECIMAL X.XXX.

How can I prevent this unwanted, unwarranted change?

Also, if this is a defect in the program, does anybody have, or know of a place where I can get a MACRO that fixes this in my BOM so the lengths shows-up correctly in my drawing's Parts List ?

The down-stream problem is found in the drawing Parts List:

A "rolled-up" line-item doesn't roll-up properly, in that it has 2 groups for the same structural member:

One group has a FRACTIONAL LENGTH, whereas the other groups has the identical LENGTH, except it's DECIMAL.

This is unacceptable and problematic in the estimation and fabrication process.

Causes a lotta confusion and errors.

Thanx ... Chris

kelly.young has edited your subject line for clarity: CC "length" changes to decimal from faction

[jtylerbc]

You don't mention what version of Inventor you're using (your signature mentions 2010, but surely that can't be right).  I ran into essentially the same problem when we first upgraded to Inventor 2016.  I resolved it by tweaking our custom structural steel families a bit.

Instead of actually using Autodesk's parameters, I created my own, set them equal to Autodesk's, and applied the formatting to my parameter instead.  Then I had to tweak some part descriptions, Parts List Styles, etc. to reference the new names.  Once I did, the loss of unit formatting stopped.  It seems that whatever is wrong only affects values that are connected to the CC Family Table.

I haven't checked to see if this was fixed in subsequent versions, so we are still running (with Inventor 2018) using my fixes. 

[cadman777]

jtyler,

Thanx for your quick reply!

Yup, you got it, IV2010.

So basically I have to use another "work-around" b/c the CC has a DEFECT.

Appreciate your input, as your work-around is not too much hassle.

It just means I have to 'tweak' about 100 CC parts.

Can't take more than a week to do the 'tweaks' and then test them for verification!

At this point, I'm going to wait to see if anybody else has any solution that's "out of the box" for obvioius reasons. If not, then I'll be forced to use your very creative solution.

Incidentally, my "length" iProp is "G_L".

That means "B_L" transfers to "G_L" and STILL gives me a changed format number.

So I'm wondering if going from "B_L" to "G_L" and then to "somethingelse" will fix the problem?

Cheers ...

[jtylerbc]

Well, if you're actually still running Inv 2010, then I can't guarantee that it's the same problem that caused me to make my change.  It might still be something you could try to fix it, but I can't say for sure if it will work.

I ran with formatting applied to the out-of-the-box parameters from Inv 2010 up until our upgrade to 2016, without problems.  Your version may not be new enough to have the exact problem I was fixing.

[cadman777]

John,

In any case, I do appreciate your input, b/c it's a solution one way or the other.

Thanx!

[jtylerbc]

In case it turns out to be relevant, here is some elaboration on what my situation actually was.

We had this problem not with the length of the members, but with the width/height parameters (G_W, G_H) and the thickness (G_T).  These parameters were embedded in our part Descriptions, with fractional format, as was the length.  What I noticed was that G_W, G_H, and G_T kept reverting to decimal, while the length stayed properly formatted.

For length, we were using an iLogic rule that measured the length of the part instead of using G_L, because we had found that to be too unreliable.  The iLogic rule was outputting to a User Parameter, which was then used as our length instead of G_L.

The difference in behavior between our custom-built length parameter and the Autodesk-standard parameters for the other dimensions is what clued me in to what was happening.  I added my own parameters, so they acted more similarly to the way we were already treating length (except without need for iLogic), and the problems went away. 

If we had been using G_L for our length, I believe we would have had the same problem there.  But I don't recall whether or not I actually tested to verify that.  I also never reported the problem to Autodesk.  It was discovered near the end of my 2016 implementation, just before we started pushing the upgrade out to the rest of the company, so I just had to make it work in a hurry.

[cadman777]

John,

Thanx for the added details.

What applications were you using the CC for? Frame Generator? Or some other custom application?

I just tried doing what you said.

Guess what?
It works!

So now I'm going to get working on the most essential CC parts to get this thing fixed.

You're the ONLY ONE IN HERE who has a solution for this DEFECT in the software.

I've asked a number of times over the years but never got an answer.

I don't write iLogic ... too much other stuff in my head.

So THANX! 

[jtylerbc]

---

@cadman777 wrote:

What applications were you using the CC for? Frame Generator? Or some other custom application?

---

Both, which is why the G_L method for length was so unreliable for us in the first place.  Although it wasn't perfect, it was usually right when used with Frame Generator.  However, when a CC structural part was placed as a normal part where it might be cut off or otherwise modified with Extrusions, Sculpts, etc., it was nearly always wrong.

The fact that my solution works for you is great, as far as getting you an answer and helping you get back up and running.  It does, however, challenge my understanding that the problem had been caused by Inventor 2016. 

Could be some other variable in play, which hit me at the same time as the 2016 upgrade and I assumed that to be the cause.  Not sure what that could be, though.  Maybe whatever it is doesn't hit that many people, so no one knows what we're talking about?

[cadman777]

No telling about any of it. This problem has been around 'since forever'. My guess is it's 'hard-coded' into the program, but costs too much in resources to justify fixing.

Do you have any examples of projects you've done w/Inventor FG that show standard structural elements, equipment and connections that I can see? Do you automatically generate drawings from your assemblies? How do you separate into iam files your FG parts that are weldments? I'm curious how far you've pushed Inventor FG and how it's working for you.

A few years ago I tried creating my own parametric structural library in Inventor, but found it very very difficult 'out of the box', so abandoned the attempt for the time being. I'm back visiting the subject to see if it's possible, now that I have a few days of free time on my hands. I'd like to see what others are successfully doing.

[jtylerbc]

---

@cadman777 wrote:

Do you have any examples of projects you've done w/Inventor FG that show standard structural elements, equipment and connections that I can see?

---

I'm not sure I have anything I can post, but I'll check.  Any models of real equipment would be proprietary, but I may have some example files that don't represent any specific piece of equipment, but are similar enough to be a realistic example.

---

@cadman777 wrote:

Do you automatically generate drawings from your assemblies?

---

If I'm following correctly what you're asking, no.  Our designs are too varied for there to be any significant automation of drawing creation.  We use iLogic and VBA quite a bit, but most of it is for supporting tasks (automating descriptions, creating PDF's, some modeling tasks) rather than for creation of the drawings themselves.  There just isn't enough repetition in our work for drawing automation to be practical, even on our non-FG work.

---

@cadman777 wrote:

How do you separate into iam files your FG parts that are weldments?

---

Essentially, I don't separate anything like that after building them.  I would build them as separate assemblies with their own frames initially, tying them together with linked parameters if necessary.  I realize that this logic may not be ideal for everyone, but it works for me.  Generally when I have the need for multiple "FG Weldments" in the same project, it's because something is detachable or possibly movable.  In those cases it makes more sense to me to just build them separately and assemble them later, just like they would be in the shop.

---

@cadman777 wrote:

I'm curious how far you've pushed Inventor FG and how it's working for you.

---

It works well for what we use it for, but I will point out that our FG applications would probably be considered fairly small and simplistic.  Generally, we are using it to build frames or skids for our custom equipment.  Often our fabrications are a combination of structural steel members and plate steel construction.  We have had great success with combining Frame Generator and Multibody modeling to create these sorts of structures.

The weldment is often a subassembly of a "final assembly", which may combine multiple weldments, connecting pins, hydraulic / pneumatic components, hardware, etc.  Occasionally the weldment is a piece of equipment unto itself (such as a support stand), but more often it is a component of a system of some kind.

[cadman777]

Thanx for your detailed reply!

Sounds like your work is similar to mine. Most of it is 'custom'.

I really didn't want to bother you for any model files, only screen shots of the GA and maybe some relevant details, so I can see how you're doing it, and maybe with the model tree showing.

If you can show me things like that, it would give me an idea, b/c I can see in it how it's done due to being very familiar w/the commands and work-flows in Inventor.

Over the years I've tried a number of ways to use the FG w/the rest of the program, and find it difficult at best to arrive at a 'holy grail' work-flow (like you get with SDS/2 or something like that).

Cheers ... Chris