03-29-2006 05:42 PM
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.
Ben
03-30-2006 05:33 PM
03-31-2006 10:18 AM
04-03-2006 01:35 PM
04-04-2006 01:20 PM - edited 04-04-2006 01:20 PM
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
04-24-2007 06:05 AM
04-26-2010 10:48 AM
04-26-2010 10:54 AM
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
04-26-2010 11:30 AM
04-26-2010 11:38 AM
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