Can I get help with a perplexing LabVIEW crash bug?

[Joel_L]

After attending the developer day, I thought this might be a good place to find someone with superior debugging knowledge to help with a serious crash bug I'm having in my current project. I can't figure out what's going wrong and not only is it driving me crazy it's gating my major project for the year. If you like a good puzzle (or you're an NI employee who knows about these things) please help me out.

I've attached a VI called "AUTOCRASH 2 Set Analog Channels.vi". It reproduces the crash problems I'm experiencing with a minimum amount of code.

My system:

Computer: Lenovo ideacentre PC, Windows 7 SP 1 64bit 8GB RAM Intel Core i7 2.92 GHz CPU

DAQ: PXI-1045 (18 slots) with PXI-6722 in slots 2-9 and PXI-6254 in slots 10-17 through a PCI card.

LabView: 2011 SP1 11.0.1f1 32 bit Full Development System.

I think I have a pretty late DAQmx installation, from the August 2011 or February 2012 distribution.

After loading "AUTOCRASH 2 Set Analog Channels.vi", click "Run Continuously". The "cycles" counter should gleefully increment as long as you let it.

Stop the continuous run.

Click "crash?" This only changes the signal sent to "DAQmx Write.vi."

Click "Run Continuously". The VI should freeze before two cycles pass. The entire computer may BSOD after some time.

Other things to play with:

Click "override crash". This should prevent the crashing completely by calling "DAQmx Clear Task.vi" immediately after "DAQmx Write.vi".

Click "delay crash" (and turn "override crash" off). This should let the VI survive several more cycles before crashing. This setting enables "DAQmx Clear Task.vi" after all 8 channels on all 8 cards have been set. (It puzzles me that this has any effect, since I thought DAQ tasks were cleared anyway when an app stops running.)

With "crash?" off,

set "signal length" to 2 to crash the VI.

With "crash?" on,

setting "channels" to 7 or less should prevent a crash.

setting "cards" to 3 or less should also prevent a crash, even with "channels" set to 8. Setting "cards" to 4 or 5 slows the cycle counter (and probably gradually approaches crash conditions)

changing "dt" shouldn't have any effect.

If anyone has any insight on how this could be happening please contact me at joel.d.limmer@seagate.com.

This VI is a boiled down version of a much larger set of code that still duplicates the crash. The larger set of code fails under a larger set of circumstances than this VI (e.g., the crashing doesn't go away on the larger code if I set the signal length to 8, or 16, or even 32) so I'd like to get to the core of what's wrong, and I also don't want to be "harmlessly" overwriting memory until the app mysteriously crashes at random one day. I can't Clear every output task I start because in the real program I need to keep waveforms running after the VI exits.

Please help! Thanks. Also, if this is the wrong forum for these questions, please let me know.

Joel Limmer

[JÞB]

You cought me moments after I sent this e-mail to a co-worker

"

I suspect the XXXPiece of code won’t be reliable in production.

With DAQmx in LabVIEW you get to create 4097 tasks for free. The 4096^th will error then, you get to close LabVIEW to clear the error.  This is why I usually create the tasks in either the Project or MAX then just use them.  It does add overhead to the deploy process but, it’s the best way I’ve found around customer’s complaining about “The app just crashes randomly with DAQmx errors like this:”

Create your task once.

[Joel_L]

That's good to know, and I'll take it into account in my coding. I am not getting that error window (or any error window), and sometimes the crash takes the whole operating system down with it.

Can you get more tasks if you Clear existing tasks? I usually only have 8 open at any given time, though I keep opening and closing them in order to change the waveforms on the channels.

[ninetysix]

See attached.  It's messy because I left a lot of your existing code in there - but it creates the task only once.  The task is the same and you configure the channels within the task before outputing that to another loop which controls the writing of the output.  If you don't explictly create a task it will create an "un-named" task for you - up until a point as mentioned above which can cause issues.  I may have missed somthing in quickly modifying your example, but you probably get the idea.  It isn't clear if your final program is using the run continously button as a method of execution, but I would personally avoid doing that and instead have a main loop with a loop wait time and a stop button for the user.

Hope this helps.

[JÞB]

JoelL wrote:

That's good to know, and I'll take it into account in my coding. I am not getting that error window (or any error window), and sometimes the crash takes the whole operating system down with it.

Can you get more tasks if you Clear existing tasks? I usually only have 8 open at any given time, though I keep opening and closing them in order to change the waveforms on the channels.

Not really. 4098 seems hard coded itnto windows.  (garbage collection really DOES destroy references- not the LabVIEW RTE)

With or without the exception being thrown by the OS, just feel free to "Code it once"

[Joel_L]

ninetysix--

Thanks for the code. I think I see what you're getting at.

So if I use Create Task once, I can use Create Channel and Timing on that one task to redefine it as often as I want without generating a new task? My application is constantly reconfiguring the timing and triggering and output waveforms of the 64 AO channels I'm working with. For some reason I got the idea that you had to Clear and Re-Create the tasks in order to redefine the timing.

FWIW, I'm not using the Run Continuously button in my application, I'm just Clearing and Re-Creating my analog output tasks a lot as I redefine the signals that go out as part of a 300+ vi application which I cut back to one VI to duplicate my crash bug.

[JÞB]

So if I use Create Task once, I can use Create Channel and Timing on that one task to redefine it as often as I want

That's once more than you need to create the task at run time!  You only need to create it once EVER. I save mine in the project.

[Joel_L]

Thanks for all the ideas--

I'm attaching a different version of the crashing VI, where I create all 8 tasks (one for each DAQ board) at the beginning and then use a While loop to do my cycles, redoing the Timing and the output signal each loop iteration.

It still crashes when "crash" = TRUE, and doesn't crash when "crash" = FALSE.

I haven't checked the output channels with a scope or anything to see that they are what I want, but no errors occur. Just the crash. I also haven't played with the number of boards or channels.

Still looking for insight...

[JÞB]

OK Now we're getting somewhere! 

the DAQmx timing.vi help

Use Waveform

Uses the dt component of the waveform input to determine the Sample Clock rate. dt is the time in seconds between samples. If sample mode is Finite Samples, NI-DAQmx generates the number of samples in the waveform. This VI does not actually generate any samples. You must wire the same waveform to the DAQmx Write VI to generate the samples.

With Crash F this requirement is met. With Crash T it is not.

You really should be using the error terminals as well.

[Joel_L]

JeffBohrer wrote:

OK Now we're getting somewhere! 

the DAQmx timing.vi help

Use Waveform

Uses the dt component of the waveform input to determine the Sample Clock rate. dt is the time in seconds between samples. If sample mode is Finite Samples, NI-DAQmx generates the number of samples in the waveform. This VI does not actually generate any samples. You must wire the same waveform to the DAQmx Write VI to generate the samples.

With Crash F this requirement is met. With Crash T it is not.

You really should be using the error terminals as well.

I use the error terminals in the real app. I'm leaving them off this VI so I can see immediately if any errors show up (they don't). Task lines keep execution happening in order.

Actually though, I'm using the crash signal (length=2) to drive the Timing, not the non-crash signal. When Crash=T, the signals match. When Crash=F, they don't (though dt is the same so I think it shouldn't matter). And I guess I'd expect an error if they didn't match, but no error occurs.