Communication between 2 VIs scenario realisation

[Pavel_47]

---

Norbert_B a écrit :

You can pass the queue reference per conntector pane. Or use named queues and each VI obtains the same queue.

Norbert

---

Ok, thanks.

Here is the version with queues that uses queue names. Sorry, I'm not aware what is "connector pane".

Anothe bizzary - when SLAVE VI is open, error is generated ... in previous version (that used global variables) there was no such issue.

[crossrulz]

---

@Daikataro wrote:

Really? I thought the reason to go FGV was specifically to avoid race conditions. How and why is that still an issue with FGV?

---

Have a look at this article I put together: A Look At Race Conditions

[Daikataro]

Quite informative indeed, I think nomenclature was the key here. I meant functional global variables in the way that is explained in this Sixclear video, which is what you have in the Action Engine section of your code. Since it was the one that best explained it, I sticked to that way of making FGVs

https://www.youtube.com/watch?v=9T1pqnGt9kU

[Norbert_B]

Reading and writing queues in a single loop to communicate both directions is possible, however it is not recommended.

What kind of error is it you see?

You can remove the loop delay queue as the dequeue by default waits for an available element. As long as there is none, dequeue will wait.

Norbert

[stevem181]

Hi Daikataro ,

> I meant functional global variables in the way that is explained in this Sixclear video

It's understandable that there is some confusion about FGVs. The nomenclature has been around a while and has mutated over time.

Before LabVIEW 3.0 there was no global variable. To achieve this functionality, someone realized they could use an uninitialized shift register to hold data and the LabVIEW 2 Functional Global Variable was born. The LV2 FGV (or just FGV) for short, only had 2 functions - Set and Get. The Set function would initialize or change the value(s), and the Get function would return the value(s).

This works fine if you only set the values in one place and read them in many places. But what happens if you want to increment a value (like in the vodeo)? You have to perform a Get, increment the value externally, then do a Set. Trouble occurs when you are doing the increment and another Set function is performed before you have updated the value with a Set. The "read-modify-write" (or "Get-modify-Set") process is not protected from external changes.

To deal with this issue and to add more features to the basic FGV structure, more functions are added. For example, you could add an Increment function that would prevent the problem outlined above. Somewhere along the line, the term Action Engine (or AE) was coined to describe an FGV type structure that has more functionality than just Set and Get. It is generally assumed, that an AE contains protection for "read-modify-write" operations, but this must be programmed.

In the LabVIEW community, the following definitions are fairly universal:

FGV - only has 2 functions - Set and Get - therefore not safe for "read-modify-write" operations

Action Engine - More than two functions (could be many) - assumed to be safe for "read-modify-write" operations

Because these structures are fundamentally very similar, they are sometimes both called FGVs.

This leads to confusion, and in my opinion, should be avoided.

steve