LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

what would cause one read of a global be slower than another?

After thinking about it, I will call this issue dead.

I am not going to have the engineer go through and change all of those VI's to get an experiment involving the globals together. I think all of my issues have been addressed and the only remaining mystery was why the "Finished Late" flags could be "encouraged" by dragging a screen. Globals reads in the UI thread could have explained that.

My application is satisfactory without the globals and I am "off the [global] bandwagon" for another 5 years. Smiley Happy

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 31 of 47
(3,331 Views)
Hello again,
 
Too bad it'll go away without a good explanation.  We never like to finish issues on a "it must be something else in the code" note... but with a huge application, sometimes that's the only practical option.  It's a good think this stream started anyway, so that at least we have confirmed that variable reads don't require a UI thread swap.
 
Thanks for hanging with this one for the couple days it took to get an official answer from R&D.
 
Best Regards,
 
JLS
Best,
JLS
Sixclear
Message 32 of 47
(3,305 Views)
"the official word is that local and global variable reads do NOT cause a thread swap to the user interface thread."
 
Wow!  When did this change?




Copyright © 2004-2024 Christopher G. Relf. Some Rights Reserved. This posting is licensed under a Creative Commons Attribution 4.0 License.
Message 33 of 47
(3,287 Views)
Hello,
 
I have pinged R&D about the history of global variable behavior, and I'll post anything interesting here!
 
Best Regards,
 
JLS
Best,
JLS
Sixclear
0 Kudos
Message 34 of 47
(3,258 Views)
Hello again everyone,
 
I have some more specific information.  First, there is a thread protection mechanism to make sure that no writer of the global is changing the data while you are reading it, but this is done via a mutex, and not by going to the UI thread. However, if the Global variable panel is opened, then a message is posted to redraw the global control, and the redraw will happen in the UI thread.

For the history of the feature, before LV5, LV was single threaded, so everything happened in the UI thread. Built-in globals were added in LV3.1, so between LV3.1 and LV5, globals, like everything else, happened in the UI thread. Today, they happen in the execution system's thread. LabVIEW checks to make sure no writer is in progress, then copies the global to the local diagram's memory, then releases the lock so that a writer can have access.

Best regards and happy LabVIEW programming!

JLS

Message Edited by JLS on 04-04-2006 01:21 PM

Best,
JLS
Sixclear
Message 35 of 47
(3,237 Views)
Great conversation about globals !
- Partha ( CLD until Oct 2027 🙂 )
Message 36 of 47
(3,034 Views)
(I might mention already written stuff, i've only read 2 pages)

2 ideas that hit me while reading:
- The notifier idea isn't primarily about reading time, but reaction time. You mentioned you had lots of loops at 100 hz? Then the notifier is fast, but the question is how fast it'll react to a notifier change. The LV2/AE/FGV has a reaction time of 1 loop, a notifier can stop the loop 'early' by connecting the loop stop to timeout. Your test doesn't really simulate this.

- Have you tried setting the FGV as sub-vi priority?

/Y
G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 37 of 47
(2,243 Views)

Yamaeda wrote:
(I might mention already written stuff, i've only read 2 pages)

2 ideas that hit me while reading:
- The notifier idea isn't primarily about reading time, but reaction time. You mentioned you had lots of loops at 100 hz? Then the notifier is fast, but the question is how fast it'll react to a notifier change. The LV2/AE/FGV has a reaction time of 1 loop, a notifier can stop the loop 'early' by connecting the loop stop to timeout. Your test doesn't really simulate this.

- Have you tried setting the FGV as sub-vi priority?

/Y

 

This thread is quite old but to re-cap...

 

It was a test to see if the Globals would perform without issues.

 

LV2's (Action Engines) did not show a problem.

 

Tossing the globals and switching the the AE version solved the "finished late" problem.

 

So...

 

It was only the global reads that were exibiting the issue of "Timed Loop Finished Late".

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 38 of 47
(2,242 Views)
You've solved the problem so it's kind of beating a dead horse i assume, but just for fun: You were abit concerned about the performance, so i did a small test. Everyone talks about AE's, but how many change the priority of this vi? Maybe it's just me being dull (but then the application i'm working with currently isn't time critical) but i cant remember any tips'n'trix to make AE's Subroutines.

Well, i just tested it for fun, and a small loop of 100k reads went from 54ms (standard) to 4ms (subroutine)! I cant be the only one that's missed that. 😉

/Y
G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
Message 39 of 47
(2,213 Views)

Yamaeda wrote:
You've solved the problem so it's kind of beating a dead horse i assume, but just for fun: You were abit concerned about the performance, so i did a small test. Everyone talks about AE's, but how many change the priority of this vi? Maybe it's just me being dull (but then the application i'm working with currently isn't time critical) but i cant remember any tips'n'trix to make AE's Subroutines.

Well, i just tested it for fun, and a small loop of 100k reads went from 54ms (standard) to 4ms (subroutine)! I cant be the only one that's missed that. 😉

/Y

 

We discussed that during the Bit-Twiddler and Dictionary Challenges but if you weren't around back then it is good that you have brought that up again.

 

Setting an AE to sub-routine is good after it has been debugged IF POSSIBLE. In the simple case of a shutdown or stop falg this is fine. If the AE has any type of I/O wrapped up in it (file I/O or other asyncronous stuff) sub-routine is not an option.

 

Thank you,

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 40 of 47
(2,210 Views)
<