Add functionality to stop at end of wave when stopping continuous generation

[daveu]

When running in 'finite mode'. Obviously, when everything stops, the last value written (to AO Channel) is the last value in the array of data points for the waveform. However, if i am running in 'continuous mode', and give a stop command, the last value written (to AO channel) is always some erroneous value based upon when stop was initiated. It would be nice if there was some added functionality that allowed setting a variable (say....Auto Stop for continuous mode), so that the programmer could control what point in the array values to the AO channel stopped being written.

It seems to me that this would be an extremely useful control.

Here is a thread of someone explaining a similar problem.

Thanks!

David

[Hal_L]

Hi Dave,

Thank you for pointing that out. I recommend that you create a product suggestion with your idea. The product suggestions go directly to R&D so they can incorporate your feedback into future releases.

Regards,
Hal L.

[daveu]

I was wondering if anyone had a solution to the above issue I mentioned. I cannot upgrade our application to LabVIEW 8 (from LabVIEW 6.i)until this issue is resolved, or a solution is available. I submitted a "product suggestion" to R&D, and have been paying attention to the recent upgrades (8.1 and 8.2), but haven't noticed anything in regards to this issue. Either I'm missing something, or R&D for LabVIEW thinks this isn't that big of a deal.

This has quickly become a major issue. We are now attempting to use the NI-cDAQ-9172 chassis. BUT, we are unable to communicate with it because it requires DAQmx. Well, since i'm unable to upgrade our software (because of the signal generation issue), I'm ultimately unable to use the 9172 chassis.

Help.

[Kevin_Price]

I'm not aware of any built-in feature to handle this, but the thread you linked to in your original post seems to hold some promise for a workaround.  I'm kinda assuming that you're continuously re-generating a single constant output buffer.  A modification of the idea may still work if you're continuously calculating and feeding new values to the output buffer, but I have less knowledge of the available properties and the relationship between PC RAM and the onboard DAQ FIFO buffer.

   Outline of idea: When defining the output values and writing them to the DAQ output task, maintain a copy of the buffer within the LabVIEW app -- perhaps a functional global or a queue.  After you stop the output, query for TotalSamplesGenerated.  Divide that by the output buffer size using 'Quotient & Remainder' and use the Remainder to tell you what your last output value must have been.  Now you can figure out how to get from the point A where you actually stopped to the point B where you wanted to stop. 

   I'm not sure what the minimum steps are to make sure that new data you write with DAQmx Write becomes the first data actually clocked out the DAC, but the maximum would be to clear the old task and reconfigure a new one for the finite # of samples you need.  I kinda suspect that the call to DAQmx Timing where you change from continuous to finite sampling would also do it, and would probably execute more quickly.

-Kevin P.

[daveu]

Kevin,

I understand your solution, and where it probably would work, I have some concerns.

What is the size of TotalSamplesGenerated? If it's a 16-bit integer, it can only give me a true value up to 65536. Any more than that, and I'm assuming it rolls over (back to zero). And if that's the case, I cannot use this method, as I cannot always use the quotient/remainder method to determine what I need to generate to get back to my starting position. Since I am potentially running upwards of 50 Hz, with large data arrays (1000 samples per period), running for even 10 seconds gives me 500,000 samples.

However if it's 32-bit, I don't think we'll ever run fast enough AND long enough to generate more than 4,294,967,296 samples, making your method a solution.

It seems the appropriate solution would be to make the fix in the LabVIEW software, such that I could tell the DAQ device that when I command a stop, it knows to continue generating AO until the end of the on-board buffer array is reached, NOT the moment it receives the stop command.

I look forward to your reply!

thanks, dave

[Kevin_Price]

---

What is the size of TotalSamplesGenerated?

---

In LV 7.1, it's a 32-bit integer.  I'm pretty sure it's an unsigned int too.  I believe the current version of LabVIEW (8.20) suppports 64-bit ints, but suspect that DAQ buffer properties like 'TotalSamplesGenerated' are still 32-bit.  But like you said, that should be enough...

I agree that there ought to be a better built-in means for controlling the end-state of a DAQ output buffer during continuous generation.  There are different needs, but among the possibilities should be "stop generating after reaching last element in output buffer", and "output specific value after stopping."  It'd also be helpful if there was a way to query an output task, even when stopped, to determine the values presently at the output terminal(s).  Then a user could make a controlled transition from that end state to the desired end state. 

-Kevin P.

[daveu]

Excellent, I will begin implementing that solution immediately!!!!

Hopefully NI R&D will recognize a change needs to be made. I've submitted this problem to them at least three times, with no response, or solution.

Thanks for the help!!!

dave