From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
LabVIEW
Elapsed Time VI Writing Duplicate Time Values
Hello everyone,
So I am having trouble writing time at 1000Hz. I am using the producer consumer template to do high speed data acquisition across two channels with the USB 6002. The issue I am having is my VI writes two sometimes three of the same time values. I initially thought it was because the elapsed time VI outputted a single precision number, resulting in rounding. It is not a single precision number; it is double precision. I checked to see if time was being rounded somewhere in the producer consumer template. It’s not. The same time value which outputs the elapsed time VI is the value which is written to the text file. Down below is a screen clipping of an array on the front panel to prove this.
Can the elapsed time VI not keep up with a 1000Hz? If so, how do I fix this?
Down below are screen clippings of my VI and data. I also attached the VI if you are curious.
Any information would be appreciated!
Hi Kurtz,
there are several "problems" in your VI:
- You set a samplerate and a "sample per channel" for the DAQmxTask using DAQmxTiming: don't fiddle with "samples per channel" unless you are really sure what you are doing here! (read the help…)
- You read your samples one by one: this is NOT recommend! The common recommendation is to read blocks of samples with about 1/10 of sample rate, in your case read 100 samples per DAQmxRead!
- Why don't you use the timing provided by DAQmx? Read your samples as waveform including a timestamp!
- You can apply scales to your AI channels, no need to convert voltages "manually" in the code.
- You can resize IndexArray to output more than one value, and you can omit the index input when you start indexing at zero…
- Don't access files inside the DAQ loop when you want to maintain strict timing! (Big fail.)
- Why do you use ElapsedTime? Why not use HighResolutionRelativeTime instead?
- There are some race conditions in your DAQ loop…
You set a samplerate and a "sample per channel" for the DAQmxTask using DAQmxTiming: don't fiddle with "samples per channel" unless you are really sure what you are doing here! (read the help…)
I fixed this. Thank you for the tip.
- You read your samples one by one: this is NOT recommend! The common recommendation is to read blocks of samples with about 1/10 of sample rate, in your case read 100 samples per DAQmxRead!
What exactly do you mean? Are you suggesting I change my DAQmx Timing to sample at a rate of 100Hz and change “Sample Mode” to Finite Samples? If so, how do I specify the size of sample block?
- Why don't you use the timing provided by DAQmx? Read your samples as waveform including a timestamp!
I am using DAQmx Timing? The DAQmx timing VI is placed outside my VI to initialize the USB 6002. I also don’t care about the time stamp (date & time). I just want elapsed time to be written to a text file.
- You can apply scales to your AI channels, no need to convert voltages "manually" in the code.
I intentionally want to manually change voltages. Students are going to be using this with different load cells/pressure transducers and I want to be able to easily change the calibration curve.
- You can resize Index Array to output more than one value, and you can omit the index input when you start indexing at zero…
Can you show me what you mean exactly? Does this speed up the code?
- Don't access files inside the DAQ loop when you want to maintain strict timing! (Big fail.)
I believe you are referring to this area of the code. These case structures will be used for calibration which is low speed data acquisition and doesn’t need precise timing.
- Why do you use Elapsed Time? Why not use HighResolutionRelativeTime instead?
I used Elapsed Time, because it was easy to implement. So I just implement “High Resolution Relative Seconds” in my VI and for some reason it was outputting a number in the thousands. I was not sure why it was displaying thousands of seconds. Initially I thought it was displaying the current time in seconds, but it wasn’t. To correct this, I used feedback nodes to restart the time from zero. How much will this slow down the code? Regardless, this fixed the timing issue I had. THANK YOU VERY MUCH.
- There are some race conditions in your DAQ loop…
I realize that my VI displays charts and indicators which isn’t ideal for race conditions. However, this code is being used for more than just 1000Hz tests. It will be used for calibration and other low speed data acquisition applications so the charts are necessary.
Thank you very much for taking the time to review my code!
It has helped a bunch!
Attached is my new code if you are curious.
Keep a time in a shift register. In the FALSE case, you use the High Resolution Relative Seconds to feed the shift register. So this will hold the time of the last FALSE case. Then in the TRUE case, you wire that value straight through and subtract from the current time to get your time difference.
Hi Kurtz,
I realize that my VI displays charts and indicators which isn’t ideal for race conditions. However, this code is being used for more than just 1000Hz tests. It will be used for calibration and other low speed data acquisition applications so the charts are necessary.
Well, even more you should get away from "N channels, 1 sample" mode!
So this for some ideas:
- I used the waveform mode of DAQmxRead with waveform functions in the loop.
(I forgot to wire a block size (=number of samples to read) to DAQmxRead.)
- I used the timestamp of the waveform…
- NEVER delete the lables of controls/indicators in the block diagram! You may hide them in the frontpanel or use captions instead!
- Why do you convert your readings to strings for display, just to convert those strings back to numbers for MinMax calculation??? That's pure Rube-Goldberg! (Enable the digital display of the chart and set it's formatting!)
Hi Kurtz,
Where specifically in your code are you avoiding this?
Do you see the mode (polymorphic instance) of the DAQmxRead function? It's "n channels n samples"!
I am also still not sure where I can specify the number of samples in DAQmx Read. I only see timeout.
Once you change the DAQmxRead instance you can also provide a "number of samples" input. Did you read the LabVIEW help for this function?
LabVIEW also comes with ahuge library of example VIs! Please look for the "Voltage - Continuous Input" example!
