DAQ and Touchscreen integration

[m.caron]

I am using the USB-6210 DAQ to read the output of a number of linear transducers and convert these voltages to indicate the actual position of the transducer.

The code runs fine on my computer however when run on the touch panel computer (TPC-2215), it seems like the voltages constantly flicker on and off. ie. they will read a normal value for a random period of time (less than a second) and then have one instant where all voltages read 0 then return to their normal values.

I have managed to produce a similar behaviour on my computer by setting the wait time on my vi to be less than the sample rate of the DAQ (so that the vi reads a 0 value when the daq is not active and a normal voltage when it is) however it does not seem to matter how 'slow' i make my vi, it will still read random zero values.

I have managed to filter out these zero values on my vi producing an acceptable response however I feel that I am turning up the stereo to drown out the noisy car so to speak.

Has anyone seen a similar problem?

Any suggestions?

[_Tim]

DAQmx is not officially supported to run on Windows embedded systems. Though it is sometimes possible to successfully interface a DAQ device with a touch panel computer, the configuration has not been fully tested and is not guaranteed to function with the full functionality found in a desktop configuration. With that said, I’m glad to hear that you were able to create a workaround and achieve an acceptable response.

[John_P1 · Accepted solution]

Hi m.caron,

Can you post a simple example showing how you have configured your DAQmx task?  I have a couple of thoughts:

If you are reading -1 samples on a continuous task you might be getting empty arrays back (reading -1 just returns whatever has already been transferred over USB back to the host computer).  If this is the case, you should set a fixed read size and use the read function to time your loop (e.g. instead of putting a 100ms wait function inside your acquisition loop, it is usually better to explicitly read back 100 ms worth of samples--reading a specific number of samples should initiate the USB transfer making the data available to DAQmx).

Or, perhaps the read is timing out before data becomes available (are you getting any errors from the DAQmx Read?).  If this were the case, the read function would return an error and you should be able to handle it accordingly in software.

I suspect that the inconsistency you are seeing between computers is probably a result of each using a different USB host controller/driver.  If you are (for example) reading -1 samples, the timing of the transfers could vary enough between the two systems to create the behavior you are seeing.

Best Regards,

[m.caron]

---

@John_P1 wrote:

If you are reading -1 samples on a continuous task you might be getting empty arrays back (reading -1 just returns whatever has already been transferred over USB back to the host computer).  If this is the case, you should set a fixed read size and use the read function to time your loop (e.g. instead of putting a 100ms wait function inside your acquisition loop, it is usually better to explicitly read back 100 ms worth of samples--reading a specific number of samples should initiate the USB transfer making the data available to DAQmx).

---

After fiddling around with this, It looks like you are right! I have changed the number of samples per channel to 40 and it seems to be working.

However I am not too sure on why 40 works. If I understand you correctly, I can remove the wait block in this loop and set the number of samples so that i just read X ms of data? Currently the DAQmx is set at 1kHz, so for an equivalent 20ms wait time, I could set the number of samples to 20?

In the attached picture, I had set the refresh rate (wait time) to 20(ms). If i set the number of samples to be much lower than 40, there is a significant delay for the program to see a change in the sensor position. Is there any logic to choosing this number or is it just trial and error?

Thanks for the help!

[John_P1]

I would suggest removing the wait and set the number of samples so you read X ms of data.

However, keep in mind that each loop iteration has a pretty large overhead--each time the loop runs it will have to initiate a USB transfer, wait for data to be available, scale it, then copy the array into LabVIEW's memory (not to mention the file I/O taking place in the loop as well).  For this reason, it is more efficient to read back larger amounts of data at a time but read less frequently.  

If you are seeing a delay in your returned data when you are trying to execute the loop every 20 ms, it probably means that the loop is not keeping up with the data coming in.  Data is stored in a buffer (the size can be configured) and if you are not reading it back fast enough you would be reading older samples (eventually I would expect you to see a buffer overflow error if the reads aren't keeping up with the sampled data).

The maximum sustainable loop rate is going to vary quite a bit from system to system.  If your application does not require an immediate response to the input data then I'd suggest not trying to push any limits and instead try running your loop at a more modest 5-10x per second (200-100 ms loop times).

On another note, I notice you are feeding your read waveform into a global then reading from this global and writing it to a spreadsheet.  You should instead just wire the waveform directly to the Write Spreadsheet File VI (there is currently a race condition since you are reading/writing to the global in parallel and it can't be determined if the current or previous data is what is written to the file).

Best Regards,