task is done does not work for multiple finite digital output task calls

[sandrawells]

I need to create a program that cycles two digital lines a variable number of times for a finite duration each time. 

Several years ago, I modified the Multi-Function-Synch AI AO.vi and called it to perform a single finite digital output task.  I have modified the program to call the digital lines six times each individually and eight times together based on the number of cycles completed.

This new program works on a desktop computer (Dell Precision 390 with an Intel Pentium 4 at 3 GHz, 1 GB ram, and a PCI-6251 using LabVIEW 7.1 and NI-DAQmx 8.0.1f0).  The program does not work on the laptop that will be used during the actual testing (Dell Latitude D820 with an Intel Centrino Duo T5500@1.66 GHz, 1 GB ram, and a USB-6251 using LabVIEW 7.1 and NI-DAQmx 8.3.0f0).

On the laptop, the task is done stops the Multi-Function-Synch AI DO for Vibe.vi on the first call but not on the remaining calls. 

Because this testing is being done on production test computers, I can not upgrade the version NI-DAQmx. 

I was able to get my program to work by switching to a finite analog input task.

Any ideas to explain why the “task is done” does not work for the finite digital task but the “task is done” does work for the finite analog on the USB-6251?  I may need to perform similar testing in the future on short notice and do not want to bang my head on the wall again when using the laptop and the USB-6251 when out of the office.

I will attach an test program that displays the acquired data and the cycle count (Vib Test Acquisition Module.vi) and the Multi-Function-Synch AI DO for Vibe.vi.

[Erik-S]

An initial step you can take is to flush the buffer after the clear task VI for the Digital output. This will help to ensure that the buffer is entirely cleared since you are calling Vibe.vi multiple times in your top level VI. I would also advise that you change both sample clocks to finite since the software timing is different. Please let me know if you are still having problems.

Erik S

[sandrawells]

How do you suggest I clear the buffer with LabVIEW 7.1?  I do not see any options for clearing DAQmx output buffers.  I see options for file buffers and VISA buffers.

I wanted to have an infinite analog input task in order to read the last set of captured data after the digital output task finished because my unit under test is allowed to operate 250 ms after the power is removed by terminating the digital output.

Thanks,

Sandra

[Erik-S]

Can you explain a little bit more about what you see when your program doesn't work correctly? (i.e. error codes). I would like to narrow this down a bit more, so could you explain how exactly you know your program is failing. I'm not saying that I don't believe it is failing, I would just like some more details about the failure.

[sandrawells]

Erik,

When calling the sub vi multiple times with a continuous analog input task and a finite digital output task, there are no error messages but the digital output task never ends using the USB-6251.  I need to click the stop button to end the task on the portable setup.  When I use the desktop computer, the output task end and the sub vi closes after every cycle automatically.

I wanted to use a finite digital output task in order to allow adjustments to the cycle timing while ensuring that all analog input samples in the buffer were read. 

In the test where I found this issue, the customer has asked for 200 ms to 500 ms on times with 1.7 second to 4.7 second off times.  When the unit under test is turned on via the digital output, there is a 150 ms delay before the output is seen (solenoid valve opening) and when the unit under test is turned off via the digital output, there is a 250 ms delay before the output is seen (solenoid valve closing).  In addition, the cycle was repeated between 20 and 200 times.  Since the timing was not finalized until the day before the vibration test at the outside lab, I was planning to use a simple tweak to the digital output task and call it repeatedly.

When I found the issue using the laptop and the USB-6251, I did switch to finite tasks for both the analog input and digital output.  This means I need to verify the synchronize the sample timing and test a unit to ensure all cycles are completed and no important data is missed.  For certain projects, I work on a short deadline and do not have access to a test article and associated test hardware.  I had just over a week to get this particular program to work.  Yesterday, I got a project that needed to be finished in 4 hours so I want to avoid problems that occur when switching between different data acquisition cards and computers.

Thanks,

Sandra

[Erik-S]

Hi Sandra,

I would suggest using a state machine instead of do the processing inside of an event structure. Since you have controls inside of the event structure, it is easy for them to get reset by other events, which will lead to undesirable results. For example, if your program times out, it will send a false to the stop condition. If the stop button was hit while the program is timing out, the true sent by the stop button can get overwritten. This could make the program run indefinitely. Here are some examples of state machines that may be useful:

https://decibel.ni.com/content/docs/DOC-4594

https://decibel.ni.com/content/docs/DOC-10176

I would also avoid nested while loops because they add an incredible amount of complexity. The sequence structure around the program is unnecessary, but it should not affect anything. I cannot find exactly what is going wrong, but there are many factors which may lead to the undesired operation. Your best bet would be to clean up some of the code to make sure there are not inconsistencies and unnecessary variability. I would also advise parsing out the program into more subVIs that can be thouroughly tested. Problems can then be isolated to one section instead of the entire program. 

-Erik S