LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

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

Also jumping in quite late.

 

I looked at the performance numbers (delta t) on the first page(s) of this thread.

Did anyone look at the performance caused by adding more and more Globals within the VI.  

I don't mean within the sequnce frames, but elsewhere on the diagram in such a fashion as not to cause a race condition.

 

I may do it.  I am curious if the number of Globals on a diagram has an influence on speed.

0 Kudos
Message 41 of 47
(1,879 Views)

I dont know if should write this here on in a new thread, but i'm pretty sure i ran into a Global issue today.



The Global is protected while reading/writing thus locking it, right? How long is that lock? Does is last a 'wire length', just the instant it's read, or what?

I'll explain what happened.

In my inherited application (with a serious case of localitis and sequentitis), a test module 'worked', albeit slow and cumbersome. To improve performance and response i've extracted a loop with some Callback and ActiveX-updates. The test itself works noticably better.

The problem is when a subtest fails, the error handler is a error handling vi which does some IO (part of the test system and ofc part of the big looping main sequence).

This mean i now have the update loop and the error handling sub vi running with no apparent connection and i start getting timeouts from the IO. This doesn't happen in any other test (with full sequentitis) and didn't happen before, thus it must have to do with the Update loop vs error handling.

So, how long is a Global locked for, and how is that different from a AE?

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

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 42 of 47
(1,840 Views)

Yamaeda wrote:

I dont know if should write this here on in a new thread, but i'm pretty sure i ran into a Global issue today.



The Global is protected while reading/writing thus locking it, right? How long is that lock? Does is last a 'wire length', just the instant it's read, or what?

I'll explain what happened.

In my inherited application (with a serious case of localitis and sequentitis), a test module 'worked', albeit slow and cumbersome. To improve performance and response i've extracted a loop with some Callback and ActiveX-updates. The test itself works noticably better.

The problem is when a subtest fails, the error handler is a error handling vi which does some IO (part of the test system and ofc part of the big looping main sequence).

This mean i now have the update loop and the error handling sub vi running with no apparent connection and i start getting timeouts from the IO. This doesn't happen in any other test (with full sequentitis) and didn't happen before, thus it must have to do with the Update loop vs error handling.

So, how long is a Global locked for, and how is that different from a AE?

/Y

See this Nugget on Action Engines where I talked at length and provided an example where globals fail and AEs shine.

 

Ben

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

 

Thanks, i've read that excellent nugget before. I cant find the answer to the lock question in there.


I'll create some AE's tomorrow and see if it helps.

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

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 44 of 47
(1,827 Views)

Yamaeda wrote:

So, how long is a Global locked for, and how is that different from a AE?

 

A global variables knows nothing of wires. It doesn't provide locking for read-write combos. The only thing it guarantees is that at the moment you read or write a value to it, no one else will be doing the same. There's nothing preventing you from doing successive writes or successive reads, etc.

 

If I had to guess, I would say you introduced a race condition, where you have two sections of the code running in parallel (the updater and the error handler) and both seem to want to use the same thing (IO), thus causing trouble with it. You say this doesn't happen in the other tests which have sequences. That's probably because the sequences enforce execution order, thus preventing race conditions.

 

But that's just a guess. Without seeing the actual code, there's no way to tell.


___________________
Try to take over the world!
0 Kudos
Message 45 of 47
(1,807 Views)

Only the error handler does IO (since the main loop is on halt). The updater shows some information gathered by activeX and an event callback. It is the Error handler that generates a timeout.

 

The only common thing is the read of a few globals and they were written to several vi's ago, now it's only read. I write to some globals but they dont cross referrence.

 

Since i get a timeout some variable must be locked/mutexed is my interpretation.

 

/Y

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

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 46 of 47
(1,790 Views)
As I said, without a better description and the actual code, this would simply be an exercise in psychic debugging, which isn't the kind of thing I want to do in a system of such complexity.

___________________
Try to take over the world!
Message 47 of 47
(1,757 Views)