Jump to content

Speed difference between reading from and writing to property nodes


Recommended Posts

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:

post-21933-0-64065600-1306498955_thumb.j

Checking the Defer Update before writing false.

post-21933-0-38302000-1306499055_thumb.j

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 by ErikTheRed
Link to comment

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 :

post-7452-0-08525400-1306501215_thumb.pn

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

  • Like 1
Link to comment

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 :

post-7452-0-08525400-1306501215_thumb.pn

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

Link to comment

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 :

post-7452-0-10478500-1306506031_thumb.pn

  • Like 1
Link to comment

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 :

post-7452-0-10478500-1306506031_thumb.pn

Link to comment

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 !

post-9691-0-76035400-1306759662_thumb.pn

Link to comment

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 ;)

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.