topic Re: Table driven iPart, iProperty formula needs to be different in each "child" part. in Inventor Forum

Table driven iPart, iProperty formula needs to be different in each "child" part.

jeanchile — Mon, 28 Aug 2023 07:24:54 GMT

Hello all,

I am attempting to make a table driven iPart family with a formula in an iProperty field that changes with each "child" part selected. What I mean is, in the first iteration of this table driven part, the "Description" iproperty is =PL. <THICKNESS>". But, in the second iteration, I need the "Description" iproperty to change to =PL. <WIDTH>", and in the last one it needs to be = PL. <LENGTH>".

This iproperty formula needs to change when each of the "child" parts are selected. I can't seem to figure out how to do this. Any ideas?

Here's what the Description iProperty looks like in the first iteration:

And here's what the table looks like with the proper formula in each iteration (notice the field is highlighted yellow though):

And this is the error message I get when I try to click "OK" and publish the iPart:

How can I get an iProperty formula to change similar to what I can do with a parameter?

Thank you everyone!

Re: Table driven iPart, iProperty formula needs to be different in each "child" part.

CCarreiras — Mon, 28 Aug 2023 08:31:24 GMT

Hi!

I would create the formulas in a separate field and load the final result to the iPropertie Description.

I would try that in the iPart excel, or using an iLogic rule.

can you share the part?

Re: Table driven iPart, iProperty formula needs to be different in each "child" part.

k.hendrickx — Mon, 28 Aug 2023 09:53:12 GMT

I never use formulas in the iPart table editor. That just doesn't seem to work.

What does work is opening the table in Excel and using all the available excel formulas to generate to required text. You can even add "helper" columns which get ignored by Inventor.

Re: Table driven iPart, iProperty formula needs to be different in each "child" part.

jeanchile — Mon, 28 Aug 2023 21:04:38 GMT

I've attached the part to this response. Thank you for the help. The part, and my description above, is a severely simplified version of what I'm actually trying to do. In the past, when this kind of thing was needed, the part was developed in a way where we had a different iParts for each instance where the description needed to be different. In this case I cannot do that. Depending upon which selections are made when placing the part, the "description" needs to be formatted differently and I can't seem to be able to do that.

I know nothing about iLogic (though it has been on my list of things to learn for a while) so that's out for the time being. Any other way I can accomplish this?

Re: Table driven iPart, iProperty formula needs to be different in each "child" part.

jeanchile — Mon, 28 Aug 2023 21:08:05 GMT

Thank you Kevin. Unfortunately, I cannot have a separate "child" for each iteration of this. The iProperty needs to be an "equation" and needs to update depending upon which selections are made when placing the part (see my response above for more details). Is there any way other an iLogic to accomplish this?

I guess what I'm saying is that I somehow need the iProperties to behave the same way as Parameters do when used in a table driven iPart.

Re: Table driven iPart, iProperty formula needs to be different in each "child" part.

johnsonshiue — Mon, 28 Aug 2023 23:18:50 GMT

Hi! Two ways to make it work. 1) Don't add the iProperty as a column. The formula stays true for all members and the values are populated accordingly.

Or, edit the iPart table and spell out the iProperty values individually using Excel functions.

Many thanks!

Re: Table driven iPart, iProperty formula needs to be different in each "child" part.

jeanchile — Tue, 29 Aug 2023 15:56:24 GMT

Okay, thank you Johnson.

Unfortunately, neither of those options work for me. The equation has to be a part of the table for the iProperty as the equation changes depending upon which inputs are selected when placing the part.

What I'm left with doing (until I can learn iLogic), is adding the iProperty to the author table, then spelling out the "equation" in the iProperty with the different ways it's written. But, then I'm just leaving the "=" sign off the front of the equation. That way, the different equations are populated in the table/iProperty but it technically doesn't "compute". The table driven iPart is now a "custom" one and when the iPart is placed, and saved in the project folder, the user then has to go into the iProperties and add the "equals" sign to the front of the iProperty field to get it to compute properly, and show up in the bill of materials the way we need.

Not, ideal, because I didn't want this iPart to be a "custom" one and also, because the user has to be told to add the equals sign (which I'm adding as a note in the engineer notebook in the part). Unfortunately, this is all I'm left with until I can learn programming in iLogic (where I hope there is a solution for this, but I don't actually know).

