Using VB based forms in iLogic Trick

I was recently building a form in VB.NET using Visual Studio Express and was faced with the task of wiring it up to Inventor.

In case you've never done it before, you need to use an iLogic rule to pass current parameters to the form class then back again.  This is typically done as follows:

' add a reference to the DLL hosting the form
AddReference "myAutomation"

' make the connection to the form

Using dlg As New myAutomation.MainForm


' shows the dialog
Dim i As Integer = dlg.ShowDialog()

' pass parameter info to matching variables in the form code

dlg.PreOrder_Initials = iProperties.Value("Custom", "PreOrder_Initials")
dlg.Shop_Order_Number = iProperties.Value("Custom", "Shop_Order_Number")

dlg.Customer_Stock_Number = iProperties.Value("Custom", "Customer_Stock_Number")

When the form closes you need to reverse the process and pass the data from the form back to Inventor, so those three sample lines become:

iProperties.Value("Custom", "PreOrder_Initials") = dlg.PreOrder_Initials
iProperties.Value("Custom", "Shop_Order_Number") = dlg.Shop_Order_Number

iProperties.Value("Custom", "Customer_Stock_Number") = dlg.Customer_Stock_Number

Seems simple right?  And, it is, unless you've got a complex form and 300+ parameters to hand back and forth.

Those that follow this blog know that I"m a huge fan of Notepad++ for creating/editing external iLogic rules.

Using a free add-in for Notepad++, called FingerText to create some shortcuts that allowed me to quickly create my initial entries for pushing values to the form.  But, now I was faced with essentially mirroring the string about the "=" sign.  To me that represented a ton of selecting, copying, replacing, etc. and I could tell that somewhere along the line I would get distracted or fat finger an entry then have to track down the bug.

My saving grace was learning that I could use Notepad++ to do the switching for me.  Here's the process I used:

1. Copy all the dlg.xxx lines and pasted them into the same document after the .ShowDialog() line.  These would become the code that would pass the form values back to Inventor.
2. I used the Notepad++ Replace function to find and mirror the text for me using a regular expression.

In the Find what: cell, enter:   ^(.*)=(.*)$

In the Replace with: cell, enter: \2 =\1

Set the search mode to Regular expression

After that it's a simple matter of Find Next and Replace.  I caution not to use Replace All as it will also mirror your originals.

dlg.UID = iProperties.Value("Custom", "UID") becomes

   iProperties.Value("Custom", "UID") = dlg.UID at the click of a button.  It doesn't get much simpler than that!

I hope that you find this little trick useful.

Happy Coding,

Format Your Code: Part I

Have you ever had to make changes to your iLogic code?  Or maybe you’ve had to review someone else’s code?  It can be a little overwhelming to open up an iLogic rule and find 500 lines that look like the image to the right…..

While there are no hard and fast rules about formatting code in the iLogic Rules Editor you’ll find that if you format your code following some basic guidelines and tips that you (and others) will be able to understand your code much easier, therefore saving time and money.

Over the next few blog posts I'll go over five different methods you can use to make your code more ‘user friendly’ in the iLogic Rules Editor.  Those five methods are Collapsible Code Regions, Indentation, Line Breaks, Empty Spaces and Commenting. 

Most of these methods are built in to programming environments such as the Visual Basic Integrated Development Environment.  Maybe some day we'll get them in the iLogic Rules Editor.

Collapsible Code Regions

Collapsible code regions allow you to group together bits of code which you can collapse and expand just as you do with features or components in the Inventor Model Browser.  This will help you and your reader navigate your code as well as clean up how it looks.

You define the beginning of a collapsible code region by inserting a single quote and a left square bracket: ‘[.  To define the end of the code region, insert a single quote followed by a right square bracket: ‘]. 

Notice the hierarchical outline tree that is to the left of the code.  You can also have nested collapsible code regions.

You can collapse and expand the code by clicking on the icon at the top of the region.  It will be a minus sign (-) if the code is expanded and a plus sign (+) if it’s collapsed.  A collapsed code region looks like this:

You can also collapse and expand the code by using the Outlining tools.  Place your mouse in the expanded code you wish to collapse, right click and choose Outlining > Toggle Outlining Expansion from the contextual menu.  This works the same as if you had clicked the (-) sign at the top of the code region.  The benefit here is that you don’t have to scroll the 200 lines to get to the top of the code region.  If this is done on collapsed code, it will expand.  Repeated use of the Outlining > Toggle Outlining Expansion will toggle back and forth between collapsed and expanded code.

