TotalSampPerChanGenerated issue

[Ron Norton]

Hi,

I am using a PCI-6281 to do continuous, non-regenerating, analog waveform generation. Since I need to smoothly ramp down the waveform when the user presses a button, I monitor how many samples are written with DAQmx Write before it is OK to stop the generation and then I monitor the TotalSampPerChanGenerated DAQmx Write property in a loop until all the samples have been output before stopping and clearing the task.

I had been trying to accomplish the final part of this with the attached SubVI, but was running into a problem with my main VI occasionally (roughly 1% of the time) hanging. The one time I was able to identify the cause of the problem, it was that TotalSampPerChanGenerated was never exactly equal to the Total samples written and it kept increasing until it was one more than Total samples written. I had assumed that the updates would stop when there were no more new samples. I have currently replaced the Equal? comparison with a Greater Or Equal? comparison, but I would like to know if it is possible that the final value of TotalSampPerChanGenerated could wind up being less than Total samples written (i.e. was it some kind of counting error), and if possible, what would be the value of any extra sample generated. Also, if I had been monitoring the error output of the DAQmx Write property node, would I have detected an error when the board ran out of data to generate?

Thank you very much for any help or insight into this issue,

Ron Norton

Faculty Research Assistant

Department of Physics

University of Maryland

College Park, MD

[Jason_D]

Ron,

You are polling with this property node in a while loop so it is likely that the value was merely missed and the loop continued polling going off into infinity because the "limit" had already been passed.  The recommended way to do this would be to use an event structure that would only register events when a value change on that property happened.  This would queue up changes so that all would be serviced and less processor time would be used as it would only check when a change was made rather than simply as fast as it can.

I doubt you would have gotten an error as from the programs perspective nothing bad has happened it simply didn't poll on the specific value you were testing.  It is a good idea in general to handle your errors though.

Is the program working fine now with the greater than change?  If so and you are happy with it you wouldn't have to make the event structure change I mentioned.

[Ron Norton]

Jason,

Thank you for your reply. I think I understand your suggestion, but I'm not sure it would make much difference - it would still depend on how and when the DAQmx driver changes the value of the DAQmx Write property TotalSampPerChanGenerated, wouldn't it? Also, although my polling loop continued to iterate indefinitely, the value of TotalSampPerChanGenerated stopped increasing at 1 sample more than the total number of samples I had written with the DAQmx Write function. I would like to understand, if possible, what caused it to stop updating (I assume that if I hadn't used Do Not Allow Regeneration for the regeneration mode, then the board would have continued cycling through the data in it's onboard buffer and kept increasing the value of TotalSampPerChanGenerated), and why did it stop at 1 sample more than I wrote, and what analog voltage did the board generate for the extra sample?

So far, the program has not hung since I made the change, but it didn't happen that frequently to begin with and we haven't really used it that much since I made the change. My remaning concerns are first, that if the TotalSampPerChanGenerated count never even reaches the total number of samples I write (which seems unlikely), the VI will still hang, and second, what voltage actually gets generated for the update(s) after the last ones I wrote to the buffer?

I guess it seems to me like I just need to better understand the interaction between the DAQmx driver and the board. Is there any documentation that you know of that might help?

Thanks again,

Ron

[Ron Norton]

I had thought it was unlikely, but this morning my analog output VI hung because the TotalSampPerChanGenerated property never reached the total number of samples written. Total samples written was 150000, while TotalSampPerChanGenerated stopped increasing at 149999.

Yesterday, while browsing the LabVIEW help for more insight, I came across the DAQmx Write property Next Write Is Last. This sounds like it might be relevant to what I'm trying to accomplish, but I would think I would still have to wait for all the samples from the final write to be generated, before stopping the task. And, I didn't get an underflow error in this case anyway. It seems that the problem is either that the board isn't generating the correct number of samples, or the driver is not reporting the correct number of samples generated.

Do I just need to accept that the final value of TotalSampPerChanGenerated might be off by one in either direction (or could it be more than one off?), or is there something else going on that I'm still missing? Does anyone know how TotalSampPerChanGenerated gets updated?

Thanks for your help.

Ron