VERY slow iLogic functions with multiple Inventor processes

[thomaskennedy]

Hi,

I hope someone can give me some advice on this, and maybe some info on how the internals of Inventor / iLogic are working.

We have multiple instances of Inventor running on a 12 core workstation so we can push configurations through concurrently  - each Inventor instance is assigned its own processor affinity and each instance has its own project which points to seperate directories of Inventor models.

Everything seems to work OK when there are up to 5/6 working concurrently, but as soon as there are more than 6 the iLogic functions seem to grind to a halt - note that the rules are external rules.

For example, this function took 11 seconds to complete when there were 10 concurrent orders processing. :

Parameter("BLANK", "EDGE_FRT_ACTIVE") = "YES"

 Similarly these functions took 11 seconds in total to complete :

iProperties.Value("Custom", "M1110900_P1PO") = iProperties.Value("Custom", "BLANK_GDIM") - iProperties.Value("Custom", "PANEL_GDIM")
iProperties.Value("Custom", "M1110900_P2PO") = iProperties.Value("Custom", "BLANK_XGDIM") - iProperties.Value("Custom", "PANEL_XGDIM")
iProperties.Value("Custom", "M1110900_P1OR") = 1
iProperties.Value("Custom", "M1110900_P2OR") = 0

When I run these with less that 6 concurrent Inventor processes, they're are almost instant.

I just don't know where the bottleneck is. I've ruled out :

- Processor (each core never reaches above around 60%)

