'wait until next ms multiple' weird behavior

[RavensFan]

You have a couple of things going on.  You have a 125 ms Wait timer at the top.  So your entire loop will take at least 125 ms per iteration.  You have a 500 ms wait until next near the bottom.  That basically runs in parallel with everything else.  So that will run dead on every 500 msec slot of the computer clock.  I'm not sure why you have the divide by and remainder operations.  That will always return a 0 because 500 always comes out of the metronome and dividing by the same value should always return a 0 remainder, which has a 0 for sign, which when ORed with a 0 returns 0.  So all of that is just enforcing a dataflow causing the data to be put in the queue after the 500 ms slot has passed.  Once all of that is done, however long it takes, the loop ends and goes back to the beginning where the DAQ read will happen again, so the timing between DAQ reads will vary depending how long that takes to run.

I would make a backup copy of your work.  Turn the 125 ms at the top into a 500 ms.  Get rid of the 500 ms wait until next and all the math and comparison and the case structure.  Just queue iup the data when you get it.  The Wait 500 ms guarantees the loop will take at least 500 msec to run.  If all the other code running in parallel gets done first, then the loop will just pause until that 500 ms timer is up.  If the code takes too long, then the 500 msec timer will expire first and the loop will take as long as it needs for the code to finish.

[GReaper]

Hi All,

I just want to add a comment here regarding the uncertainty between the first and 2nd iteration when using WUNMM.  I encountered this and have attached my solution.  I watched the time stamping and everything seems to work as you'd exepct from the first loop iteration on.  This assumes, of course, that the inside loop code completes in less time than the wait.

I'm looking for some feedback on the suitability of this solution.

[RavensFan]

That looks like an acceptable solution to me.

[oldpan]

Ravens Fan,

thank you for the explanations. I could simplify the application as you suggested, but my aim is that while i acquire data from the acquisition system continuously with small period T0,  this data should be recorded in binary files, and from period to period, T1 (T1>T0), the data should go to another module to process this time-selected data. What you suggested is going to both record the data and tranfer it to another module (the consumer) with the same rate, although the rate is lesser.
So  basically I need two rates for the two actions I want to perform. Do you think it would be an idea to have a single clock for recording data, and to derive an arithmetic out of its value or use a second clock dependent on the first for the second action?

Best regards,
Dana

[RavensFan]

As you have it now, although there are two different wait statements in the loop, the loop will only run as fast as the slower wait statement will allow it.  I would recommend just using a single loop rate for whichever task needs to be done more rapidly and doing the calculations off of that to determine when to do the other task.