Another wonderful Outlining tool that is right at your fingertip is the Toggle All Outlining option.  This will collapse and / or expand all collapsible code regions in the rule.  I recently had a rule what was approximately 5,000 lines and I would use the Toggle All Outlining and then expand just the section I wanted to work with.  I found it much easier than hiding a ‘here comment in my code and using the search command (I always seem to forget to delete those ‘here comments).

The other tools that are available on the Outlining fly-out are:

Stop Outlining:  This will expand all collapsed code regions and disable the ability to collapse code.  Once you’ve done this, you’ll then have a new option called Start Automatic Outlining

Collapse to Definitions:  In other programming, Collapse to Definitions will collapse your code down to the definitions in the procedure.  In iLogic, this function works the same as Toggle All Outlining.

You can also start and stop the outlining by using the button that is just above the vertical scroll bar.

"Good design adds value faster than it adds cost." ~ Thomas C. Gale

Thanks,

Randy

Debugging iLogic under Windows 10

A while ago I posted on debugging methods using SysInternals DebugView.  Well, this past week IT upgraded my machine from Windows 8.1 to 10 and with a few small exceptions things have been working well.

Until I went to begin debugging an iLogic rule and while DebugView launched fine and loaded my existing filters like a champ, it just sat there with a blank look on it's face.

I'd have sooner given up my right arm than agree to forego DebugView on the new platform.  I immediately reached out to a team member who I knew had been on Win10 for a while and uses DebugView daily.  "No problem here", he states...crap, the problem is local.  Or maybe not...


Like most when faced with a quandary of monumental proportion, I did a Google search and came up with the following post on Sysinternals forum:

Topic: DbgView and Windows 10

The first post almost broke my heart.  Not compatible with Windows 10?  Are you kidding me?

Fear not, keep reading...

About 2/3's down the page alanadams had an interesting comment about his experience with the problem. It seems that DebugView silently installs a .sys file in the ...\System32\Drivers folder.  Once there it seems that Windows keeps it from being written again because Windows says the driver is already running.

The solution?  Rename the original dbgv.sys file, then restart DebugView.  For some reason that seems to pacify Windows and lets DebugView run normally.  Who knew?

alanadams claimed, (at least for him), that this only fixes DebugView for that session and the step may need to be repeated, but for me at least DebugView continues to run even after several restarts including reboots.

I also run DebugView as Administrator just because I can, not necessarily because I need to.

So, hopefully you're like my fellow co-worker and DebugView works right out of the box, but if not you now have something to potential ease the pain.

Happy Coding,

Multi-Value List Controls

We often use multi-value parameters in our automation projects as they are a way to offer options for your end user to select from.  Usually you, as the developer, will want to limit these options to what’s available, either due to selections already made or other constraints.  In this post, we’ll describe how to control values for one option based upon another selection.

Have a look at the User Interface (UI) shown below for a conveyor design by Salt Automation.

When the end user selects a Duty Cycle of Heavy, the Motor Selection options should be 7-1/2 or 5 hp, as shown in the image.  But, what if the options need to change when the end user selects a Duty Cycle of Light, to either 2 or 1 hp?

Let’s take a look at how we can accomplish this.  We can set the value options for the Duty Cycle parameter in either the Parameters dialog box via traditional methods or we can set it via iLogic code, using MultiValue.SetList.

The scheme for the MultiValue.SetList is:

    MultiValue.SetList("parameter name", "value 1", "value 2", "value 3")

In our example, it would look like this:

    MultiValue.SetList("Duty_Cycle", "Heavy", "Light")

The benefits to setting the value options in code versus the traditional method are that you can set the order in which you want them displayed but more importantly, you modify the value options at run-time through your code.

Let’s look at how we can modify the value options of our Motor Selection parameter at run-time.  We’ll do this using the Case structure.  This could also be done with an If Then statement.

    Select Case Duty_Cycle

        Case "Heavy"

            MultiValue.SetList("Motor_Selection", "7.5 hp", "5 hp")

        Case "Light"

            MultiValue.SetList("Motor_Selection", "2 hp", "1 hp")

    End Select

The code above will set the Motor Selection options based up on the selection of the Duty Cycle parameter.

