iLogic to drive pattern in iPart requires rebuilds

[88nwilson]

I have a simple iPart, with driven parameters Length and Width. When length changes (from a multi-value list), the spacing on a pattern and the number of occurrences of that pattern also change.

Invariably, it requires a rebuild. Occasionally, it requires two rebuilds. As this part is in a second-level subassembly, opening the part, rebuilding it, then rebuilding its assembly, then rebuilding the top-level is consumptive.

I've been using iLogic and iParts for about a week now, so I might be missing something basic. File attached.

[mrattray · Accepted solution]

One quick correction: I think you mean "requires an update", not a rebuild.

Updating can be automated by adding this line anywhere (I like it to be at the top, by preference) in both rules:

iLogicVb.UpdateWhenDone = True

[88nwilson]

Thanks, the .ipt is working perfectly now. I guess I assumed that was the default state of the model, to update after running a rule.

I'm still (occasionally) getting the same problem in the top level, despite tucking the same Update All code snippet into its rule. Do I need a different code for an iAssembly to update?

[mrattray]

iParts and iAssemblies don't usually play well with iLogic. I think there's just too many "i"'s involved.
If you can post the assembly or give a more detailed description of what's going on I can give you some better advise.
By the way, I just noticed this is your first (well, second now) post here. So, welcome to the forums.

[88nwilson]

Yeah, I've noticed the iPart/iLogic conflicts a few times already. I've been careful to keep the iLogic inside a part, without trying to pass any paramters into an iPart from the top level, but I have a feeling I'll be tracing that boundary for a while.

I have a folder with 30 configurations (5 lengths x 6 widths) for this part, and each is predictable with a brief iLogic code. The assembly similarly has 30 configurations, all predictable. I use iLogic to decide which iPart to call, and there are a handful of assemblies driven by pure iLogic, as well. The iParts seem to load much more quickly, and the file structure is helpful, but I am having trouble figuring out where the line lays before iLogic causes problems.

Is there a writeup on a healthy way to use the two together? And thanks for the welcome.

[mrattray]

I personally just use iLogic 100% of the time to avoid any possibility of conflict. I find that I can do anything in iLogic as easily or easier than I can in a spreadsheet.

If there is a white paper out there on getting iLogic & iParts to coexist I haven't seen it. If you do find one, would you mind posting it here? I wouldn't mind giving it a read.

[88nwilson]

If I find anything, I'll certainly post it.

What I've noticed, the iParts are safer for a product line. We make 30 similar products, and need files for each. I made iParts for each of the 30, so that it replaces the part when we change size, instead of editing the part and potentially damaging linked assemblies, drawings, etc.

I've used iLogic to pick which iPart to use. If the length is 36, iLogic code finds all the 36" long iParts (which are saved as part-36.ipt, making them easy to find in their table/folder). I also have safely used iLogic inside an iPart to control a pattern relative to the tabulated parameters. However, I think this might be why it won't update well from a top-level assembly on the first try.

Earlier in the week, I tried to use iLogic in an assembly to directly influence a parameter in an iPart, and it gave me errors(fortunately). I was trying to edit part-36.ipt to 48", instead of switching to part-48.ipt.

The major problem I'm having is preserving distinct files for each size (an obvious iPart feature) while manipulating each size (an iLogic feature). I agree, it would be much easier to only use iLogic, but the potential to overwrite a needed file is too dangerous for us (and we're in the process of migrating to Vault, but it'll take a while). Is there a simple method to have iLogic build a file library whenever a key parameter is changed, or call the appropriate file to the assembly if it already exists?

[mrattray]

Those are solid reasons to use iParts.
Unfortunately, there's no in-built method of doing what you ask in Inventor. There are two options to get it though. You could depending on your handiness with programming write yourself some sort of add-in to do it. You could also request this as a feature for future version of Inventor by posting your idea here: Inventor IdeaStation