Shared Variable notification speed - GUI separation

[ehrlich]

Hello,

I am currently developing a LabView application that heavily relies on shared variables to separate the GUI from the core logic of the software. Some of the variables are used as triggers, meaning they are booleans which are checked by the server (core application) side for "true". If that is found, they are reset to false and some action is performed (like enqueuing a message to an internal queue).

The attached image shows such a situation where the checking of the boolean trigger is done in a loop. Now, what I found is that the same message gets enqueued multiple times. The "Save Thermal Calibration" SV is read in the loop, reset to false and read again in the next loop iteration. But apparently the SV server is too slow to notify the accessor about the changed value before the next loop iteration.

I encountered similar behaviour on some other positions in the code and so far solved them by adding a "Wait (ms)" for approx. 200 ms. However this feels quite ugly and I am wondering if this could break if at some point the load on the server app increases and the SV server becomes even slower.

Also, I am wondering if there is a way to speed up the SV server communication, especially when writing values and notifying other SV accessors about changes.

[crossrulz · Accepted solution]

Network Published Shared Variables are slow.  There is no real way around it.  And, yes, when you write a value that value is not really in the variable until the NSV Server handles it.  And when the value actually gets sent to the server can be in the 100 ms range.

If you are actually talking to another computer, I recommend changing to using a Network Stream or TCP/IP.  This way you have actual messages commanding the server what to do.

[ehrlich]

Thanks for the quick reply. I guess I have to live with the waiting then.

Currently, I am not really talking to another machine but I want to keep that option for the future (have some kind of control-app with more decision taking running somewhere else). But also, I would like to be able to "connect" multiple GUIs, controllers etc. at the same time so network streams would make everything much more complicated. Shared variables look like the best option to me.

[Ben]

Hi Ehrlich,

You have a calssic "Race Condition" that can be corrected using an Action Engine, or a a DVR.

The Nugget I linked includes an example using normal global variables. Action Engines and DVR when properly designed and used, will prevent the race condition.

SO you do NOT have to live with the limition you found nor do you need teh artificial delays that as you obesrved, only work up to a point and them you will have to fix it again.

I hope that helps,

Ben

[ehrlich]

Hello Ben,

thank's for hinting me to that, it was definitley an interesting read and a new concept for me. I'll play around with it.

Thanks!

[ehrlich]

So the way I see it, I would loose the option to have the GUI running on another machine since the VI of the Action Engine is part of the server and the client has to sit on the same machine. Or am I mistaken here?

[Ben]

It depends on how you want to implement it.

The code doing the serving on the server side can use the AE OR the Action Engine could be invoked using VI Server where the proper action can be invoked by the client side using the served AE on the server side.

Or you could work out your own method to prevent the race condition using semaphres if you want.

Ben 

[ehrlich]

Just to wrap this up and in case anyone else is having a similar problem: I solved one part of it in a rather bruther force way: The specific case of writing to a Shared Variable and reading it immediately after that. So usually, the SVE is too slow to return the new value then which is the main cause of my race conditions. The "solution" is a Sub VI that takes the new value, writes it and reads the SV until it returns the new value (The code has a few more steps for the case that the exact same value should be written).

Thanks for all the comments!

[crossrulz]

---

@ehrlich wrote:

Just to wrap this up and in case anyone else is having a similar problem: I solved one part of it in a rather bruther force way: The specific case of writing to a Shared Variable and reading it immediately after that. So usually, the SVE is too slow to return the new value then which is the main cause of my race conditions. The "solution" is a Sub VI that takes the new value, writes it and reads the SV until it returns the new value (The code has a few more steps for the case that the exact same value should be written).

Thanks for all the comments!

---

I would recommend changing that While Loop to a FOR loop.  That way you can limit how many times to try instead of possibly being stuck in an endless loop.