08-17-2012 05:35 PM - edited 08-17-2012 05:41 PM
I found a reliable way to crash LabVIEW with DAQmx:
I tried it on 2 systems:
1. Windows 7 32-bit, LV 2011 Debug Deployment, DAQmx 9.3.5: Indefinite hang (I waited about a minute or so) on the 2nd DAQmx Stop on the 2nd loop iteration,
2. Windows 7, 64-bit, LV 2011 FDS, DAQmx 9.5.1: Crash shown below:
I tried using both a PCIe X Series and a PCI M Series (using a counter output as the sample clock on the M Series) and got the same results.
I suppose the first question that comes to mind is why in the world would I want to be doing this with DAQmx? The snippet above is of course a simplification. In my application I am running a re-triggerable digital output task with an X Series and a free-running trigger. The user might want to stop and re-configure the output buffer (size could change as well) while the task is running, but I absolutely cannot leave the line high for a longer duration than what would have been clocked out previously (it is OK to miss triggers during reconfiguration though). My procedure for handling this is: tri-state the line, then stop the retriggerable task, then write an on-demand 0 to the output line (which might still be high from before), then un-tri-state the line, then start the retriggerable task with its new parameters (I cannot risk un-tri-stating after the task is restarted for fear of outputting only a partial waveform, but this isn't relevant to the bug).
The problem seems to be in transitioning between a finite and an on-demand output task without clearing and re-creating the task. The hang occurs on the 2nd loop iteraton--the first time it seems to work OK. If the loop includes the create and clear task then it seems to run indefinitely.
When we rework our hardware I plan on using a buffered counter output (which returns to the idle state when it is stopped) instead of the digital output but right now I'm stuck with a digital output due to having to support existing systems which are hard-wired.
Can somebody validate that this is reproducible at NI's end and let me know the CAR ID (I'm assuming that this isn't expected behavior 🙂 ). My workaround is to clear and re-create the task or perhaps make a 2nd task for the static digital output (if there are other suggestions I'd happily take them).
Best Regards,
08-20-2012 12:51 PM - edited 08-20-2012 12:58 PM
Hello John
I tried it with the M series using a counter´s output as the external clock and using LV 2012 and DAQmx 9.6 it did not crash, with the X series I received error 201062 but it did not crash either. I am missing something? And as always it is pleasure working with you John
Warm regards
Martin
NI Costa Rica
08-21-2012 02:10 PM
Error -201062 probably means you are running it on a line other than port 0.
Thanks for trying to reproduce, strange that it doesn't crash for you. Do you have an older DAQmx system handy to test on by any chance?
Best Regards,