DaqMX analog inputs drop to 0

[abashore]

Hi all,

I'm reading analog inputs from 4 devices, displaying them , and logging to a file. I have voltages, and some thermocouple channels, with a total of about 28 channels. I am using two USB 6210's, and a 9174 Chassis with a 9219 and a 9213.

The problem is, periodically the analog inputs drop to 0. I'm scanning at 100 Hz, but want to display and log the data at 10Hz.

I broke out the Y components of every channel so that I could add scaling options for each channel independently on the fly. There might be a better way to do that, but I stuck with what I know. 

When I run MAX, and start a scan in my tasks there, the data looks fine. It's only in the VI where it drops out to 0.

Any thoughts? 

BTW I'm still learning, and have tried to venture out of using express VI's. So if something is obvious to a more experienced user it might not be to me. 

Thanks,

[johnsold]

Do the dropouts show up in the file also, or just on the chart?

Your data is somewhat noisy. It might be better to take all the samples in each array and calculate the mean rather than just using the first element.

If you are not going to use the timing information in the waveform datatype, change the DAQmx Read.vis to 2D DBL output rather than 1D Waveform. Then you do not need the Get Waveform Attributes nodes. You could put Mean.vi inside a for loop and autoindex over all the data.

It is generally best to avoid local variables when wires will work. You can get into race conditions, they are far slower than direct connections, and they may make extra data copies.  It is very likely that your charts are getting data from a previous iteration of the loop due to the way the locals are read. It is possible that they may be part of the dropout problem, although I cannot convince myself that it is definite.

Lynn

[abashore]

Good question, I haven't even looked at the data file. Unfortunately, the data dropouts on the charts are unacceptable so the issue still needs to be addressed. I increased the buffer size, and in doing so that helped out quite a bit. 

Thanks for the info on the 2D DBL, I suppose I kept the waveforms because I was previously using tdms logging, or the write to file express VI. SInce I am inserting a time string into the write to spreadsheet I guess I don't need to do it that way. 

I wasn't aware of the potential problems with local variables. What if I ran them in another loop, say running at a slower speed? I was getting complaints of the data moving too quickly in the 10Hz loop. I was thinking of moving the charts and indicators of the data into another while loop running at say 1Hz using the local variables. Would I still have issues? 

Thank you for the response,

[johnsold]

Look at the Producer/Consumer architecture. It uses parallel loops so that you can run acquisition at one speed and display and file I/O at other speeds. There are examples with all recent versions of LV.

The Producer/Consumer system uses queues to transfer the data. The queue avoids most of the problems of the local variable. The queue also can serve as a temporary buffer to accomodate the differing loop speeds.

One reason I asked about the file was that the data does not go through the locals.

Lynn

[abashore]

Hi again, it looks like we are still getting occasional dropouts in the data, in the display graphs, and in the data file as well. Since I increased the buffer size these have been happening much less frequently, but is still annoying to deal with. Any thoughts?

The vi works fairly well as is, with the exception of the dropouts, so I don't want to go and make any major changes right now if I don't have to. We will be running the real test tonight so I probably won't have time anyway. But I will be looking at the producer/consumer archituecture moving forward. 

[crossrulz]

It is very likely your saving to a file is slowing down your system too much and you get buffer overflows.  Use a Producer/Consumer setup to log the data in another loop.

You also should not be using another loop to read local variables to update graphs.  Just update them in your main loop.  It is a lot more efficient.

[abashore]

Ok thanks, that makes sense.

I do not want my digital displays or graphs updated at 10 Hz, that's why I put them in another loop timed at 2Hz. It's easier for the operators to read that way, as the data tends to fluctuate +/- a few milivolts. I suppose that's just putting a band aid on the problem though, huh?

I'm guessing the producer/consumer loop would function the same way in this regard correct?

Thank you for your response, I appreciate it. 

[crossrulz]

---

abashore wrote:

I do not want my digital displays or graphs updated at 10 Hz, that's why I put them in another loop timed at 2Hz. It's easier for the operators to read that way, as the data tends to fluctuate +/- a few milivolts. I suppose that's just putting a band aid on the problem though, huh?

I'm guessing the producer/consumer loop would function the same way in this regard correct?

---

Not really.  With a Producer/Consumer, you use a queue to pass your data from the producer (DAQ reading) to the consumer (logging to disk).  A queue is a lossless data transport, so you will process (save) all of the data.  You shouldn't have any waits in your consumer loop since you need it to run as fast as possible or the queue could get really large in memory.  If there is no data in the queue, the Dequeue Element causes the thread to sleep until there is data in the queue.  Therefore, the Dequeue Element acts as your wait.