DAQmx timing issue

[cm_opi]

I'm working on a data acquisition system for my company and we're running into a problem with the DAQmx code.  The program follows the following general algorithm:

1. Set digital outputs to control hardware

2. Read 32 analog input channels using Traditional DAQ

3. Read 32 thermocouple channels using DAQmx (we're using this because the newer hardware won't support Trad. DAQ)

4. Process data, look for user input, and other program functions.

5. Loop back to 1 unless the user has commanded the program to exit.

I'm trying to get it to run as quickly as possible so we can acquire data at a reasonable rate, and my goal is to get the loop to take less than 10ms.  The problem I'm encountering is that I'm getting error -200279 from the thermocouple DAQmx code.  From what I understand, this means I'm reading from the buffer slower than data is being put into the buffer, and that the data I'm trying to read is getting overwritten.  This isn't an issue with the analog DAQ, since we've set up the traditional DAQ to not buffer at all.  When the loop gets to setp 2 it just pulls in whatever's on the analog channels at the moment.  The thermocouples will read, but won't do so at a consistent rate.  Every .25 seconds or so the time to complete a program loop jumps from ~8ms to ~80ms, and I'm almost certian that the issue is with the DAQmx code.

My question: what is the simplest way to get DAQmx to behave like a traditional DAQ single scan?  I don't want/need a buffered acquisition, and I'm only using DAQmx because I can't get traditional DAQ to work with my new thermocouple hardware.  What I'd like is to set up DAQmx so it will just read the current thermcouple data (whatever that may be) whenever the program gets to step 3.  If I can do that without lagging the whole program loop past 10ms per loop, it'll be great.

Any help on this is appreciated.

[CharlesD]

It sounds to me like you are specifying some kind of timing scheme with DAQmx (Using the DAQmx Timing .vi).  If you delete this from your program you will default to 1 sampl on-damand.  With this data will be returned anytime the DAQmx Read.vi functions is called.  Please see the following image for more information on how you can use event structures and on-demand sampling to acquire a sample from single or multiple channels when user input is triggered.

 

Message Edited by CharlesD on 05-15-2009 11:32 AM

[Broken_Arrow]

Too many things could cause this - without seeing your code it's hard to say.

Are you using the Sample Clock VI?

How many samples are you taking vs. how fast? This will determine if your program can keep up.

As a diagnostic, there are property nodes (see attached pic) you can use to monitor the number of samples taken and the number of available samples. As your available samples start to fill up faster than you are reading them, you'll get the error. You can use these nodes to troubleshoot where your code is slowing down.

[xander c]

I work with the original poster and use the daq system his Labview code is running on.  He's out on vacation this week so I'm working on the system when I can.

I tried CharlesD suggestion of eliminating the DAQmx Timing vi and the result was an increase in loop execution time from every 5-7 ms to >150 ms.  I've seen this behavior on other systems I've built/used.  It seems that having to make the call to the board to read a sample(s) every time through the loop requires extra time for the board to acknowledge the request, process it, take the data, and report it back.  I had gotten around this in the past by having the thermcouple board continuously streaming data into the buffer so that the only action that occurs during the loop is a request/retrieval of data, eliminating whatever initiation processing time the board would otherwise have.  Granted those systems were coded with traditional daq instead of daqmx, but I've had success in the past with loop execution speeds down to 500-1000 Hz.  Unfortunately our SCXI usb board does not seem to work with traditional daq.

So I added the DAQmx Timing vi back into the code and got the performance back down to what was listed above.....loop exection every 5-7 ms with the occasional hiccup to 60-120 ms execution time.  The timing vi is setup as Sample Clock with Continuous daq.  The code was initially written with the DAQmx Read vi in a N Channel 1 Sample mode.  I thought that maybe we weren't pulling data out fast enough and the buffer was filling up and causing a hangup when it ran out of room, so I switched the Read vi to a N Channel M Sample mode, using a custom vi to average the output NxM array into a Nx1 array.  I tried this with many different combinations of Sampling Rate and Samples per Channel feeding the Timing vi.  This did not seem to make a difference except that over 1200 samples/channel/sec I would get an error saying it was too high of a rate for adequate settling time of the daq hardware.  Dropping the sample rate below 150 (corresponding to the 7ms loop time) caused instances of no data being returned (presumably the loop was going faster than the daq board was taking data).  Changing the samples/channel (which should change the buffer size in a continuous mode?) had no effect.  The one parameter that did alter performance was changing the #of Samples to Read on the Read vi.  Obviously, the higher the number, the more time taken for averaging and the longer the loop execution.  However, I tried feeding this parameter with "-1" to make it read all available samples in the buffer, and I ceased to get any data, except for the occasional blip (every couple of seconds maybe).

I also added a property node.  The Total Samples/Channel Acquired rose continuously in all cases above, although it went fastest with the "-1" setting on the Read vi.  I also took the difference between the Total Samples/Channel Acquired and the Current Read Position and charted it in time.  What I found was that the number would spike to around 120 and then decay linearly until it reached 0, at which point it would spike back up to around 120.  The spikes seemed to correspond to the times when the loop would stall out to the 60-120 ms execution time.

