arbitrary waveform generation from large text file

[physicsundergrad]

Hello,

I'm trying to use a PXI 6733 card hooked up to a BNC 2110 in a PXI 1031-DC chassis to output arbitrary waveforms at a sample rate of 100kS/s.  The types of waveforms I want to generate are generally going to be sine waves of frequencies less than 10 kHz, but they need to be very high quality signals, hence the high sample rate.  Eventually, we would like to go up to as high as 200 kS/s, but for right now we just want to get it to work at the lower rate. 

Someone in the department has already created for me large text files > 1GB  with (9) columns of numbers representing the output voltages for the channels(there will be 6 channels outputting sine waves, 3 other channels with a periodic DC voltage.   The reason for the large file is that we want a continuous signal for around 30 minutes to allow for equipment testing and configuration while the signals are being generated. 

I'm supposed to use this file to generate the output voltages on the 6733 card, but I keep getting numerous errors and I've been unable to get something that works. The code, as written, currently generates an error code 200290 immediately after the buffered data is output from the card.  Nothing ever seems to get enqued or dequed, and although I've read the Labview help on buffers, I'm still very confused about their operation so I'm not even sure if the buffer is working properly.  I was hoping some of you could look at my code, and give me some suggestions(or sample code too!) for the best way to achieve this goal.

Thanks a lot,

Chris(new Labview user)

[physicsundergrad]

Oops! I forgot to post my code!  Here it is:

[jareds]

Hi Chris,

The 1122 error that you seem to be getting based on some of  your logic suggests that the queue is being released before you finish using it.  There are three wires coming from the Obtain Queue function.  Where does the top one go?  Since it's not broken, it must be wired to something.  The only thing I can see would be the while loop next to your producer loop.  If that is the case, then you might be releasing the queue after the first read from the consumer.

[physicsundergrad]

Hello Jared,

First of all, thank you so much for you interest in my problem.

The wire that you are asking about goes from the enque element vi and to the rightmost while loop that checks for the queue to be empty.  The wire travels behind the main producer loop...sorry about that. In addition to the 1122 error(which I think I've successfully ignored, although I'm not sure if I should), I get an error 200290: The generation has stopped to prevent the regeneration of old samples...

I redrew some wires to clean up the vi and reattached a new screenshot... 

Chris K.

[jareds]

Hi Chris,

The 1122 error is actually very important and should not be ignored (nor should almost any error).  You shouldn't wire directly wire from the obtain queue to the rightmost while loop, since this could release the queue before you're finished using it.  You should try wiring the queue reference from the while loop reading the file to the rightmost loop.

[physicsundergrad]

Hi Jared,

Thanks a lot for informing me about the 1122 error, I did not realize its importance.  I've fixed the wires you mentioned and it has disappeared.  I'm still getting the error 200290, for rates above 80kS/sec.  Do you have any suggestions as to how I could improve this? 

Thanks,

Chris K.

[charris]

Chris:

For context, I've pasted in the "explain error" output from LabVIEW to refer to while we work on this. More after the code...

Error -200290 occurred at an unidentified location

Possible reason(s):

The generation has stopped to prevent the regeneration of old samples. Your application was unable to write samples to the background buffer fast enough to prevent old samples from being regenerated.

To avoid this error, you can do any of the following:
1. Increase the size of the background buffer by configuring the buffer.
2. Increase the number of samples you write each time you invoke a write operation.
3. Write samples more often.
4. Reduce the sample rate.
5. Change the data transfer mechanism from interrupts to DMA if your device supports DMA.
6. Reduce the number of applications your computer is executing concurrently. 

In addition, if you do not need to write every sample that is generated, you can configure the regeneration mode to allow regeneration, and then use the Position and Offset attributes to write the desired samples.

By default, the analog output on the device does what is called regeneration. Basically, if we're outputting a repeating waveform, we can simply fill the buffer once and the DAQ device will reuse the samples, reducing load on the system. What appears to be happening is that the VI can't read samples out from the file fast enough to keep up with the DAQ card. The DAQ card is set to NOT allow regeneration, so once it empties the buffer, it stops the task since there aren't any new samples available yet.

If we go through the options, we have a few things we can try:

1. Increase background buffer size.

I don't think this is the best option. Our issue is with filling the buffer, and this requires more advanced configuration.

2. Increase the number of samples written.

This may be a better option. If we increase how many samples we commit to the buffer, we can increase the minimum time between writes in the consumer loop.

3. Write samples more often.

This probably isn't as feasible. If anything, you should probably have a short "Wait" function in the consumer loop where the DAQmx write is occurring, just to regulate loop timing and give the CPU some breathing space.

4. Reduce the sample rate.

Definitely not a feasible option for your application, so we'll just skip that one.

5. Use DMA instead of interrupts.

I'm 99.99999999% sure you're already using DMA, so we'll skip this one also.

6. Reduce the number of concurrent apps on the PC.

This is to make sure that the CPU time required to maintain good loop rates isn't being taken by, say, an antivirus scanner or something. Generally, if you don't have anything major running other than LabVIEW, you should be fine.

I think our best bet is to increase the "Samples to Write" quantity (to increase the minimum loop period), and possibly to delay the DAQmx Start Task and consumer loop until the producer loop has had a chance to build the queue up a little. That should reduce the chance that the DAQmx task will empty the system buffer and ensure that we can prime the queue with a large quantity of samples. The consumer loop will wait for elements to become available in the queue, so I have a feeling that the file read may be what is slowing the program down. Once the queue empties, we'll see the DAQmx error surface again. The only real solution is to load the file to memory farther ahead of time.

Hope that helps!