DAQ commit and GPIB write at same time freezing compiled exe?

[Mako]

I'm having a weird issue with a compiled LabVIEW EXE completely freezing, while it's okay within LabVIEW.  I had a heck of a time getting it down to a testcase, but finally narrowed it down to a DAQ reserve operation happening at the same time as a GPIB write when there is an error present.  There's an image of my testcase VI attached, and I can add a compiled EXE if anyone wants to see one.

The symptom is that the program will completely hang as soon as you try to do anything that touches the windows chrome around the interface; that is, you can toggle front-panel buttons, but the instant you click a menu (or programatically open a One-button dialog) the program becomes completely unresponsive at the system level.  It's not just stuck in a loop; Windows reports it as "not responding", the menus don't respond, and nothing short of a manual termination from the Task Manager will kill it.  CPU use is at 0%, and memory use low.  Same thing happens on both XP and Win7.  If I run the external debugger, it loses the connection when the program hangs.

It's obviously some sort of resource-allocation race condition, I'm assuming maybe with the error handlers, because it doesn't happen 100% of the time, and if you do get the program to successfully run once it can be re-run without incidente repeatedly, so long as you don't close it.  Adding a short (~1sec) delay before doing one of the operations causes it to work reliably.

The odd thing is that it works fine when run from within LabVIEW itself; the problem only happens with a compiled binary.  I can work around it easily enough by putting in an init delay, but I'd kind of like to know why this is happening--is it a LabVIEW compiler bug, or something I'm just not understanding.

[David-A]

Hi Mako,

The issue could be that your VI gets stuck indefintly in a loop.  For example your GPIB loop references a shared variable that is not referenced anywhere else in your screen shot.  There may also be an issue with your application builder if it is an evaluation copy.  Are you using a developers copy of labview?  Also, would you be able to post a sample of your code?

David A.

[Mako]

Thanks for the follow-up.  I continued to prune it down to the attached bare-minimum testcase; it does nothing but use the convert channel names to string fuction and a single GPIB write, simultaneously.  There are no loops, no external VIs. and no variables.  Even the case structures only exist to allow the two actions to be turned off, and to allow me to wire the error output to something so that it doesn't trigger the error handler.

I've attached a PNG of the block diagram, the saved .vi file, and a complied .exe with debugging enabled.

This repeatably freezes hard on both an XP and Win7 system if you run the testcase .exe when neither device is attached (and therefore both VIs would be generating an error).  It's not 100% of the time, but it is about 80-90%.  If the compiled program completes execution once, it can be re-run repeatedly without issue.  Similarly, if you add a delay before doing one of the two operations, it's fine.  And it always, so far as I can tell, runs fine from within LabVIEW--only the compiled .exe freezes.

This was built with a complete install of the 2010 Development System, SP1, with an Academic license.

[David-A]

Hi Mako,

There are a few issues that may cause your application to freeze.  The first is a lack of error handling.  Your GPIB Write vi is throwing an error.  If you wire that error wire to a Simple Error Handler vi the application will not freeze and will instead prompt you with an error message.  

The other issue is the error itself.  Error code 7 is bein thrown which is created when there is a "Nonexistent GPIB interface."  Make sure you have your GPIB device connected when you attempt to write to it.  The vi takes a long time to timeout when it is trying to write to a device that isn't there and which may be the cause of the freezing behaviour.  

To aid the debugging process you may want to enable debugging when you build your application.  You can do this by selecting the 'Advanced' tab when you are in My Application Properties (this is accessed by double clicking Build Specifications in your project list).  Once at the Advanced tab, select 'Enable Debugging' and 'Wait for debugger on launch'.  You may now look at the block diagram of the built application by opening another vi in labview and navigating to the Operate menu and selecting 'Debug appliation or shared library' and then selecting your appliation in the 'Application or shared library' drop down menu.

David A. 

[JÞB]

to Echo Dave,  Check your GPIB address string from MAX on the machine. (And did you install the hardware drivers?) Better yet- punch the VISA Write in there instead of the 488 call. 

[Mako]

Thank you both very much for the suggestions David and Jeff.

First, the attached .exe was, as I said, compiled with debugging enabled, and I understand how to do remote debugging on a compiled executable.  When attempting to debug the freezing application, the debugger loses contact with it, so there's no way to look at anything that's happening.

Second, error handling isn't the issue; I wired the error output of both objects to a simple error handler, and the freezing behavior was identical (and happens before either error handler throws a dialog).  Screenshot of the block diagram attached.

I of course understand why the GPIB write is throwing an error--I ran into this behavior initially exactly because the GPIB interface and particular channels being run through the other object aren't present; the real-world use case of this scenereo is a USB-based control system that gets started up before the cDAQ device and USB-GPIB device have been plugged into the computer.  Under normal operation, the program will continue attempting to restart the two interfaces until the USB devices get plugged in, at which point it recognizes them and operates normally.

The problem isn't related to timeouts, as it hangs permanently, even if you wait a very long (1+hr) time.

I also understand that I could be using a VISA write instead of a GPIB write (and indeed it won't fail when using a VISA write), but my question had more to do with "why" than "how can I work around it."

Maybe I should back up and ask a separate question:  Is it possible, from the perspective of a LabVIEW programmer, to create an application containing no loops that will hang its own interface to the point that window redraws do not happen (you get the glitchy video buffer white chunks of a truly hung Windows app), the menus do not respond to clicks, and Windows recognizes it as "not responding"?  (With, for that matter, 0% CPU use.)

I have never managed to generate such a state via LabVIEW in the past, and I was under the impression that the window chrome and video buffer were beyond the scope of what I, using simple LabVIEW objects, was capable of causing to fail.

[JÞB]

"Is it possible, from the perspective of a LabVIEW programmer, to create an application containing no loops that will hang its own interface to the point that window redraws do not happen (you get the glitchy video buffer white chunks of a truly hung Windows app),...?"

Any thing IS possible- Windows is Windows and although I've never seen a application like yours hang I believe you when you say you saw it and can reproduce it. 

As to WHY I won't even speculate- but encourage you to adopt one of the work-arounds discovered.  You could open a SSP reruest and see if the NI GURUs can reproduce-  Send a technical report generated from max as well so they get the info to exactly duplicate the issue.  and keep us posted if a CAR is generated