Anyways, I am going to try and grab a pic of the thermocouple daq code when at the test site today and load up here so hopefully what I typed above makes more sense.  Please let me know what other info you might need and I'll try to get it.

Thanks,

Alex

[Mcdan]

Alex,

The behavior you describe at the bottom of your post with the available samples per channel spiking to 120, then decaying to 0 rings a bell.  It sounds to me like the data is being held in the FIFO on your device until some threshold is met.  At this point, a large collection of samples is sent from the device to the buffer.  Using the FIFO in this way is often done to efficiently use the available bandwidth on the bus (ie... more efficient to send one large packet of data than a large collection of small ones).  You didn't specify which hardware you were using, but you might be able to change this behavior by setting the AI.DataXferReqCond property (Channel Property Node->Analog Input->General Properties->Advanced->Data Transfer and Memory).  For many devices this property will default to 'Onboard Memory More than Half Full'.  This could be changed to 'Onboard Memory Not Empty.'  If you device supports this, this could prevent the spiking of available samples that you are observing.

If that doesn't help with your issue, a code snippet and information about the hardware you are using would be helpful.

Dan

[xander c]

Dan,

Thanks for the tip.  I tried what you suggested with no apparent change in behavior.  I've attached my thermocouple daq vi for review.  This isn't the total daq code, but just the thermocouple daq portion pulled out in a separate vi to experiment with.  Hopefully I'm just missing something really obvious.

As for my hardware, here is the chain from the thermocouples to the daq computer:

Thermocouple

TC-2095 (rack mount connector block)

SCXI-1102C mounted in #3 slot of SCXI-1001

SCXI-1600 mounted in  in #1 slot of SCXI-1001

DAQ Computer

Thanks for all the help.

Alex

[cm_opi]

Now that I'm back in the office I can work on this problem again.  Changing the data acquisition from the continuous sampling to acquire 1 sample was something I tried during my initial implementation, and I encountered the same problem.  If I took only one sample, loop execution time shot up significantly.  If I went to the continuous mode the execution time improved, but I ran into the buffer errors.

I think it might be helpful to go back to one of my earlier questions: how do I get DAQmx to behave like a traditional DAQ single scan?  The Trad DAQ works perfectly for the analog channels we're reading, but it wasn't an option for our new thermocouple hardware.  I don't know enough about the inner workings of either programming scheme, so is there some simple answer as to why the same operation (reading all the channels) takes so much longer with DAQmx Read than it does with the Trad DAQ Single Scan?

[Jason_D]

cm_opi,

Were you able to add the Event Structure like David suggested?  If not could be try that?

Additionally why do you have the create channel in a for loop?  Generally I would advise not looping any of the create channel/task VIs. 

[CharlesD]

cm_opi,

I think what Jason_D meant is that it is important to NOT Create the channels and configure those channels over and  over again if it is not needed.  Creating Channels in a for Loop is acceptable in this case however it is important to do this only once for the task.  Therefore is this VI part of a larger VI (is this a subvi that gets called over and over again?) From your initial post it sounds like you have 5 major steps and this SubVI constitutes step 3.  As such, is it this entire SubVI iteration that is taking too long?? or is it the while loop inside of the SubVI that is taking too long. 

My worry is that you are stating that this particular subVI is taking to long to run through and this could very well be the case because you are creating all of your channels, configuring those channels, Reading those channels then finally clearing the task Everytime this subvi is called.  It would be better if your main program were to do the following:

1. Set digital lines to configure hardware

2. Create and configure T-DAQ TASK (including timing and starting task)

3. Create and configure DAQmx Task (including timing and starting task)

4. Read data

    a. Read T-DAQ channel data

    b. Read DAQmx Channel Data

    c. Maniupulate data if needed (Could be in parallel to completing the read using Producer Consumer Architecture

    d. Loop Back to 4a and repeat iteratively until necessary. 

5. Exit read stage

6. Clear T-DAQ Task

7. Clear DAQmx Task

8. Exit Program 

I hope this helps please let us know if this is NOT what is going on in yourmain program and if there is something that we are missing. Thank you

[cm_opi]

Jason_D, we are working with the basic LabVIEW package, so the event structure is not an available feature.  The reason the channels are configured in a for loop is because when I started this implementation I didn't have any experience with DAQmx.  I had used the DAQ Assistant express VI before, so I set one up to do what I wanted, and then converted it to a sub-VI.  I took the code you see know from the result of that, but I'd be interested to know if there's a better way.  I have set up the program so that the channels are only created once, and then we are trying to read from those channels from within a while loop.  It's at the reading stage where the slowdown occurs.

CharlesD, as far as I know we're not duplicating the creation/configuration of channels and clearing the task each time through the loop.  However, my experience with DAQmx is limited.  Is there some part of the read process as we have coded now that clears the task without us explicitly telling it to?