LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Problem in getting the output in equal intervals

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

fig1.pngfig.2.jpgfig 3.jpgfig 4.jpg

0 Kudos
Message 1 of 10
(1,356 Views)

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.

0 Kudos
Message 2 of 10
(1,321 Views)

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.

 

 

 

code part1code part1code part2code part2resultsresults

 

 

 

0 Kudos
Message 3 of 10
(1,299 Views)

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. 

0 Kudos
Message 4 of 10
(1,291 Views)

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

0 Kudos
Message 5 of 10
(1,287 Views)

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

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 6 of 10
(1,279 Views)

Hello Kevin,

 

I did the same but still no significant change, is there any other way to get at consistent intervals. 

 

Rawoof

0 Kudos
Message 7 of 10
(1,271 Views)

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

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 8 of 10
(1,264 Views)

@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.

Message 9 of 10
(1,252 Views)

 Hello John,

 

Thanks, now I have improved response.

 

Rawoof

0 Kudos
Message 10 of 10
(1,219 Views)