Indicators in or out of loop?

[dhp7320]

Please see attached sample vi (LV2023 Q1).

Question 1: Is it better to locate an indicator outside of a loop on the base level of the block diagram and then change it via local variable inside the loop, or simply put the indicator inside the loop and change it directly? I've read comments that putting indicators inside loops is worse for compiler optimization. I'm curious if there are other efficiency reasons and/or best practice reasons for doing this one way or another.

Question 2: The application here is to have some indication on the front panel that a loop is alive and running. The indicator does not need to run at the same rate as the loop, but just provide a heartbeat indicator for the loop. Is there a better way? Something with shift registers, or timers, or something all together different? The sample code has an alternative using the blinking property node that seems like it might be low overhead but doesn't tell me if something is stuck/frozen inside the loop and it's not actually iterating.

Thanks,

David

[altenbach]

Sorry, can't see your VI, but placing indicators is always better than placing local variables. Indicators update asynchronously in the UI thread. Even if the loop runs millions of times per second, all it updates is the transfer buffer of the indicator and the UI thread will update the front panel at a leisurely pace (unless you set the indicator to "synchronous display", not recommended and not the default!). Writing to a local variable does the same, just with more overhead.

If you want more users to see your code, consider "save for previous" (2020 or below) before attaching.

In general, you can trust the LabVIEW compiler to be efficient.so don't overthink things. Once you run into performance problems, you can revisit.

[crossrulz]

---

@dhp7320 wrote:

Question 1: Is it better to locate an indicator outside of a loop on the base level of the block diagram and then change it via local variable inside the loop, or simply put the indicator inside the loop and change it directly? I've read comments that putting indicators inside loops is worse for compiler optimization. I'm curious if there are other efficiency reasons and/or best practice reasons for doing this one way or another.

---

The general rule for subVIs is to have the terminals on the top level diagram.  But for top-level VIs and/or GUIs, just put the terminal where it is written the most.  Avoid the local variables whenever possible.

---

@dhp7320 wrote:

Question 2: The application here is to have some indication on the front panel that a loop is alive and running. The indicator does not need to run at the same rate as the loop, but just provide a heartbeat indicator for the loop. Is there a better way? Something with shift registers, or timers, or something all together different? The sample code has an alternative using the blinking property node that seems like it might be low overhead but doesn't tell me if something is stuck/frozen inside the loop and it's not actually iterating.

---

I tend to avoid using the iteration terminal for these sorts of things, mostly because of work I've done in FPGA.  Instead, I use a shift register and iterate it myself.  If not on RT, I will use the Quotient & Remainder to reset the value, using the remainder.  You could then toggle the indicator when the remainder is 0.

[Kyle97330]

---

@dhp7320 wrote:

I've read comments that putting indicators inside loops is worse for compiler optimization.

---

Altenbach already did a pretty good job of covering the "optimization" part here, but one other highly recommended coding practice (that crossrulz hinted at) is to put all indicators that are used as subVI outputs on your top-level diagram (i.e. not inside any loops, case structures, or other structures).  There are several reasons for this:

• Makes it easier to find the outputs of the subVI at a glance and trace them back to what creates their output values
• Prevents old values from previous executions from being output accidentally
• Forces consideration of all possible execution paths to decide what the output should be in each case

It sounds like this is a VI that is likely your main VI (or at the very least a pop-up subVI where the indicator in question isn't an output) so none of that applies to you, but those reasons are possibly part of why you may have seen comments encouraging indicators to not be inside loops, whether for optimization or good coding practice.

[altenbach · Accepted solution]

OK, I had a quick glance at your VI.

• You seem to light up on even i, so [i AND 1=0?] would be more lightweight that Quotient&Remainder, especially since you are not even interested in the IQ part! To blink slower, you can "AND" with other powers of two.
• You can also just toggle a boolean in a shift register.
• The blinking is not useful, but you definitely don't need any sequence structure. Just use dataflow to determine execution order.

Here are some alternatives A, B, and C will blink the same.:

Note that updating a boolean indicator is trivial. Think about optimizing when updating huge arrays or graphs with tons of data.

[altenbach]

---

@Kyle97330 wrote:

..., but one other highly recommended coding practice (that crossrulz hinted at) is to put all indicators that are used as subVI outputs on your top-level diagram (i.e. not inside any loops, case structures, or other structures). .

---

If indicators need to update during the loop to show progress, they belong inside the loop. If the loop is fast and only the final result counts (e.g. a Newton algorithm), no indicators or wait should be inside the loop.

(I don't understand the "subVI" comment. That seems offtopic here. It also depends if the subVI shows the front panel and if intermediary values are interesting to the operator, such as a progress bar).

[altenbach]

Here are some Booleans that blink at various rates of the loop rate. Pick whatever is suitable.

[dhp7320]

D'oh. I feel silly for having missed the obvious, simple and elegant solution of just putting a NOT in the shift register wire (my shift register version was unnecessarily complex). Also, using the AND with integers was an unexpected and unknown idea for me also. Thanks so much for both of those ideas.

I realize the efficiency question isn't really of concern for this application of toggling booleans, but, I appreciate the discussion as it helps me understand how LV works.

In the end, I used all of the replies to create the attached (I also learned how to do snippets). It gives me a nice consistent heartbeat with a variable (and very slow) loop rate. For my actual application we are having some trouble with a remote device in an unfriendly environment so I'm just trying to add some simple feedback and diagnostics to what should have been a simple read data task. Thanks again for helping me come up with a nice solution.

[altenbach]

There really should not be any orange anywhere.... 😄