LabVIEW
Best practice Reference node or FGV
I sometimes use the timeout event for final recalculation and indicator updating. The trick is to keep the timeout value in a shift register and set it to -1 (infinite) inside the timeout event. All events that require updating set the timeout to a small finite value.
In more general terms, generously updating controls is a good habit and I don't recommend to micromanage indicator terminal placements deep inside their relevant event case or other structures. Code is much easier to maintain if they are all in an easy to find diagram location. If your front panel consists of several tab layers (example), you need to ensure that indicators get rewritten if the tab is changed. LabVIEW often optimizes front panel updates and ignores things that are currently not visible and if you later change tabs without updating, you might not see what you expect.
@drjdpowell wrote:
@altenbach wrote:
If your front panel consists of several tab layers (example), you need to ensure that indicators get rewritten if the tab is changed. LabVIEW often optimizes front panel updates and ignores things that are currently not visible and if you later change tabs without updating, you might not see what you expect.
Is this true anymore? I admittedly don't use tabs that often, but I have never seen such an issue. Sounds like a bug in LabVIEW that got fixed at some point.
It sounds weird. I don’t recall having seen that. Maybe it was in a particular version that I skipped (8.0 for instance). Also I would be really surprised if it ever happened when using terminals or locals to update a control/indicator since that updates only the control data buffer and doesn’t trigger an immediate GUI update (but schedules one for the next LabVIEW GUI maintenance run happening some 25 times a second). Using property nodes for value updates is a sure way to slow down your program and should only be done if the terminal or local is not accessible (is outside of your actual GUI VI).
A GUI cluttered with value properties, preferably also in tight loops, can make the difference between a nicely behaving application and a snail that you can’t get to do anything even with the fastest overclocked CPU on earth.
@drjdpowell wrote:
Is this true anymore? I admittedly don't use tabs that often, but I have never seen such an issue. Sounds like a bug in LabVIEW that got fixed at some point.
It was definitely true in the distant past, but likely(?) got fixed at some point. (Some of my public programs go back 15+ years!). I never did exhaustive tests in new versions.
So why do we still have the "force redraw" property for graphs? (I never used it, though).
Most of my legacy code still automatically protects against it and I won't rewrite code that is working well. 😄
@drjdpowell wrote:
@altenbach wrote:
If your front panel consists of several tab layers (example), you need to ensure that indicators get rewritten if the tab is changed. LabVIEW often optimizes front panel updates and ignores things that are currently not visible and if you later change tabs without updating, you might not see what you expect.
Is this true anymore? I admittedly don't use tabs that often, but I have never seen such an issue. Sounds like a bug in LabVIEW that got fixed at some point.
There are some update issues with subpanels.
I see that a subpanel often switches to it's default tab, while the content stays on the most recent tab. Since the tab did switch, it gets very confusing for the user.
Shady things happen when there are (a few) transparent objects (graphs). CPU time gets high when hovering the mouse over tabs, and there's little you can do about it. Of course, this is in complicated application, so there might be more factors that cause this, but making the graphs non-transparent (and ugly in my gui) fixed it.
Search LabVIEW like a graph! 