- RAM (we've got 48GB of RAM, with about 15GB free at worst)

- Disk (disk IO is busy, but it doesn't look like it's the bottleneck)

- Graphics (Inventor is in silent mode, with no UI, so graphics activity is minimal)

From the tests I've done it seems to be the iLogic functions that are the bottleneck. My next port of call is to change the iLogic functions to actual API calls, but I suspect I'll get the same results.

So, my questions :

Is Inventor queing these iLogic API calls somehow (note we're creating a unique instance of the Inventor.Application COM object for each processing thread) ?

Is there an issue with using external rules with nultiple instances?

Or, is it a bug in Inventor?

Any advice would be greatly appreciated.

Thanks,

Tom

Dell Precision R5500, Intel Xeon X5690 3.47GHz (x2)

48GB RAM

Inventor 2013 (PDS Premium)

64bit Windows 7 SP1

[xiaodong_liang]

Hi,

I am not sharing a comment, rather, I am curious why you have multiple instances of Inventor running. This scenario is weird to me. With more and more instances, it is not strange to me you may hit some performance issues. I even doubt if you could manually operate the instances fluently, though I know your workstation is strong enough.

So, what I could, if it is a suggestion, say is: you may need to check the workflow if you need to create many instances. e.g. can some jobs be done in one instance? Is it necessary to keep one instance alive if you do not need it anymore?  

[thomaskennedy]

Hi, thanks for the reply.

I think we're quite unique with our implementation of Inventor.

We've worked with our ERP supplier to develop a system that runs alongside out existing order entry system.

So, at order entry the clerk enters a paricular model to order, with a particular configuration, through a web interface.

This config is sent to an application on ther server that :

 - Decides which of the multiple Inventor.exe processes to use (i.e. one that isn't busy)

 - Opens the specified model, from the order entry config

 - Passes in (to custom iProperties) the order entry options

 - Runs an iLogic rule, which reconfigures the model the the requied spec

 - Gets the BOM

 - Returns the BOM to our ERP system.

 - Closes the model

As you can imagine, we order many different models, in different configurations, at the same time.

We could of course queue up all of the requests and process them 1 by 1, but we are entering hundreds of configurations a day, so this just isn't practical and won't work.

I don't think there is an issue with having lots of instances alive at the same time, the issues arrise when there are multiple instances trying to execute iLogic functions at the same time.

Thanks for your suggestions, I hope I've given a better explanation of our implementation.

Thanks

Tom

[xiaodong_liang]

Hi thomaskennedy,

Sorry for my delay.

I have not an idea on such behavior. There is not any such report in our inner database. If it is fine to you, could you share the iLogic code and describe the steps how to test? I can give it a try at my side.

[thomaskennedy · Accepted solution]

Hi,

I think we've worked out what was causing this issue.

The parent process that is responsible for triggering the iLogic rules in the model(s) was using the iLogicAutomation API. So although there was a unique instance of the Inventor.Application COM object for each of our processing threads, it appears that using the iLogicAutomation API caused all subsequent iLogic function calls to be processed in a single seperate process away from Inventor.

To get round this, we are now triggering the rules via a parameter change. So rather than running the rule directly, the parent process changes a parameter value which causes the rule to be triggered. Using this method we are ensuring that the rule (and all subsequent iLogic functions) are executed inside it's own process.

We've proven that this works. Using the iLogicAutomation API to trigger the rules it took 18 minutes to process 10 complex models concurrently. However, triggering the rules from a parameter change, the same 10 models were processed in 3 minutes concurrently.

Thanks,

Tom

[Shatalov]

Great solution! Faced the same problem...

[Shatalov]

Any ideas how to pass ruleArguments from external process?

[l.vandemoortele]

Hi,

Very interesting, thank you.

I am currently facing the same issue and for the same kind of workflow with multi Inventor instances controlled by API.

We are now in 2020... Are you still using a parameter change trigger to make the iLogic rules to run ?

Or have you found a way to run iLogic from API in a multi thread context without incredible performance loss ?

I tried to keep the rules to run automatically, directly by Inventor with a trigger and not through API, but its not consistent, sometimes they run sometimes they do not..

Best regards

Luc

[thomaskennedy]

Hi Luc,

2020 - now there is a question.

We recently tried upgrading from 2017 to 2020 and we faced really poor performance.

As of yet we have been unable to identify exactly what was causing the issue(s)

Ultimately we had to revert back to 2017 to allow us to invesitgate the issues separately.

Aside from the performace issues are rules are still called in the same way - parameter trigger.

I don't remember ever coming across a rule that didn't run when linked to a parameter so long as:

1. 'Don't run automatically' is NOT checked

2. The rule is not suppressed

3. The rule is an in document rule and the parameter name is in blue in the editor

4. If the parameter was created after the rule was created then the rule needs saving again - when opening the rule the parameter will be in blue but for some reason it doesn't register unless you make an edit and save again

Cheers,

Tom

[thomaskennedy]

Also one other thing to watch out for in 2020.....

Inventor 2020 compiles iLogic rules differently

Inventor 2017 compiles the iLogic rules on the fly – it creates .vb files in the %temp% directory with random file names and therefore when multiple processes are compiling iLogic rules on the fly there is never (or very very very rarely) more than one instance trying to access the same .vb file at the same time

Inventor introduced some new functionality to allow you to debug iLogic code with Visual Studio. This changed how the iLogic rules were compiled on the fly and instead of random file names being generated they were structured and named to reflect the document file name and rule name. This means that when multiple processes are running there is a potential for conflict where more that one instance requires access to the same file at the same time

I found that setting a System Environment Variable “iLogicRuleFolderForVS” to a value of 0 turns the debugging functionality off and the iLogic temp files return to as they were previously.

Hope it helps

Cheers,

Tom

[l.vandemoortele]

Hi Tom,

Thanks a lot for this information. And I was not expecting a reply on such an old thread 😉

In the end I managed to implement the rules trigger consistently by liking the rules to a clear iTrigger parameter.

Your second message is really interesting, as I in the end experienced the same problem with iLogic rules beeing called at the same time by several instances.

From my side I solved that by adding a instance prefix during Apprentice copy design on all files, this way the rules name are different for each instance.

Maybe I will try to change the “iLogicRuleFolderForVS” variable, it might improve the overall performance. The only thing is that would be less convenient if the app is launched by new people on different computers.

Now I have to solve some other problems..

- Apprentice parallel execution (subsidiary)

- more problematic, an issue during FileDescriptor.ReplaceReference exiting 0x80004005 (E_FAIL) error

But this will be an other thread if i cannot solve it 😉

Thanks again !

Cheers

Luc