LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Synchronization problems during measurements (using while loop)

Hi everybody,

 

I'm programming a LabVIEW code to connect to an Agilent Multimeter (model 34405A) to measure electrical continuity.

 

The code is very simple, but unfortunately the multimeter sends me measurements in different time periods. I guest this behavior is caused by the multimeter internal trigger, but I'm not sure... I observed that the synchronization problem is caused during the frame labed with Block 1. This block spends different periods of time to run in ms (40, 60, 80, 40, 50...). The block 2 always runs in 12 ms. The overall while seem synchronization problem too.. 

 

I'm trying to force the measurement cycles run always with the same period (greater than requests and transfer measurements). So, I'm using the Wait Until Next ms Multiple to fix the period of time of Block 1 and the period of the entire loop, but it's not working...

 

Could anyone send a idea?

 

This is my code:

 

 

Thanks in advance.



Message Edited by Klein on 12-19-2007 11:02 AM

Message Edited by Klein on 12-19-2007 11:03 AM
Download All
0 Kudos
Message 1 of 6
(3,354 Views)
I would recommend putting the wait until next ms in it's own frame to guarantee when this operation occurs.  You will need to make this time larger than 80ms especially if Block 1 alone can take up to 80ms. 
I would break Block 1 up (three pieces maybe) and see if you can narrow down the problem.


0 Kudos
Message 2 of 6
(3,329 Views)

No, don't add any extra sequence frames, that's not the problem!

You problem is purely mathematical. 🙂 Wait next ms multiple does exactly that, it waits until the tick count is an integer multiple of 80 ms.
The problem is that 500 ms is NOT a multiple of 80, meaning that the two waits interact in an unwelcome way.

Lets say for simplicity the tick starts at zero.

Iteration 1:
Frame 1 ends after 80ms (tick=80, 1x80) and the loop will finish after 420 more ms, when the outer wait reaches a multiple of 500 (tick=500).

Iteration 2:
Frame 1 ends at the next multiple of 80, this is at tick 560 (7x80!), meaning the first frame only takes 60ms! Loop iteration completes at tick=1000.

Iteration 3:
Frame 1 ends at tick 1040 (13x80), now the first frame only lasts 40ms! Loop completes at tick 1500.

etc.

The wait for the first frame will change in a regular sawtooth pattern between 80 and 0ms!!!! (80ms, 60ms, 40ms, 20ms, 0ms, 80ms, 60ms, ... etc) 

You need either...

  1. a plain Wait(ms) in frame 1 or
  2. you need to ensure that the outer loop "wait next ms multiple"  is an interger multiple of the "wait next ms multiple" in frame 1.

Makes sense? 🙂

Message 3 of 6
(3,321 Views)

Thanks ShotSimon, I think you solution will work too!!!

Hey Altenbach, you are my fan mentor!!! Smiley Happy

I have being problems with Wait Until Next ms Multiple for a long time because the LabVIEW help doesn't seem clear enough about this function!!

Your explanation was great (thanks for your time!). You said exactly what happens with the time inside the Frame 1: 80ms, 60ms, 40ms, 20ms, 0ms, 80ms, 60ms. Finally I understood what the "tick" means and it does make sense.

Thanks a lot, Altenbach.

I uploaded two examples to indicate the synchronization problem related to "tick iteration":

Example 1 (Frame 2 is multiple incompatible with the Wait function outside the frames):

 

Example 2 (Wait function inside the Frame 2 is multiple with the one outside. Note that the time of execution of Frame 2 is 40ms = 50ms - 10ms (of Frame 1) and the iteration time is 500 ms:

 



Message Edited by Klein on 12-20-2007 07:23 AM
Download All
0 Kudos
Message 4 of 6
(3,296 Views)
Too funny.  I did not see that you were using two wait until next ms.  I'm happy to see you figured it out.  SS


0 Kudos
Message 5 of 6
(3,289 Views)
Just some additional notes:
  1. For the same reasons, the first iteration of a loop has a random wait between zero and the ms value if you use "wait next ms multiple".
  2. All later iterations will be more regular and are less likely to drift compared to a plain wait.
  3. To troubleshoot issues like that, I usuallly hook up a chart for the time measurements. You'll immediately see the pattern. 🙂

 

Message 6 of 6
(3,275 Views)