DAQmx-based VI functions differently in LabVIEW than it does in TestStand

[Nessalc]

I have a particular VI that generates a square-wave signal to control the motion of a motor. When I run this VI in LabVIEW, after a prescribed time, it halts (a timer is also included in the VI). When this same VI is run as an Action (or Limit Test, or Pass/Fail Test) in TestStand, the PWM signal continues to be generated indefinitely after the VI has completed and the results (if required) have been returned to TestStand. If I follow this VI with another VI that generates a square wave with a duty cycle of 0%, the motor stops, as expected. However, I cannot run the sequence in TestStand again without resetting the cDAQ chassis--and even then, only every other time. LabVIEW reports an Error -200474 (expired timeout) and TestStand reports an Error -200088 (invalid or non-existent task) on other runs.

My questions are these: Why? and What can I do to fix it?

[EEsRULEtheWORLD]

Hey Nessalc,

Did you create your task in LabVIEW, or are you calling a global channel or task that was configured in MAX?  What specific device are you using?

If you could post your LabVIEW code to this forum, it would help me to better uncover the issue that you're experiencing.

[Nessalc]

I created the task in LabVIEW, and the device being used is the NI 9472 in a cDAQ 9172 chassis. I have attached some code which demonstrates what I believe to be the primary issue here. The interface is far from pretty, but it does what's needed.

In LabVIEW, test1.vi will generate a 1000Hz, 50% duty-cycle square wave for a specified period of time. When this is concluded, an oscilloscope will show no signal output by the NI 9472 (or at least the "Low" state).

In TestStand, test.seq has test1.vi as an "Action" step. When this is concluded, an oscilloscope will show the same signal being output by the NI 9472. This continues until the step is modified (e.g. changing a parameter--even un-checking the "Default", or clicking "Edit vi"), TestStand is closed, or the device is reset.

A second "Action" step is added for an additional demonstration. Set this to "Normal" Run Mode, and "Enable" the disabled block in PWM.vi.

If, at any point, the initial task is stopped and/or cleared (see that disabled block in PWM.vi, created to run if duty cycle is set less than 0.0001, which occurs in this second action step), I run into the -200088 error (using TestStand). At this point, it must realize that the task has been stopped and/or cleared, because from this point on, every second iteration through the test sequence will succeed while the others throw up the error dialog.

Is this sufficient to explain the issue?

[EEsRULEtheWORLD · Accepted solution]

Hey Nessalc,

After looking at your program, I think I understand why you're not seeing a signal on your oscilloscope.  The test1 VI opens a reference to your Counter Output task, configures timing and then starts the generation over and over and over again, without ever giving the task time to generate any pulse train.  Typically, you would do this with a DAQmx Is Task Done a Wait Until Done subVI (depending on if this is a continuous or finite pulse train).

If you're attempting to execute a pulse train for a specified amount of time, refer to the example called Gen Dig Pulse Train-Finite.vi, which can be located in the NI Example Finder (Hardware Input and Output»DAQmx»Generating Digital Pulses).  Based off of the value of the number of pulses and frequency controls, you can configure your device to output a pulse train for a certain amount of time.

I also noticed that you are not clearing your task at the end of the program.  It is necessary to release your resource before attempting to create another task for that resource.

The following image is a screenshot of the block diagram from the example program (Gen Dig Pulse Train-Finite.vi).  I labeled the key subVIs that I found missing in your application.

Hopefully, this helps.  Let me know if you have any other questions related to this issue.

[Nessalc]

Quote:

After looking at your program, I think I understand why you're not seeing a signal on your oscilloscope. The test1 VI opens a reference to your Counter Output task, configures timing and then starts the generation over and over and over again, without ever giving the task time to generate any pulse train. Typically, you would do this with a DAQmx Is Task Done a Wait Until Done subVI (depending on if this is a continuous or finite pulse train).

Though I was seeing a signal on the oscilloscope, and the counter output was not re-starting the generation over and over again (the input to the case structure was, or should have been, equivalent to a "first call" only), and I did have the clear task involved, nothing was in the right spot. The examples you pointed me to got me pointed in the right direction, and the most important thing was, and I don't know why I missed it, the "Wait Until Done" VI.