LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

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

Hi All,

After some trouble shooting the engineer I was working with looked at me and said "WHY?"

"Why questions are always the hardest Q's to answer.

Warning! I am going to be asking about normal LV globals NOT LV2 globals. Using LV 7.1.

I have to admit that I have very little experience using globals and this is probably my first attempt to use them.

I am using them in this application because I found that a simple boolean global can be read a lot faster than the best LV2 version I could think of. In my application, the "Stop Boolean" global is only written one place but read in about 250 sepearte loops to indicate it is time to stop.

About 30 of those loops are timed loops and we noticed that two of the timed loops were asserting the "Finished Late" flag. The actual finish time was about 1 msec after what was expected.

We found that if we ran the application without the two loops that were flaging the "Finished Late", none of the other loops had problems. If we added either of the two loops that were finishing late, they would again finish late but the others never had trouble.

Running either of the two loops by themselves never give an error. Add any of the other non-late-finishers, BINGO we start seeing the finished late again. Oh bother!

I removed ALL of the code inside the loops that finished late except the read from the global boolean and still the loops finish late.

At this point I had to question the global!

I replaced the global boolean read with a LV2 style boolean and the finished late errors stopped! ohmy.gif

We could not make (dragging a window around on the desktop helped produce the error) that loop to finish late as long as it was using the LV2.

I restored the global boolean and >>>> Finished late!

More background info.

The application dynamically loads all the VI's required to operate. A timed loop is used in every loaded module. This is how I am quickly including and excluding the offending code. Continuing....

Changing the order in which the modules (timed loops) are loaded did not make a difference.

So.....

Why would 2 timed loops always take longer to read a global boolean than any of the other timed loops?

Do gloabl reads have to execute in the UI thread?

Thank you for reading,

Ben
Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 1 of 47
(8,333 Views)
Ben,

Have you (for the sake of testing) tried using a Queue as a variable.  It's been noted recently that Queues as variables (only ever containing one element with the queue name identifying the variable) are quick.  This might get around the thread issue (if there is one).

On another note: I presume the contents of the multiple loops (late finishers versus not late finishers) are different?

Interesting.

Shane.
Using LV 6.1 and 8.2.1 on W2k (SP4) and WXP (SP2)
Message 2 of 47
(8,291 Views)

'After some trouble shooting the engineer '

Hi Ben

I appriciate much of the advice you give us on this group, but come on, shooting the engineer just because your 1 ms out on a couple of loops is a bit drastic..

Sorry I can't help with your problem, but please spare the life of your poor engineers.

Ian

Message 3 of 47
(8,279 Views)
Hi Shane,
 
I use queues to pass data between all of those loops. They give better performance that my best round-robbin LV2 buffers.
 
The Globals in question is just a boolean that is false while I am running anf true when it is time to stop.
 
The queue does not seem to suit that use case well.
 
"the contents of the multiple loops (late finishers versus not late finishers) are different?"
 
At the tail end of my troubleshooting, the offending loops ONLY had the global and they STILL finished late. Smiley Mad
 
Ben
Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 4 of 47
(8,280 Views)
"

Sorry I can't help with your problem, but please spare the life of your poor engineers.

Ian

"

I'll try!

Actually the engineer was looking for me to help correct the problem. He just had to sit back and let me come up with the answers.

Still curious,

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 5 of 47
(8,273 Views)
Hi Ben.  I cobbled together what I think you described.  I wasn't able to reproduce the problem
unless I delayed the processing in the loops such that they were running too long anyway. 
All of the loops seem to stop within about 0.01 mS of each other.  Maybe something
else like a background process is delaying everything?  Do the loops ever finish late at times
other than shutdown?

An interesting problem.

Matt
Message 6 of 47
(8,259 Views)

Hi Matt!

"unless I delayed the processing in the loops such that they were running too long anyway. "

That is exactly my issue. The reading from the global boolean is taking too much time. My loops are running at 100 HZ.

I am not sure if your example would catch the late flags. I am using an "Error Logger" to track these errors.

The best case failures indicate the loops are finishing 1 msec late. The worse case indicates 56 msec!

Ben

BTW: CPU is not an issue. I am running on a dual processor with one using 75% and the other using 50%.

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 7 of 47
(8,242 Views)

Ben,

I dunno if access to globals requires switching to a UI thread, but it sounds like a reasonable theory.  I do recall that timed loops are given boosted priority -- perhaps also their own thread?  If so, there may well need to be some sort of context-switching when accessing a global.

Still, it's hard to account for 10's of msec extra for timed loops over the other standard loops.  Does every vi with a global on its block diagram reserve a separate spot in memory for a copy of the data?  If so, there must be a process "under the hood" responsible for dispatching the updated value to all of the global variable instances.   Hmmmm.  The train of thought isn't leading me anywhere...

Along the same lines as Shane's queue idea, you might also consider trying either a Notifier or perhaps even a lowly Occurrence.  I have tended to keep using Occurrences for very simple "HALT RIGHT NOW" situations.  Because they're so simplistic, I've figured them to have lower overhead than Notifiers or Queues, though I haven't done any careful benchmarking.  I only know they were easily good for several kHz under RT with a sub-GHz CPU.

Let us know if/when/how you fix this one.

-Kevin P.

 

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
Message 8 of 47
(8,224 Views)

"A wise man goith into his storehouse and bringith forth treasures both old and new." (Paraphrased Proverb)

"There is wisdom in a multitude of counsellors." (Proverbs)

"even a lowly Occurrence.  "

Wonderful thought Kevin!

I will investigate further and update.

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 9 of 47
(8,212 Views)



Ben wrote:

"There is wisdom in a multitude of counsellors." (Proverbs)

Actually, the correct quote should be along the lines of "without cunning the people will fall and deliverance will be found in a multitude of counselors" (and yes, I know the original).


___________________
Try to take over the world!
Message 10 of 47
(8,198 Views)