cDaq devices losing/dropping/not reporting samples

[zeppelinboy]

Hello,

I have a

CDaq-9174

With the following modules installed.

NI9477
NI9213
NI9215

Part of my application involves acquiring samples from the 9213 and 9215. The code that I use to perform this looks like the below image.

For some reason, the DAQmxREAD vi's do not always (randomly) return a value every iteration of the loop. I am attaching a data file that shows the missing data, I am also attaching the VI which displays this behavior.

The VI is set to run the loop every 2 seconds and to sample data at a rate of 5 samples/sec, but this behavior occurs at any combination of sampling rate and loop execution time.

Any thoughts on why this is occurring? Is there something wrong with my code, or is this a hardware issue? Am I asking too much from the cDaq devices?

Thanks!

Justin

[Jim_S]

Hello,

When looking over your code, I would make a few changes to your code make it work better overall. First, I would not DAQmx Flatten Channel String to combine multiple channels. I have provide a KnowledgeBase that shows you how to choose more than one channel for one DAQmx channel constant.

After this I would pass the errors from each of the DAQmx VI so that you can monitors errors throughout the program. This is extremely good to do with a string of DAQmx code because if the previous step didn't work, the following steps won't work either. Along with this, you should always close and clear your tasks before you end your program. If this isn't done, the open references to your card can cause problems with leaving the device in an unknown state.

As for the problem you are experiencing, I would try a few things. First, I would set the Number of samples per channel to a set amount. This will force the DAQmx read to wait until X number samples have been acquired from the card. Next, I would monitor how much data is sent to the two for loops. If you are getting all the data you expect, then we know the DAQmx read is working correctly. From here, I would follow the path of data to the Write to Spreadsheet file to make sure the data is being create and sent to it correctly.

[Seth_B.]

Hello Justin,

NI-DAQmx should never drop samples without reporting an error.  However, there is no error handling in your VI at all.  Additionally, you should use the DAQmx Start Task and DAQmx Clear Task VIs as well.  I strongly recommend looking at the LabVIEW Example Finder (Help » Find Examples) to find good example code to base your program off of.

When you open the Example Finder, navigate to Hardware Input and Output » DAQmx » Analog Measurements » Voltage and open ContAct&Graph Voltage - Int Clk.vi.  This VI shows the best and simplest way to set up a continuous acquisition using NI-DAQmx.  You can copy the code from this VI into your program and modify it to fit your application.

[zeppelinboy]

Hi Jim and Seth,

Thank you for replying to my problem and for your suggestions.

I must appologize for my hastily written example code. You are of course correct in that I should have proper error handling and start and clear tasks appropriately. The aquisition of these data signals is but one small part of a much larger program that would be pointless in posting here. I assure you that my real program contains proper error handling and task clearing. My example code is an attempt to replicate the problem that I am having while keeping the code as simple as possible. I have re-written the example in hopes of addressing all of your concerns.

I used the flatten channel string to combine the channels because the user can select multiple non consecutive channels. I do not specify a specific # of samples to be read from the daq modules because my main program loop execution rate can vary. I want the daq to continuously acquire samples while the loop is executing, and then deliver them when I ask. The loop execution is not particuarly fast, and never drops below 1.25 s, so the daq modules ought to be able to acquire at least 1 sample during this period.

Hopefully this makes the decisions that I have made for my application a little more clear.

I have run the revised code with proper error handling, and unfortunately still have the same problem of missing data.

Attached you will find a copy of my code, a txt file of the data, and an xls file of the data. The xls file has been formatted to include column headers and the missing data has been highlighted in yellow. As you will see in my code, the data file now records any errors if they occur and the error code. As you will see in the data and xls files, no errors are reported, even though there are missing samples. Specifically, data is missing from module 3 (NI9215) at iterations 15, 49, and 51 and data is missing from module 2 (NI9213) at iterations 48 and 56.

Any further thoughts are appreciated.

Thanks!

Justin Lee

[John_P1]

By default the number of samples per channel input of DAQmx Read is set to -1.  For a continuous task, this means that it will read all available samples.  If no samples are available, it will return an empty array, which is what you are seeing.

