Numerical Indicator Update Rate

[Mark H]

I'm never keen on parrallel loops and local variables - it can be a clumbsy solution, particularly in such as small job.

Here's my solution - pop this VI in front of your numeric indicator, and wire in your chosen update interval (milliseconds).

A five star solution I reckon?

Mark.

[altenbach]

Mark,

I do not understand your solution. It seems equivalent if you would replace your WHILE loop with a single sequence frame containing a wait statement, except that your solution consumes 100% CPU doing basically nothing. Are you running this using the "continuous run" button??? The continuous run button is just a debugging tool and has no purpose for normal use.

This is NOT a solution to the problem discussed! 😮

KevC and SarahB,

It seems overkill to run two different loops, because you don't really save anything. (updating a local variable (!) and maintaining a second loop is probably more expensive than just updating the indicator all the time ;))

What you need to do is simple. Place all the desired "slow" indicators inside a case structure which turns true only after e.g. every 25th iteration. See attached modification (LabVIEW 7.1).

Message Edited by altenbach on 01-05-2006 08:51 AM

[Mark H]

Hi Altenbach (& KevC),

I only had 15 minutes to create and post that sub VI before setting off for home, so didn't have time to explain clearly how it should be utilised.

Here is a demonstration that should make it very easy to see how you would use it... (see attachment).

It enables you to run a single while loop at full/high speed (no parallel loops or local variables), but slows down the update rate of the variable passed through the sub VI. Note that I've made the sub VI "reentrant execution", so you can use the same sub VI in multiple instances/indicators without any confusion of values.

Now - where are my stars!

Mark.

[altenbach]

OK, this makes more sense 🙂

However, be aware that the slow indicator STILL gets "updated" at the fast rate (= with every iteration of the loop!), just with a stale value most of the time. ;).

[Mark H]

---

@altenbach wrote:

However, be aware that the slow indicator STILL gets "updated" at the fast rate (= with every iteration of the loop!), just with a stale value most of the time. ;).

---

Of course - but that's no different to writing the value to the local variable in the "parallel loop/local variable" method - the second loop may run slower but the fast loop is still writing values to the local variable at the fast rate.

It's worth pointing out (as I'm sure you yourself are aware) that the LabVIEW user interface will not "physically" update an indicator display (i.e. rewrite a numeric, or redraw a plot, etc) unless its value has changed.

Also, another thing worth a mention - by default, the LabVIEW user interface runs asynchronously to the user code (unless you explicitly set it to be synchronous); so for example, if you have an unrestricted loop write an incrementing value to a numeric indicator, the display is only going to be updating say 25 times a second (guessing the probable rate) even though the incrementing value itself will be able to reach 10's of millions (for example) of increments in the same time period.

[altenbach]

---

@Mark H wrote:
It's worth pointing out (as I'm sure you yourself are aware) that the LabVIEW user interface will not "physically" update an indicator display (i.e. rewrite a numeric, or redraw a plot, etc) unless its value has changed.

---

This might be true (and I'm not sure it is), but there is a clear benefit NOT to place the indicator terminal in the code path. There is definitely cost involved, even if it is only the checking if the data has changed or not 😉

In the attached example (LabVIEW 7.1), the graph ALWAYS gets the same data, yet having the terminal in the code path slows down the execution time significantly.

• "updating" every iteration (skip=0): 280ms
• "updating" every 10th ieration (skip=9): 29ms
• "updating" every 100th iteration (skip=99): 6ms

Sure, it typically is not worth bothering, but this is something to keep in mind if there is a lot of data involved. (In your case, you could add a "data changed" boolean output to your subVI.) 🙂

And YES, I agree that the earlier solutions by others using local variables are not that great.

[Mark H]

---

@altenbach wrote:

---

@Mark H wrote:
...the LabVIEW user interface will not "physically" update an indicator display (i.e. rewrite a numeric, or redraw a plot, etc) unless its value has changed.

---

This might be true (and I'm not sure it is), but ....

---

It's definately true (I remember being told this way back on a "LV Basics" training course) and it can be demonstrated by the same method you use in your example.

That said, you're certainly correct in saying that by selectively not writing data updates to a terminal will save even more time - because even though the LV indicators are "inteligent" (i.e. don't "physically update" if the input data is unchanged), they still must consume some time comparing the new data against the old data in order to decide whether or not the indicator needs to be physically refreshed.

I've modified your example to demonstrate this (saved in LV version 7.1)...

On my PC, with the graph indicator set to "asynchronous display" (the normal default setting), a million iterations writing constantly changing data to the terminal takes about 6300 ms, whereas writing unchanging data only takes about 3700 ms.

If the indicator is set to "synchronous display" the difference is even more dramatic - a thousand iterations writing changing data takes about 17.7 seconds, whereas writing the same amount of unchanging data only takes about 1.5 seconds (a huge difference).

Note the massive, approx 2000x, performance hit when setting the indicator to "synchronous display" - i.e. the huge advantage of LabVIEW's user interface running asynchronously with the user code.

There's no functional reason why the "indicator intelligence" benefit/gain is so much more when the "synchronous display" mode is enabled - although part of the explanation must simply be that in the "synchronous" demonstration the data is always changed with each iteration (thereby producing a refresh), whereas by definition the "asynchronous" demonstration will randomly have changed/unchanged data at the terminal at the indicator refresh time (because the refresh is not synchronised with the loop iterations/data toggling)

Mark.

P.S. I saved the modified example program with the indicator's "synchronous display" selected and the number of iterations=1000. You will need to "right-click" and deselect "synchronous display" and increase the iteration constant on the diagram to say 1,000,000 to test the default asynchronous display mode.

Message Edited by Mark H on 01-06-2006 06:19 AM

[Mark H]

After posting the last message I've thought it through and now have a clearer explanation of the difference between the results between the "synchronous display" and "asynchronous" display...

The time saved by not having to physically refresh an indicator (when the data written to it is unchanged) is far smaller when the indicator is in the "asynchronous (the default)" mode - simply because there are far, far, fewer indicator updates as a propotion of the number of loop iterations.

i.e. In the default "asynchronous mode", the indicator is probably only updated say 25 times per second while the loop may well execute 1,000,000 (million) data updates - so the tiny time saving per avoided indicator refresh is very small.

In "syncronous display" mode the loop is vastly slowed down by the need to consider the need to refresh the indicator for every write/iteration even if a refresh is not required - i.e. the user interface will at least check the new data against the old data for every update written, whereas in the "asynchronous" mode example above, the refresh check will only be done 25 times per 1,000,000 write/iterations.

In "synchronous" mode there are maybe 1000 refresh comparisons per second to be made, where a no data value change so no indicator refresh timesaving can be made - in the "asynchronous" mode, the loop runs vastly quicker but there are maybe only 25 refresh time savings to be made.

Attached is a better and mor simple illustration of an indicator not needing refreshing when the valu is not changing...

Mark.