Thanks again everyone for the assistance!

Re: Table driven iPart, iProperty formula needs to be different in each "child" part.

Frederick_Law — Tue, 29 Aug 2023 16:07:45 GMT

Add another parameter "ForDesp".

Set it to "=Thickness", "=Width", "=Length" in different part.

Set "Description" = "ForDesp".

Why does description switching to "Thickness", "Width" and "Length"?

Do you want to display the largest dimension in description?

If your solution start to get too complex, go back to beginning and look into other direction.

Re: Table driven iPart, iProperty formula needs to be different in each "child" part.

jeanchile — Tue, 29 Aug 2023 16:15:41 GMT

Again, the part and description I have posted above is a simplified version of my issue and not exactly what I am trying to do.

And, no matter what iProperty I use, custom one or Autodesk one, that iProperty MUST be an equation. So whether I type the "PL. = <thickness>" equation in the description iProperty, or any other one, custom or otherwise, I am still left with the problem that I need to have an iProperty, with an equation, and that equation needs to be a part of the table and needs to change depending upon the inputs selected on placement.

Your suggestion does not work because I still have to have an equation that changes typed somewhere into an iProperty that is part of the table.

But I thank you for your attempt at helping. I wish there was a solution as easy as you are representing.

Re: Table driven iPart, iProperty formula needs to be different in each "child" part.

Frederick_Law — Tue, 29 Aug 2023 16:34:38 GMT

Cool, but .....

Show us your whole problem, not your version of solution to the problem.

You must use equation but I might not.

You are asking for solution, so prepare to get a solution completely different then your solution.

Of course you can ignore all that too.

Yes, this is how I talk to my customers.

Re: Table driven iPart, iProperty formula needs to be different in each "child" part.

Frederick_Law — Tue, 29 Aug 2023 17:35:41 GMT

@jeanchile wrote:
that iProperty MUST be an equation

Why?

I think the problem is different syntax for iProperties in Excel table and iProperties edit.

What you type in UI does not work in Excel.

Similar thing had been done in Content Center parts. With part dimension, usually length in Description.

Re: Table driven iPart, iProperty formula needs to be different in each "child" part.

jimm_motyka_777 — Tue, 29 Aug 2023 17:25:27 GMT

It's outside the box, but have you tried making these work through your user parameters and then snagging the value in the user parameter to populate the iProperty field? You could possibly create your equations behind the scenes and then just pull in the value into the iProperty.

Recently, I've been using the Model States rather than the iParts/iAssemblies, just because it seems they reside better in Vault Pro. Model States may open some new ideas that the current iParts aren't. I've also found that the Model States have diminished some of the iLogic programming I used to do. Again, this is just a suggestion. I've been on the frustrating side of things not updating as expected, so I completely get vibe of your posts.

Re: Table driven iPart, iProperty formula needs to be different in each "child" part.

jeanchile — Tue, 29 Aug 2023 19:18:24 GMT

Unfortunately I cannot post the actual part, or be very descriptive in exactly what I'm trying to do, but it doesn't matter. If you solve the original question I asked, you will have solved my issue.

I'll try to take this a step further using another example but again, the fundamentals are exactly the same. I need an iProperty to be "programmed" with a different equation for different instances of the table-driven-iPart.

Here's example two:

I have a custom iProperty named "ORDER INFO".

When placing the iPart in an assembly, the user will be specifying different configurations of the part through selecting parameters or iProperties that define the geometry and text data needed downstream from this step.

When it's placed, the user will select either "HOOKED", "HEADED", "PARTIALLY-THREADED", or "FULLY-THREADED".

If the use selects "HOOKED", the "ORDER INFO" iProperty must read:
- ANCHOR ROD, HOOKED, LEN=18", HK=3", THREAD=7" of 3/4-10 UNC 2A LH, ZINC-COATED=8" FROM EXPOSED END
If the user selects "HEADED", the "ORDER INFO" iProperty must read:
- ANCHOR BOLT, HEADED, PROJ.=4 1/2", EMBED=12", THREAD=5 1/4" of 1 1/4-8 UN 2A RH
If the user selects "PARTIALLY-THREADED", the "ORDER INFO" iProperty must read:
- ANCHOR ROD, PARTIALLY-THREADED, PROJ.=4", EMBED=14", THREAD T&B 1/2-20 UNF 1A RH, 7" @ TOP, 2 1/2" @ BOTTOM, HOT-DIP GALVANIZED 12" FROM EMBEDDED END
If the user selects "FULLY-THREADED", the "ORDER INFO" iProperty must read:
- ANCHOR ROD, FULLY-THREADED, 7/8-9UNC 2A RH, PROJ.=6", EMBED=13 1/2"

