02-28-2022 10:12 AM - edited 02-28-2022 10:29 AM
Hello,
I have a problem getting the output of my two thermocouples(T1 and T2) and the flow meter(m.dot) outputs at equal intervals as shown below(last fig)
I have used the sample clock to set the sample rate at 20 Hz and samples per channel along with the sample mode as shown in fig1.
Inside the while loop, I have used wait until next ms multiple and I have set it to 50milli sec shown in fig.2 &fig 3.
I'm getting the outputs at random intervals but not at every 50 milliseconds, as shown in fig 4.
I want the outputs at every 50 milliseconds as 0.050,0.100,0.150 etc. Can someone help me to get through this?
Thanks in advance
Rawoof
02-28-2022 11:34 AM
You really need to share more of your code, but the first obvious question is why are you using the wait until next millisecond multiple? You have the timing set up on the DAQ so why not use it to do your timing. It is much more reliable than loop timing.
On a side note, do you notice the coercion dot on the wait until next millisecond multiple? The wire going to that primitive should be blue, specifically a U32. Additionally, what is the purpose of multiplying by 1?
Without seeing more of your code there's not much more help that can be given. Note that a vi is worth a thousand pictures.
02-28-2022 03:27 PM - edited 02-28-2022 03:34 PM
Hello John,
Thanks for the response. Here I'm sharing the complete code(first two images)
Yes, as you suggested I have removed, wait until the next millisecond multiple but still, it shows no significant change in the output timings still it is random. (results).I tried all the possible ways but I'm unable to get the time interval as .050,0.100,0.150 etc.
Also, I have attached the VI.
02-28-2022 03:49 PM
Rather than using loop time read your data as a waveform and use the DAQ timer. Loop timing does not equal the timing at which the data are read from the DAQ device and put into the buffer.
02-28-2022 04:02 PM
Yes, as you can see in the above code the while loop time is removed and only DAQ timer(Sample clock ) is used, but still, the output time is not exactly the at an interval of 50milliseconds for the sample rate of the 20Hz.
Note-Check the previous message images.
Thanks
02-28-2022 04:30 PM
Add some dataflow to make sure the call to DAQmx Read returns *before* you query for High-Res seconds. As it is now, you're just seeing jitter in the variable amount of time you have to wait for the next sample from one iteration to the next. With dataflow sequencing, you'll make the query at more consistent timing intervals. (But still don't expect perfection from *any* software-queried timing info.)
-Kevin P
02-28-2022 05:00 PM
Hello Kevin,
I did the same but still no significant change, is there any other way to get at consistent intervals.
Rawoof
02-28-2022 05:36 PM
1. Post what you did to enforce dataflow -- I would have expected a mild improvement.
2. In the end, it doesn't much matter anyway. Hardware timing will be correct. Measuring that timing with software queries is subject to uncertainty and jitter.
The sample intervals are *defined* by the hardware sample clock. That's where the truth is. The software time queries can never be better than an estimate.
If you were to use the waveform version of DAQmx Read, the 'dt' field would tell you the exact sample interval to within a small fraction of a microsecond. You can accomplish the same thing by querying a DAQmx Timing property node after configuring DAQmx Timing. That'll give you the *actual* sample rate, which may differ a bit from what you request if the device isn't capable of sampling at the exact rate requested.
-Kevin P
02-28-2022 09:00 PM
@Rawoof wrote:
Yes, as you can see in the above code the while loop time is removed and only DAQ timer(Sample clock ) is used, but still, the output time is not exactly the at an interval of 50milliseconds for the sample rate of the 20Hz.
Note-Check the previous message images.
Thanks
Yes, I saw that you had taken out the wait for millisecond multiple, but the time that you’re using is from your loop timer. The loop timing is subject to jitter. Change to waveform and use the timing from there. The data are actually timed as expected.
03-07-2022 09:57 AM
Hello John,
Thanks, now I have improved response.
Rawoof