Expand and customize iLogic capabilities

You can place iLogic rules in external files rather than store them in the Inventor model. This storage method allows you to use the same rule in several different places.

To store rules in an external file, you first set the default file extension for new files. The default extension you choose depends on how you want to edit the file. For example, you can set the default extension to .vb if you want to edit files in Visual Studio. An extension of .txt lets you edit the rule with a text editor such as Microsoft Notepad. Or, you can set the default extension to .iLogicVB if your files contain standard iLogic rule code to be preprocessed by iLogic.

iLogic rules can use code in other .NET assemblies. You can specify the directory in which these .NET assemblies are located. You develop a .NET assembly with programming tools such as Visual Studio 2008. See Advanced Rule Programming for more information about using .NET assemblies in rules.

iLogic provides an automation interface. You can use this interface from Inventor VBA, or VB6 or .NET code to access parameters and rules.

The class iLogicAutomation enables this capability.

In a VBA or VB project, you use it as a late-bound type (declared as an Object) without adding a reference. Because it is not a full .COM object, you cannot browse its methods.

iLogic uses a custom data type called DoubleForEquals to store parameter values. DoubleForEquals supports easy comparison of numbers. This parameter is like the standard VB.NET type Double. Except that DoubleForEquals values are compared as if they were Single values (7 decimal places instead of 15). By default, parameters in rules are declared as DoubleForEquals.

DoubleForEquals makes it easier to ignore round-off error in comparisons. For example, suppose your part uses inches as document units, and you have a parameter with a value of 13/16 inches. The part is not exactly equal to 13/16 in a rule, because the parameter value is stored in centimeters in the model. The value is then converted to inches for use in the rule. Consider the following comparison:

if d0 = 13/16 then ... 

In this example, the comparison fails if d0 is of type Double. However, if d0 is of type DoubleForEquals, the comparison succeeds.

DoubleForEquals stores the value as a Double type and performs all calculations as Double values. Only the comparison is performed as a Single.

You can convert a parameter value to a Double using the CDbl function, if necessary.

DoubleForEquals is a Structure (a value type) in VB.NET.

DoubleForEquals treats comparisons to zero as special cases. When one of the numbers being tested for equality is exactly zero, the test succeeds when the other number is less than 0.0000001 (in absolute value).

This comparison makes it easier to ignore round-off errors that are close to zero in value. For example, the following comparison determines that x = 0:

angle = PI/2
x = cos(angle)
If (x = 0) Then
...
End If

DoubleForEquals is the default type for all Inventor parameters used in rules. You can disable this setting for the following reasons:

• You use library functions or custom code that requires the Double type. All efforts have been made to enable transparent conversion to Double. However, if a function expects an argument of type Object, no conversion is performed. If a DoubleForEquals object is passed, the function can possibly expect a Double type. You can either use CDbl or disable DoubleForEquals.
• You require more control over equality tests or comparisons in the rule. For example, you want to specify your own tolerance.
• Your rule does not include any equality tests, and you prefer to avoid the overhead of DoubleForEquals by using Double directly.
• Your rule does include some equality tests, but the parameters are outside of the dynamic range of a Single value (approximately 1.4e-45 to 3.4e38). Although this situation is unlikely in an Inventor model, it is possible with non-length units.