Speed difference between reading from and writing to property nodes

[ErikTheRed]

In my front panel, I defer updates frequently to prevent piecemeal updates. I have a subVI to defer/un-defer updates, sometimes when the VI comes to this piece of code, updates have NOT been deferred (in other pieces of code). Is it more efficient and faster to read from the 'DeferPanUpdts' property and if it is false, already, skip the rest of the code? Or is it better to just blindly write false to the 'DeferPanUpdts' property... Blindly writing false will cause a single Write action, checking would cause always a single Read, and sometimes a Write. (sometimes is likely a decent percentage of the time...).

Images below:

Checking the Defer Update before writing false.

Defer SubVI.

Thanks!

EDIT: I realize this might better be posted in the GUI sub forum... if a moderator could move it, that would be fantastic, if not... please accept my apologies for posting in the wrong forum, I question whether I should repost...

Edited May 27, 2011 by ErikTheRed

[Antoine Chalons]

EDIT: I realize this might better be posted in the GUI sub forum... if a moderator could move it, that would be fantastic, if not... please accept my apologies for posting in the wrong forum, I question whether I should repost...

Don't report, simply report your message to moderator and ask for the post to be moved.

Regarding your question, here's my suggestion :

When you start your application, put the panel ref into an action engine (init case) and then where-ever when-ever in the application call the action engine to set which-ever state (deferred / un-deferred) you want.

Hope this helps

[ErikTheRed]

Thanks for the response.

I'm only slightly confused on what an action engine is... is this a state machine or an event structure?

The program that this is inside is quite complicated with quite a few loops, so it's almost impossible to utilize shift registers since other loops need to defer updates as well. (Would this work if I added another event loop?)

Also, just trying to understand your provided diagram... is the while loop that you've provided, that is a one-time-run (true on the stop terminal), made to keep those shift registers populated within a subVI? Does this require any settings to work?

Thanks again!

Don't report, simply report your message to moderator and ask for the post to be moved.

Regarding your question, here's my suggestion :

When you start your application, put the panel ref into an action engine (init case) and then where-ever when-ever in the application call the action engine to set which-ever state (deferred / un-deferred) you want.

Hope this helps

[Antoine Chalons]

All right, let's start from the beginning, what I call an action engine is also sometimes called a FGV (functional global variable) or USR (un-initialized shift register) or LV2 global, if you search the forum for these terms you'll find clear definitions for them.

But basically, the block diagram I posted is a subVI that you call once at the initialization of you application in "init" mode and feed it with the panel ref of your main front panel (here I'm assuming you have mono-front panel user interface), then the shift register will keep that panel ref during all the execution of your application AND it will also retain the last state you set, therefore from anywhere in the application you can call again this subVI to set the defer panel update ON or OFF and the change will be made only when necessary.

Here's a hint :

[ErikTheRed]

Thank you, this is extremely helpful!

All right, let's start from the beginning, what I call an action engine is also sometimes called a FGV (functional global variable) or USR (un-initialized shift register) or LV2 global, if you search the forum for these terms you'll find clear definitions for them.

But basically, the block diagram I posted is a subVI that you call once at the initialization of you application in "init" mode and feed it with the panel ref of your main front panel (here I'm assuming you have mono-front panel user interface), then the shift register will keep that panel ref during all the execution of your application AND it will also retain the last state you set, therefore from anywhere in the application you can call again this subVI to set the defer panel update ON or OFF and the change will be made only when necessary.

Here's a hint :

[hugo_fr]

I usually use this kind of code for managing the 'Defer Panel Update' property in software with multiple UI windows.

It allows a subVI that perform updates on a given object (such as Trees) to set the 'Defer Panel Update' to TRUE if necessary in the Setup process, then restore the original value in the Clean up process.

Important notice about the Defer Panel Update : if you set it FALSE, it will trig LabVIEW to redraw Front Panel objects immediately, even if it was previously set to FALSE !

[Antoine Chalons]

I usually use this kind of code for managing the 'Defer Panel Update' property in software with multiple UI windows.

It allows a subVI that perform updates on a given object (such as Trees) to set the 'Defer Panel Update' to TRUE if necessary in the Setup process, then restore the original value in the Clean up process.

Important notice about the Defer Panel Update : if you set it FALSE, it will trig LabVIEW to redraw Front Panel objects immediately, even if it was previously set to FALSE !

Hi Hugo,

I see one advantage for the solution I posted, it doesn't need to read (via property node) the current state - deferred or not - because the current state is held in the shift register. And like your solution it only sets the state if necessary.

It might not be very important but my solution only opens the panel ref once and closes it when the App is shut down