LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

'wait until next ms multiple' weird behavior

Hi all,

I have a case structure that should be executed once every 500 milliseconds. For this purpose I chose the 'Wait until next ms multiple' and attached to it a numeric constant equal to 500. But the bad part is that the timer's behavior is far from the one expected. Obviously I expect for the case structure to execute twice a second, but it executes at an unpredictable time.
Can anyone provide me with an insight on this?

Thank you very much in advance.
Dana
0 Kudos
Message 1 of 15
(4,232 Views)
The time between the first 2 iterations will be unpredictable, but after that it will begin execution every 500ms as long as your code executes within that amount of time.  If it doesn't, then it might be 1500ms, 2000ms, etc later.
0 Kudos
Message 2 of 15
(4,223 Views)

Brian is correct.  The behavior is expected.  Here is the reason why...

Wait Until Next Millisecond Multiple (WUNMM) looks at the millisecond counter that is ticking away in the background.  Assuming you have code that executes much quicker than 500 ms, the length of the first iteration is unpredictable.  This is becasue the code looks at the millisecond timer and waits until the next multiple of your input.  So, if the section of code with the WUNMM is entered when the millisecond timer is at 350 ms, it will only wait 150 ms, which is waiting "until the next multiple of 500 ms occurs on the millisecond timer".  Each iteration after that should then take 500 ms, again assuming that code runs quicker than 500 ms.

If you want your section of code to take 500 ms for the first and all other iterations, use WAIT not the WUNMM.  Wait is the one with the "wristwatch" icon, not the "metronome" icon.

0 Kudos
Message 3 of 15
(4,212 Views)
I have cannot repeat what you are saying. Do you have code in the loop that may take longer than 500mS to execute could you post your code or maybe a screenshot of your code.



Joe.
"NOTHING IS EVER EASY"
0 Kudos
Message 4 of 15
(4,211 Views)

Adding to what Brian and Ed said.

I seldom use the WUNMM.

I think of it as a random delay generator. Smiley Mad

The only thing you can guarentee about its operation in an app is that you use two of them and they are NOT set for prime number delays, they are quite effective in getting multiple threads to fight for the CPU at the same time. Smiley Surprised

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 5 of 15
(4,202 Views)
Ben, when you say the WUNMM "are quite effective in getting multiple threads to fight for the CPU at the same time", how do you prevent that and wouldn't the regular Wait VI do that, too?
0 Kudos
Message 6 of 15
(4,188 Views)
Hi all, thanks for the shared opinion. For me it;s no big issue if for the first operations, the periodicity of 500 ms does not apply.
But I still cannot see with respect to my application, why wouldn't this clock tick at the programmed time and why would it be dependent of the code. Could one be more explicit about how the timer works and what are its dependencies?
I attached the code. I acquire the input continuously, and want to pass over some of the values acquired in a selective way - meaning although I acquire continuous samples, only each N ms (say N=500ms) I pass the input value to another device..
Then what kind of timer should i use to enforce this facility? Do you have suggestions how I can solve the problem?

Dana
0 Kudos
Message 7 of 15
(4,173 Views)
Hi Sima,
 
You queried "....how do you prevent that and wouldn't the regular Wait VI do that, too? "
 
Yes the Wait VI is preferable since its start and stop are not syncronized to the ms clock.
 
I already alluded to to how to prevent the WUNMM timed threads from running into each other, use prime number timer values.
 
That approach has worked for the cicada* for a long time.
 
Ben
 
* Cicadas are these bugs that spend most of their time under ground, sucking fluid from tree roots. Every couple of years they all come out at the same time and the woods are buzzing with their sound. There are different version of Cicada and they are known as 7-year cicadas, 13-year cicada, etc. THere is a theory that since each version only breads in prime number year intervals, ther is no chance of one version mating with the other version. If you are careful and have left-over 1/120 scaling military parts laying around you can make some impresive looking alien type miniatures. My son loved them.
 
War Story:
One of the guys I work with is a Knee-dragger" (races motorcycles) and was at an event in West Virginia and there was an accident. They brought in a Life-Flight helicopter to get the injured racer to the hospital. He had been troubled most of the day by the large number of Cicada all day but confessed he broke out laghing when the helicopter arrived. It turns out the helicopter must have been "singing" the right song because as the copter was landing,  Cicada in mass aorse to meet the "Big Cicada in the sky".
 
Do y'all have Cicadas in your part of the world?


Message Edited by Ben on 01-29-2008 02:02 PM
Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 8 of 15
(4,157 Views)
I have some bad news, Ben.  The cicadas would mate with each other on the 7-years' thirteenth cycle and the 13-years' seventh cycle.  And yes, we get them and the shells litter the ground all summer.  It's pretty nifty.
0 Kudos
Message 9 of 15
(4,151 Views)
Well the first insight to why this not working as you think it should is because you have two different types of waits in one while loop. You should only have one type of wait statement in a loop. The two types of waits ar fighting each other for CPU time.



Joe.
"NOTHING IS EVER EASY"
Message 10 of 15
(4,145 Views)