The entire code is listed below.  I am also setting the ValueOptions, which will be covered later.

' Set multi-value options

    MultiValue.SetValueOptions(True, DefaultIndex := 0)

    MultiValue.SetList("Duty_Cycle", "Heavy", "Light")

' Set Motor Selection based on Duty Cycle

    Select Case Duty_Cycle

        Case "Heavy"

            MultiValue.SetList("Motor_Selection", "7.5 hp", "5 hp")

        Case "Light"

            MultiValue.SetList("Motor_Selection", "2 hp", "1 hp")

    End Select

“Don’t worry if it doesn’t work right. If everything did, you’d be out of a job.” ~ Mosher’s Law of Software Engineering

Thanks,
Randy

Using iLogic with Autodesk Configurator 360 Webcast

Hey everyone,
Wanted to give everyone a heads up that our own Carl Smith will be hosting an upcoming webinar on using iLogic with Autodesk Configurator 360.  It's free and I'm sure you'll pick up at least one thing that will help you in all your automation endeavors.

Using iLogic with Autodesk Configurator 360
October 08, 2015 | 11:00 AM
Online | Manufacturing

Join us for this complimentary webcast as IMAGINiT expert Carl Smith explores how Autodesk Configurator 360 enables you to upload existing Inventor models to the cloud and create custom-branded 3D configuration experiences to impress your customers, give them what they need, and help grow sales of your products.

Register Now

iLogic Authoring Tools

Autodesk Inventor comes with a built-in iLogic rule editor.  The iLogic rule editor, (Integrated Development Environment), can be very useful when learning to write iLogic code.  The IDE provides a built-in Snippet library as well as instant access to model parameters, etc.

But as iLogic rules become more complex or lengthy you may find waiting for the rule editor to open tedious an inefficient.  Those who know me will say I'm not a terribly patient person.  Come on already, I've got code to write!!

Additionally, as you begin to integrate more complex Inventor API calls and general .NET functions you'll find that the native rule editor does nothing to help in terms of Itelli-sense or syntax warning such as parenthesis matching.  It doesn't hurt your development efforts, but it doesn't help either.  The old adage, "If you're not helping, you're in the way", comes to mind.

In previous lives many of us used Windows Notepad to write AutoCAD LISP code.  This same simple workflow can apply to iLogic rule code as well.

Given the fact that iLogic code is not compiled and is in fact a simple ascii text file, you can virtually use any text editor you wish.  My favorite is Notepad++.  Notepad++ is an open-source text editor, is distributed free of charge. NOTEPAD++ DOWNLOAD

One of the things that makes Notepad++ such a great authoring tool for iLogic is that while it does a great job of editing text files, it can be configured to recognize the programming language format you're using and provide really nice features like color formatting, auto-complete, etc.

Additionally, there are numerous plug-ins for Notepad++ available, also free of charge. One of my favorite plug-ins is 

The following is a step-by-step process to configure Notepad++ to recognize the .iLogicVb file format.

