Full Document Automatic Update iLogic

[Anonymous]

A little background... I'm driving an assembly through parameters in Excel and I created a few rules using the iLogic interface to suppress/unsuppress parts and patterns based on states defined in Excel. I've created a rule to perform a full document update automatically when the Excel document is saved. The way it works is:

I've created a parameter in Excel, we'll call "ChangeBit", whose value changes back and forth between 0 and 1 every time the document is saved. I then created a rule which performs a comparison of the values between "ChangeBit" and a user parameter in Inventor that we'll call "InvChangeBit". If the values are different, "InvChangeBit" is set to "ChangeBit" and inventor is updated. This ensures that every time the Excel document is saved, these two bits will be different and an update must be performed.

The problem that I'm running into is that, quite often, these rules are performed before some of the parameters from Excel have a chance to update their values. So, while the suppression states of parts are usually updated, often the length, width and mate distances of parts will not be updated and I will have to click the update button anyway.

Is there a way I can ensure that this rule is run only after all the parameters have been read from Excel?

[martin_winkler]

Hi,

i think it is a timing problem concerning the odbc to Excel. It's very slow often.

1. Did you use the Excel Parameters only in then main assembly or did you use it also in sub assemblies and parts as connected parameters?

2. Is it necessary that the parameters comes from Excel?

I prefer an fxParameter.ipt that contains only user defined parameters and use this ipt in all documents were the parameter are needed as a connected part in the fxParameter Table. The advantage of this method is that it's very much faster and Inventor recognize changing parameters immediately.

If you need the Excel Table because of complex calculations then create first this fxParameter.ipt , get the parameters from Excel only in this part and use the fxParameter Part in all other Assys and Parts.

I am not sure if this will solve the timing problem, so try it.

[b_sharanraj]

I think Some of you parts have Event Triggers of "Any Model Parameter Change" .

So that excel starts transferring the data to parts and it updates the model parameters & rules starts running.

The rules only which have Event Triggers and parameters transferring are happening simultaneously so that you are seeing this issue.

Remove Event Triggers and try once or else add a iLogic code for "iLogic Regeneration of all Rules"

Dim controlDef as ControlDefinition = ThisApplication.CommandManager.ControlDefinitions.Item("iLogic.RegenAllRules")

If InvChangeBit = 0 or InvChangeBit = 1 then
controlDef.Execute2(True)
End if

[Anonymous]

Thanks, Martin.

I use Excel parameters primarily because these parameters are tied to other functions outside the scope of Inventor. So, the Excel workbook kind of becomes the central hub of control for data related to assemblies. It gives employees the ability to perform any function related to an assembly from one location, even if they don't use Inventor.

[Anonymous]

So, the Excel parameters are link to each part document and the assembly document independently.

Here's the actual code I use for iLogic to update the assembly:

If ParameterChangeBit <> InvParameterChangeBit Then

	InvParameterChangeBit = ParameterChangeBit
	RuleParametersOutput()
	InventorVb.DocumentUpdate()
	iLogicVb.UpdateWhenDone = True

End If

The thing is, "ParameterChangeBit" is an excel parameter. So, in order for the rule to be triggered, this parameter change is recognized as an event. By that, I can assume that the excel parameters must have been read and updated. Otherwise, the rule wouldn't run. I even made "ParameterChangeBit" the last parameter on the list, so that it would be the last one to be updated (or so I assume).

Is it possible that either 

iLogicVb.UpdateWhenDone = True

or 

InventorVb.DocumentUpdate()

are only updating the assembly document and not any of the parts within the assembly? Anything assembly related like mate distances and patterns, etc. update fine, but anything part document related isn't really updating.

[martin_winkler]

I think the way you do it is a bit complicated and made no good performance.

I suggest you this workarround:

1. Create a new ipt only for your Parameters (fx.ipt)

2. Create a connection to all of your Excel Parameters in this fx.ipt

3. Create in the fx.ipt all  Parameters as User defined Parameters (for example Excel Parameter Name is A than create a User Parameter A_fx with A in the Expression. If it's later could be necessary to Replace the Connection to the Excel Table with anonther one then don't put A in the expression but whright an iLogicRule that puts the Value from Parameter A to A_fx ( A_fx  = A). Otherwise you run into problems with the Parameter names when replacig the Excel Table. If you have al lot of Parameters writing the rule could be automated

4. Go to all of your parts and assemblies and replace the connected Excel Table with the fx.ipt and use the UserDefined Parameters (*_fx)

Here is also the same issue as in Point 3. If it could be able that you later want to replace the fx.ipt, put the Values into the part form the fx.ipt to the part or Assembly with an iLogicRule.

What happens now:

You change a Parameter in Excel

Save the Excel Table

fx.ipt get the new Parameters .Perhaps here is the Update you use necessary but i remind this happens also automatically

because the fx.ipt is updated you only have to make one Document Update at your assembly and all of the other parts and assembly should get the right Parameters. It's much more quicker and safer than using the Excel Table in all Parts/Assys. If you are using the variation with iLogic Rules additionally once RunAllRules from your Assembly.

I handled with this technic large and complicated Assemblies and made good experience. In my case i am using only fx.ipt without Excel, but this should be no problem. It's only one step more reading once Parameters from Excel.

Which Version of Inventor do you use?

If you would like i create a little example for this.

For your interest: I am working actually an a tool that read/write Parameters and iProperties directly from/to a Database (for example ERP Databse)

So Inventor could be driven directly from the database or put informations to the database.

[Anonymous · Accepted solution]

Ok, I figured out how to make it work. I added an extra step for Inventor in between the rule by setting the Excel parameter "ChangeBit" to a user parameter called "ChangeBit_" and then made the rule look for the value of "ChangeBit_".

If I had to guess, since "ChangeBit_" has a dependency on an Excel parameter, it probably has to wait until Inventor is finished reading the Excel parameters before it's allowed to write the value of "ChangeBit" to "ChangeBit_"

I did try creating a part to store parameters, but that didn't end up suiting my needs since I was forced to hit the update button for anything to update at all. It was also a little cumbersome to create user parameters for each Excel parameter. I just didn't really see any benefit in doing this.

[Anonymous]

Good day Martin, 

I've been having some issues directly related to the issue you are talking about with the link between all parts and excel spreadsheet. Could you give me more details on your workaround with a FX part?

I'm in the process of automating all my assemblies, and my goal is to have have all of them linked to the same Excel file named AUTOMATION_DATA.xlsx. I took this route because I use excel to handle all my complex calculations and also use it as a database. I currently have over 250 equations/variables, so it's the only way I can see that can work well.

But now that all my sub assemblies/parts are linked to AUTOMATION_DATA, if I make a change, all the parts get messed up and I have to manually re-link everything (edited paramaters become yellow)... It's been a real headache, your advice is very appreciated!

Thanks,

Julien Bourque