There are a few different ways to avoid this scenario (e.g. utilize the Every N Samples Event, poll the Available Samples per Channel property, specify a specific number of samples to read, etc.).  It depends a bit on what you need to do with your application. 

Do the two tasks have to run at different rates?

Best Regards,

[zeppelinboy]

HI John,

Thanks for your thoughts.

An answer to your question - the two tasks may run at different rates, but in the example code that I have posted they both run at the same rate of 5 samples/sec.

In the above posted example code, the loop executes once every 2 seconds and the tasks are supposedly acquiring data at 5 samples/sec. This is a fairly low sampling rate. The 9215 is capable of at least 5000 samples/sec and the 9213 has a maximum sampling rate of 100 samples/sec - 1200 samples/sec aggregate. There is no reason that samples should not be available when I request them.

I have done some additional troubleshooting and have determined the following:

When either task runs in the loop by itself, there is no data loss.

When the tasks are placed in a stacked structure inside the loop, data loss only occurs for the task which occurs second.

This seems to imply some sort of timing issue with the 9174 itself.

Any ideas?

Thanks,

Justin

[John_P1]

Hey Justin,

Try setting the number of samples to read to be 10 (2 seconds worth of data) and removing the 2 second wait inside the loop.  This should be the easiest fix to your issue if you are running the tasks at the same rate (you could just combine the two tasks into one if this was the case).

Reading -1 will simply read whatever is currently available in the DAQmx Software Buffer.  USB devices tend to transfer large groups of samples from the on-board FIFO to the host at once to help maximize throughput.  In your case, you are trying to read -1 samples while the samples are still in the hardware FIFO and thus wouldn't be avilable to be read.  If you want a specific duraiton of data, you should set the number of samples to read.

If you just want to ensure that the data is available sooner but you don't care exactly how much data you are reading, you can always reduce the Maximum transfer request size with a DAQmx property node:

       

Best Regards,

[zeppelinboy]

Hi John,

Thanks for the reply.

The data acquisition is only a small portion of a much larger program. My loop execution rate can vary, as well as the sampling rate and number of channels sampled. I only set the loop execution rate to 2 seconds in this example to approximate what is happening in the real program.

What I would like to accomplish is to tell the DAQ modules to sample at a specific rate and to hold those samples in a buffer until I ask for them, and then give me all of the samples. Unfortunately, this does not seem to be possible because the DAQ modules want to transfer data in chunks, and apparently can sometimes send chunks too soon, then a chunk is not available the next time I ask for it.

I tried your suggestion of adjusting the transfer request size. I set it to the smallest possible value of 1024 bytes. I still get random missing samples. If I monitor the size of the array that the module is returning when I make a request, I can see that the module sometimes returns 20 samples when it should only be returning 10. The request immediately following the return of 20 samples results in a return of 0 samples. This is the missing data. I am not sure why the data is being packetized in this manner, but I will try to see if there are other settings that can be adjusted in order to unpacketize it.

Any further suggestions would be helpful.

Thanks,

Justin Lee

[zeppelinboy]

I have arrived at a partial, although unacceptable solution.

If I combine both of the tasks into one, set the USBxferreqsize to 1024, and set the sample rate to a higher number (I tried 50 samples/sec, not sure what the lowest setting that I can use is yet), I can collect data without loosing samples randomly.

Unfortunately, this will not work for me as I need to collect samples at different rates for the two DAQ modules, I also need to be able to dynamically generate the tasks.

Any further suggestions would be appreciated.

Thanks,

Justin Lee

[Carl_H]

Justin, I realize this post is a bit old but I was hoping you were able to find a root cause.  We have been experiencing a very similar situation with dropped samples that will throw our PIDs for a loop and of course saves blanks. I have a couple of fixes but they are just band-aids, one is to count the number of samples in the array and if it is zero to pass the last array (repeat points), the other involves using a property node for DAQmx to know how many samples are in the buffer and then take a part of that buffer so that the next time the task decides to pass data consecutively there is something in the buffer to be passed.

Thank you for your time.

C.H.