1)  Navigate to Notepad++'s Settings>Style Configurator menu.
2) Scroll down the Language list selecting VB/VBS.
3) Add iLogigVb as a recognized user extension.
4) Adjust your color settings as desired for Comments, Numbers, Keywords, etc.
5) Add any special iLogic keywords that you wish, (keywords should be entered in lowercase only, regardless of how they're typed in the code)

This configuration gives you this:

Instead of this:

I should have added the disclaimer at the beginning of this article that to really make this workflow shine you should be using external rules.  When using external rules simple make edits in Notepad++, jump over to Inventor and run the rule.  No more waiting for the native rule editor to load the code.

Notepad++ has the added benefit of line numbers, and natively collapsible code due to the association to the VB file type.

If you're doing serious iLogic development you really owe it to yourself to check out the benefits of using Notepad++ as your iLogic development platform.

Taking the mystery out of debugging

One of the complaints I hear most often from clients and other iLogic developers is the inability to debut iLogic code from within the iLogic IDE.  I've shared similar frustrations as I'm generally a brute force kind of programmer...write some code, run it, see what breaks, fix the error, then plunge ahead again.

Don't get me wrong, I ALWAYS plan out the workflow and general design criteria of what my code needs to do ahead of time, but sometimes the semantics are either not important or completely apparent before I begin writing.

I've come to rely on a few 3rd party tools to aid my debugging process.

Method #1: Utilize the built in debugger to decipher syntax errors

An often overlooked method of debugging iLogic code is the iLogic interface itself.  When asked to run code that generates an un-handled exception iLogic will throw a message box like this:

 

Not terribly informative.  But have you ever taken a look at the More Info tab?  You'll see a much more descriptive display of just exactly what the problem is.

Ah,...I declared a variable as a an Integer then tried to fill it with a string.

Dim i As Integer = "string"

Granted, a silly freshman mistake, but after all, this was meant as an simple example.
Don't be too quick to dismiss the simplicity of the built-in compiler debugger.

Method #2: DebugView

DebugView is a free tool distributed by Microsoft Technet.  Usage is described on Autodesk's Manufacturing DevBlog: Debug iLogic Code.  Adam Nagy does a great job of describing the basic features of DebugView and how to set it up for tracing errors in an iLogic rule.

DebugView has some really nice features such as being able to add custom filters giving a very colorful output, highlighting specific lines.  Here I've added a filter containing the text "iLogicErr".  Anytime that DebugView reads a Trace statement containing the phrase "iLogicErr" it will highlight the line making in my case errors quickly identifiable. 

In this instance I've used a Try/Catch block like this:

Try

   ‘your code goes here  

Catch ex As Exception

    Trace.TraceError("iLogicErr: #2")

End Try

Download DebugView here.

Structure the suspect code, (wrap the whole rule if necessary), as follows:

Try

   ‘your code goes here  

Catch ex As Exception

    Trace.TraceError("iLogic: " & ex.Message)

End Try

This will pass back the actual the error message that was encountered, either by Inventor or Windows.  You may still need the rune stone to figure out the cryptic generic message that iLogic throws, but you'll be in a much better position to correctly handle the exception like this:

Catch ex As Exception

    Trace.TraceError("iLogic: " & ex.Message)

    Exit Sub

    ' Goto Foo

    ' provide other useful user feedback

End Try

As an added bonus, check out my associated abbreviated DebugView article here:

Taking the mystery out of debugging

Method #3: Visual Studio
The final method takes a little more effort to set up, but overall does give you more verbose and complete feedback when debugging code.

You might be thinking that wait a minute, I'm writing iLogic code, why do I need Visual Studio?  Well, I remind you that iLogic is running on top of the Microsoft .NET Framework and the iLogic IDE is really a sub-set or wrapper around some build in .NET functionality.

This built in functionality comes to our aid in the fact that that .NET calls and functions work "EXACTLY" the same in iLogic that they do in iLogic.

First, you must have a copy of Visual Studio.  I always like free and recommend using Microsoft's Express version of Visual studio.  You can download Visual Studio Express Desktop 2015 here.  VS Express Desktop 2013 is also available on the same page.  Download your preferred version and install.

To set up your debug environment start a new VB Console Application project.  You can save it using any name and location you wish.

Next you'll probably want to add a reference to Inventor so that you can take advantage of Intelli-Sense within VS.  To do this Right click on References in the Solution Explorer and browse to "C:\Program Files\Autodesk\Inventor 201(n)\Bin\Public Assemblies\Autodesk.Inventor.Interop.dll"

Next add an Imports Inventor at the top of your console app Main Module.  Starting to look familiar?

We're really working with our code at an Inventor API level, but with a few syntax changes Visual Studio can provide a superb debugging tool.

Next let's add some functionality to our code.

Time to debug!  Add a break point by clicking in the left margin.  You'll see a little red dot appear indicating where the code will stop.

We can step into this code by selecting the Start button on the main toolbar.  The code will execute and run, stopping on our break point.  And here comes the sweetness that is Visual Studio, we can step through each line, hovering over variables and objects to determine values immediately, all while the code is running. 

You can step through each line by pressing F11 or selecting the Step Into button on the Debug toolbar, (if the Debug toolbar is not visible GoTo View>Toolbars>Debug).

After stepping past the line where we declare ThisApplication, I can hover the mouse over ThisApplication and by drilling down several levels I can see this:

Powerful stuff!  While it takes a little to set up, 'most' iLogic code can quickly be converted to run inside VS.  In fact, to make my life easier I keep a VS project on my development machine that's already set up with the Inventor.Interop reference so all I have to do is plug in my problem code and set to work debugging by stepping through the code.

I hope you find this article useful.

Happy Coding!