DAqmx in timed while loop, measurements are lagging behind?

[LennartM]

I could not edit anymore unfortunatly.

And do you understand why I get double timestamps in the log file? The first row is the timestamp from the logger loop. The second is the actual timestamp from the acquisition loop.  The measurements do differ.

Timestamp logger      Timestamp aquistion  Measurement 1-4
12205302.000000 ,    12205400.000000 ,    0.637403 ,    0.565219 ,    -0.090649 ,    -102.499583 ,

12205400.000000 ,    12205400.000000 ,    0.683806 ,    0.612912 ,    -0.079048 ,    -91.256038 ,

12205402.000000 ,    12205600.000000 ,    0.636114 ,    0.565219 ,    -0.090972 ,    -102.499583 ,

12205600.000000 ,    12205600.000000 ,    0.685095 ,    0.614201 ,    -0.078726 ,    -90.952158 ,

12205602.000000 ,    12205700.000000 ,    0.637403 ,    0.565219 ,    -0.090649 ,    -102.499583 ,

12205700.000000 ,    12205700.000000 ,    0.685095 ,    0.612912 ,    -0.078726 ,    -91.256038 ,

12205702.000000 ,    12205800.000000 ,    0.637403 ,    0.565219 ,    -0.090649 ,    -102.499583 ,

12205800.000000 ,    12205800.000000 ,    0.685095 ,    0.614201 ,    -0.078726 ,    -90.952158 ,

[Bob_Schor]

Can you please attach your VI, not a picture of your VI?  You can "have it both ways", of course, if you attach a Snippet, which looks like a picture but can be pasted into LabVIEW and become code -- just be sure your Snippet includes the entire VI (type Ctrl-A to select all, then Save as Snippet).  You can, of course, also attach your VI as an "attachment" ...

Bob Schor

[LennartM]

I wanted to post only the relevant code 🙂

Hereby as an attachment

[Bob_Schor]

Forget my previous post -- I didn't realize that you were double-posting the same question that I think I essentially answered in the previous post.  However, if you do choose to post a real VI instead of a picture, I might be able to figure out what you want to do (since you never clearly describe the output format you desire) and produce it for you.  Be warned -- I would use the Report Generation Toolkit and save the results in a .xlsx file (which, as I demonstrated, is capable of writing a row of Excel every 50 milliseconds).  Of course, if you clearly describe the output format you desire (e.g. "One row every 10 seconds containing 100 points collected at 10 Hz"), that's what you would get.

Bob Schor

P.S. -- I'm on Jury Duty, so won't get back to my computer until this evening ...

[Dennis_Knutson]

You are getting two timestamps because that is how many you are writing. One tick count from the acquisition loop and one tick count from the logging loop.

No, do not use the timed loop! Either acquire multiple samples and reduce them out switch to hardware timed single input of your board supports it. With 1 sample mode as you have it, it is software timed acquisition as I already said. The wait (ms) or wait until multiple is subject to jitter.

[LennartM]

Thanks for the responses.Bob, thanks for the input. But I want to learn why this program won't work if that is possible 🙂

Dennis,

The acquistion loop should send one notification every time the clock can be divided by 100. But now it seems to send two notifications, with the same timestamp but with different measurements. The log loop should only execute when a new notification comes in. But why is the main loop sending two?

[Dennis_Knutson]

Sorry, I don't understand what you are saying now. That seems to be a different question than you are getting two timestamps in the file. I don't see the main loop sending any more than one result to the queue at a time.

[LennartM]

Well I don't either that is the problem....It isn't supposed to create double entries.
The vi provide creates a log file with double readings.

Timestamp logger      Timestamp aquistion  Measurement 1-4
12205302.000000 ,    12205400.000000 ,    0.637403 ,    0.565219 ,    -0.090649 ,    -102.499583 ,

12205400.000000 ,    12205400.000000 ,    0.683806 ,    0.612912 ,    -0.079048 ,    -91.256038 ,

12205402.000000 ,    12205600.000000 ,    0.636114 ,    0.565219 ,    -0.090972 ,    -102.499583 ,

12205600.000000 ,    12205600.000000 ,    0.685095 ,    0.614201 ,    -0.078726 ,    -90.952158 ,

12205602.000000 ,    12205700.000000 ,    0.637403 ,    0.565219 ,    -0.090649 ,    -102.499583 ,

12205700.000000 ,    12205700.000000 ,    0.685095 ,    0.612912 ,    -0.078726 ,    -91.256038 ,

12205702.000000 ,    12205800.000000 ,    0.637403 ,    0.565219 ,    -0.090649 ,    -102.499583 ,

12205800.000000 ,    12205800.000000 ,    0.685095 ,    0.614201 ,    -0.078726 ,    -90.952158 ,

[Dennis_Knutson]

Each line has unique data and unique timestamps in the first column so it isn't creating double entries.

[Bob_Schor]

If you want to find out why your poorly-organized program is working the way you told it to do, you can trace it, put probes on it, turn on the "Watch" indicator and look at data flow, or (my recommendation!) start all over, slowly, one step at a time.  Best is to write a (text) document saying what you want to do, then develop code that does it.

What I see is an Analog data acquistion loop that seems to take N points at a time at some rate.  You should realize that if you put such a "Acquire N Samples" VI inside a While loop, it will loop once every N samples, and will "clock" itself using the (independent-from-Windows Hardware) clock of the A/D system.  This clock is extremely accurate, and independent of any timing vagueness inherent in Windows.

How do you "use" this clock?  Well, if it sampling, say, 1000 samples at 1 KHz, it becomes a clock "ticking" at 1 Hz, returning when it acquires all of the samples.  This means that you want to put the code that needs to be associated with the clock on the error line just after the Acquisition function.  If you acquire a TimeStamp at this time, it should show times differing by 1.000 seconds.

Now that you have a simple loop that is self-clocked, and have a way of creating a TimeStamp synchronized to the acquisition, you can also add (in the same loop, since you have lots of time, at least 0.9 seconds) code to write the new data to an on-going file.  If you check my last post in your other duplicate post, you'll see that I basically did this using the Report Generation Toolkit.

If you want a little extra safety, you could put the sample and TimeStamp on Queue and send it to a parallel Consumer loop that does the write.  This gives you almost the entire second to do the write.  Clearly doable.

Such a "redo", starting from clean code, should be doable with (I'm estimating here) about 20 LabVIEW functions, and should easily fit on about half a laptop screen.  Give it a try ...

BS