Anything underlined and in RED, is a parameter that directly affects the geometry of the model, but is defined by the user and their requirements. Anything underlined and in BLUE, is another custom iProperty that drives different text in all of the drawing design information (Leader Info in Drawing Details), the information in the Parts List on the drawing, and the direct link to the purchasing/inventory software.

This "ORDER INFO" iProperty ties directly to ERP/MRP software and must be formatted like this. Once the formatting is established, and specified in the ERP/MRP software and created in the iPart, it must remain exactly like that and if it's left up to the user to format it like that each time, there are constant user-errors that cause problems during import, nesting, purchasing, etc.

This is another example of what I'm trying to do, not exactly what I'm trying to do, but again, if someone has a solution to my first post, all of these problems are resolved.

I hope this helps because, in all honesty, I have run out of ways to describe this.

Thanks again for spending time with this and for all the attempts at helping!

Re: Table driven iPart, iProperty formula needs to be different in each "child" part.

Frederick_Law — Tue, 29 Aug 2023 19:43:42 GMT

I cannot open 2024 file.

So I make my own.

The problem is, Syntax Error.

This help page need to update:

https://help.autodesk.com/view/INVNTOR/2023/ENU/?guid=GUID-6A984E7A-C08E-45C0-906B-7143596A4581

CONCATENATE changed to CONCAT.

Use Excel syntax in spreadsheet, not IV syntax.

See attached file.

Re: Table driven iPart, iProperty formula needs to be different in each "child" part.

Frederick_Law — Tue, 29 Aug 2023 19:46:51 GMT

Now I can use it in my ModelState Part 😎

I was thinking about generated Description for all different sized parts also.

Probably Part Number also.

Re: Table driven iPart, iProperty formula needs to be different in each "child" part.

johnsonshiue — Wed, 30 Aug 2023 02:10:51 GMT

Hi Jean,

Such variation is probably not doable with iPart or Model States. I think you may want to look into iLogic.

Many thanks!

Re: Table driven iPart, iProperty formula needs to be different in each "child" part.

jimm_motyka_777 — Wed, 30 Aug 2023 11:06:34 GMT

I would have to agree that when equations cannot give your expected result, bring that info into iLogic. The upside is that you know what you're wanting to happen, which should simply the iLogic path for you. Your pre-work is done and you know what works and doesn't work. In this instance, I could see the MultiValue functions being key to getting you where you need to be. It certainly will take work to get there, but it appears that it would be worth going down that rabbit trail.

Re: Table driven iPart, iProperty formula needs to be different in each "child" part.

Frederick_Law — Wed, 30 Aug 2023 12:49:12 GMT

4 versions of "Anchor Rod/Bolt" each has different "Order Info" with different parameters.

"Order Info" MUST change with "Anchor Rod" TYPE.

It can be done easily with the iPart table.

Table MUST have all the info.

"Anchor Rod" TYPE MUST be Primary KEY.

Re: Table driven iPart, iProperty formula needs to be different in each "child" part.

jeanchile — Wed, 30 Aug 2023 15:53:33 GMT

Thank you Johnson, it's time to start learning iLogic.

Re: Table driven iPart, iProperty formula needs to be different in each "child" part.

jeanchile — Wed, 30 Aug 2023 16:00:46 GMT

My apologies Fredrick. I am in no way attempting to be rude or belittle you in any way, but there seems to be something about this that you're not grasping, and I am out of ideas on how to explain it differently.

The simple question in my original post stands. I need to be able to add an iProperty (stock or custom) to an iPart table, and have that iProperty's values be an "equation", and that "equation" needs to be different for different children in the iPart table. Apparently, Inventor is capable of doing that with a parameter, but not an iProperty. There appears to be no other solution to my issue other than programming in iLogic, which I will have to start learning.

I'm grateful to everyone for their time and attempts to help. Thank you everyone.