VI works in IDE, not after being built

[SimonGoodson]

This is going to be a little long, but I'm not sure I have a choice. I'm using Mark Yedinak's SNMP v1 driver in LV2014 32-bit to talk to a Dell G756N rack mounted power distribution unit (think fancy power strip). My code works just fine in the IDE, but causes the program to freeze after I have built it into an executable. I have no idea what is wrong. I built a simpler example VI intending to have an easy example project (Classy Talker.vi in the SNMP Talk project) of where the VI breaks down, but it seems to work even after being built into an .exe. I built the InitializePDU.vi (the one that works) in the SNMP Talk project by dragging the innards of the problem vi (InitializeEquipment.vi in the Dell Power Supply Testing project, this one doesn't work after being built), so they should be identical.

Using logs, I've been able to track which one is the problem vi. It's the Get snmp Item(s).vi in Mark's snmp communication.llb. Here is a picture of where it fails according to my LVLog.txt file:

To recap:

In the Dell Power Supply Testing project

The Data Collection Quick Shot.vi under "Main" calls Initialize All Equipment Data-Clock.vi. The Initialize All Equipment Data-Clock.vi is responsible for reading the Equipment Config.xml file and presenting the user with choices of equipment to use with the program. The .vi then uses a factory pattern to initialize chosen equipment. 5 of the equipment types work, but the Power Distribution Unit will not complete verification after being built into an executable (this is event 10, "PDU Verifiy), but works fine in the IDE. Using logs, the probelm occurs after the class is cast to the specific class in the InitializeEquipment.vi found under "Hardware\Power Distribution Unit\DellG756N\" when it call Mark Yedinak's Get snmp Item(s).vi from his snmp communications.llb.

The SNMP Talk project was created to be similar to the problem areas of the Dell Power Supply Testing project. I was hoping it would be a simpler example so that I could get help, but to my suprise it works just fine even after being built into an executable.

The Classy Talker.vi casts the GenericPDU class to the DellG756N class, and uses the InitializePDU.vi which is the equivalent to the problem vi InitializeEquipment.vi in the Dell Power Supply Testing project. It then just reads the manufacturer and part number from the supply, which is also done in the same manner as the InitializePDU.vi.

Any help on why one built executable work and the other does not would be really appreciated.

Thanks,
Simon

P.S. I couldn't power the Power Supply Testing project here because it is 54MB, so here is a link to it in my dropbox:

https://dl.dropboxusercontent.com/u/10871313/Power%20Supply%20Testing.zip

[mikeporter]

Try setting the vi that seems yo be hanging to open its front panel when call so you can see what is being passed to it.

You could also try remote debugging.

Mike...

[chembo]

Do you have the NI LabVIEW Desktop Execution Trace Toolkit in your LabVIEW license. It helps a lot for debugging strange behaving code

[SimonGoodson]

Guys, thanks for pointing these things out. I don't work extensively in LV so I am not aware of all the debugging options and standard procedures. I'm going to look into the trace toolkit (we have it) and remote debugging to see what I can do. I will report back.

Thanks again,

Simon

[SimonGoodson]

So I tried both the remote debug and the trace toolkit. Remote debugging just caused the program to freeze before it opened the front panel. I know via the text log that the program executes at lease some of the code before freezing. The trace toolkit didn't seem to show anything. It seemed to connect to the program though, so I don't know what the issue was.

Currently I'm trying to get a hold of the NI Rep. We are only a couple of miles away so hopefully it won't be a problem. I will update if we solve it.

Thanks,
Simon

[chembo]

This is strange. The Desktop Execution Trace should show you at least the VI's calls, when a VI starts, finishes, etc... You can even add the  Generate User-Defined Trace Event function (Desktop Execution Trace Toolkit functional palette) in your code and make sure they execute as expected.

Did you check the selection in the Capture Settings and made sure that the trace actually started when your program runs?

[SimonGoodson]

The trace is definitely started, but I didn't check the trace. Looking at the defaults I should have seen something, but perhaps I didn't get the right vi. The only choice I have is "Main Application Instance". My executable is called "Data Collection Quick Shot:" though. Do I have to add the Generate User-Defined Trace Event function to the vi to enble the Trace Toolkit?

Thanks,
Simon

[chembo]

I always pick the project file as 'Application Instance'. In this pull-down selection you should see your project also. If not, you need to enable the VI Server for the project in project window: My Computer (right click) / VI Server. Probably you need to restart LabVIEW or reload the project if you made any changes.

When you select the project as 'Application Instance' and run the trace, then start the main program, it should work. All that said is valid for development environment.

If you want to trace the executable, you need to start it first, select it as 'Application Instance' and run the trace. Maybe there is an option to trace from the very beginning, but I didn't find it yet.

What I usually do, when I need to trace a program right from the start, is to include a dialog before anything else is running, which will wait for user input/click. The I can select the executable in the trace, run it and continue with program execution.

[chembo]

---

@SimonGoodson wrote:

...............

Do I have to add the Generate User-Defined Trace Event function to the vi to enble the Trace Toolkit?

Thanks,
Simon

---

I missed this one. No, you don't have to add them. This is optional. I use this functionality in order to find easier particular steps of the trace, or to display the value of a variable in the trace. Filters and Search help also a lot to find exactly what you are looking for because, depending on the capture settings and execution speed, you may get very long code traces.

[SimonGoodson · Accepted solution]

To follow up, Drew Pierce from NI came down to look at the issue. The morning before he came I was expanding my use of log files and finally had an executable build work. I was a little too quick to think I had the issue solved and threw a 2ms wait where the last log file was thinking it was a timing issue. Nope, it was broken again. So I put all of the logging functions back in, then took them out 1 by 1 until I found the one that fixed it. I have no idea why it fixes it, but it does. The offending vi is Mark Yedinak's SNMP Get Request. Here is the fix:

And the Write Log:

I have no idea why this works and just putting a wait doesn't:

If anyone has a theory I'd love to know.

Thanks,

Simon

P.S. I want to be clear that I'm not saying Mark's code is bad, it works flawlessly elsewhere and I'm very thankful he provided it. It has saved my life on this project.