Instrument Control (GPIB, Serial, VISA, IVI)

cancel
Showing results for 
Search instead for 
Did you mean: 

Read data from 2 serial port and forwarding to single port

Albert! Hello,

 

No, I've not. However, there is a lot of 'what if' depending on the code architecture.

 

Loop timing: Because I use Queues and notifiers they inherently time loops and I construct my state machine's 'POLL' state to 'wait' on queue message. Thus I rarely use the brute timing functions. 

 

I could see the metronome having problems if the loop execution time is near the loop time? I'd like to hear more about what you've seen?. I prefer to avoid pitfalls then fall in them!.

 

Regards

Jack Hamilton

 

 

0 Kudos
Message 31 of 38
(1,252 Views)

Jack,

 

We originally developed our Windows-based test system back in the LV7.1 days using the Metronome, but found significant deficiencies when in use.  It waits until the next increment.  This would cause us to have fallout from a 5 second wait seeing about 3 seconds to 7 seconds on a scope versus the Watch which would hold at least the 5 seconds before release.

Help the Community (and future reviewers) by marking posts as follows:
If it helped - KUDOS
If it answers the issue - SOLUTION
0 Kudos
Message 32 of 38
(1,250 Views)

The metronome is for synchronization.  The watch is for actual waits.  Therefore, I rarely uses the metronome.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 33 of 38
(1,243 Views)

crossrulz,

 

The wait multiple is often misunderstood, mainly because of the poorly worded help for it. The description that gives the most insight is the this one: (also in the help)

 

Wait Until Next ms Multiple Details

When LabVIEW calls a VI for example, if millisecond multiple is 10 ms and millisecond timer value is 112 ms, the VI waits 8 more milliseconds until the millisecond timer value is 120 ms, a multiple of 10.

 

I am not sure why the word 'synchronization' is used in the help, it's not clear. What the metronome does is compensate of the overall loop cycle time, by measuring the loop execution time and adjusting its delay to provide a 'loop' cycle in msec specified to its input terminal. Many forget that the code in the loop takes time to execute.

 

The watch simply adds a delay in addition to the loop execution time - this means the 'loop rate' can be inconsistent. The metronome will give you a consistent loop rate, far better than the simple timer.

 

That said, one's coding style can result in lots of claimed inconsistencies in LabVIEW's  core functions. I know many who have lots of problems with Queues and notfiers. When in fact they are quite robust, provided their implementation is understood.

 

Regards

Jack Hamilton

 

 

0 Kudos
Message 34 of 38
(1,240 Views)

Jack,

 

I tried executing your vi but it's not working somehow.

 

Aniket

 

0 Kudos
Message 35 of 38
(1,239 Views)

Aniketja,

 

What exactly is 'not working'. I have LV2016 so I had save to previous version.

Try opening the VI and hold down Ctrl+Shift and the Run button [Mass compile]...see if that helps.

 

Regards

Jack Hamilton

0 Kudos
Message 36 of 38
(1,236 Views)

MrJackHamilton wrote:

I am not sure why the word 'synchronization' is used in the help, it's not clear.


Because it "synchronizes" the loop rate to the ms timer.

 

As far as the rest of your post, most people have the wait in parallel with the rest of the loop code.  In that case, it really does not matter which you use.

 

For me, almost all of my loop rates are determined by queue timeouts or instrument communications.  So I often do not have any waits for my loops themselves.  I may have waits as part of a sequence, in which case the normal wait works best.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 37 of 38
(1,231 Views)

Hi Jack

most is already said. I always the watch when I have to make sure I don't need 100% cpu waste in polling something. If I need better timing I try to use hardware timing. If I really need software timing I make sure that the first wait on multiple ms is done before the loop so to start a known border and not having the first loop a timing close to zero. 

My problem is when people start to use 10, 20 50, 100 ms waits in several parallel loops in the program. Because they all will coincide at peak moments of processor load instead being spread over time.

The wait multiple in RTE is much better. It starts at from the first moment to wait exactly the number of ms asked and adapts to the offset of the system clock while the windows version synchronizes withe system clock. I wish we could choose which of the two versions to use in windows.

 

I hpe I made it clear enough.

greetings from the Netherlands
0 Kudos
Message 38 of 38
(1,228 Views)