LabVIEW
How to share single FGV between many LabVIEW projects
Nothing at VI level will be shared between LabVIEW instances.
So normal FGV, global, Vi references, queues, etc. won't solve your problem.
You could use a shared variable (LV), a shared file (LV), a memory mapped file (Windows), a (named) pipe (Windows).
The moment you replace ta FGV for another solution, you will get race conditions. A VI prevents this, as a non-reentrant VI can only execute once. But if you read, modify write these global resources, chances are one read, modify, write will overwrite another read, modify, write (readA, readB, modifyA, modifyB, writeA, writeB, writeA will be lost). Be warned, you somehow need to solve this.
Search LabVIEW like a graph!
@Jan_Nousiainen_8467 wrote:
Ok thank you, I think I will implement something with datasockets instead 🙂
Datasocket, shared variable... The major difference is datasocket is obsolete. AFAIK, you'll be using the same mechanism.
The race condition warning still applies. If you read, modify, write in parallel, you're in trouble.
A way out would be to make the writes buffer (not a shared variable fan, but I think they can do that), and make a server that collects the writes. Then you'd have n writers, 1 reader.
A network stream might be more convenient for that.
@Jan_Nousiainen_8467 wrote:
Got the datasocket implementation mostly working already, phew.
Not sure what happens if two or more drivers decide to write to log precicely at the same moment. There are multiple writers to common socket, only one reader, data is plain strings. What can go wrong in such a situation in practice?
As I understand, "writing to the log" means reading a string, add an entry to it, and writing it. So:
Device A reads ""
Device A Adds "Device A" -> "Device A"
Device A writes "Device A"
Device B reads "Device A"
Device B Adds "Device B" -> "Device A Device B"
Device B writes "Device A Device B"
No problem. But the two devices are not in any way synchronized. So this might happen:
Device A reads ""
Device B reads ""
Device A Adds "Device A" -> "Device A"
Device B Adds "Device B" -> "Device B"
Device A writes "Device A"
Device B writes "Device B"
That's only one possibility. Any time a read\write crosses another, you'll loose data.
You'll get the same indeterministic behavior as a VI race condition:
Which might be unlikely to happen, until it changes to actually do this:
Now you're in trouble.
What extra does the buffering implementation require?
IIRC, you can tell a shared variable to enqueue all written values (in stead of keep only the current value). This is only a solution when you decide to have n writes, one reader.
Honestly, I'd go for a network stream if that's what you want. It's what network streams are actually designed to do.
For documentations sake, this page explains what you are seeing and why:
https://www.ni.com/en/support/documentation/supplemental/13/how-teststand-interacts-with-labview-app...
If you didn't call the VI's in TestStand using a "Project Path", even though they are in a project, they would share the same application space.Instead you can just specify the vi path, and you'd be good to go.
@ShockHouse wrote:
If you didn't call the VI's in TestStand using a "Project Path", even though they are in a project, they would share the same application space.Instead you can just specify the vi path, and you'd be good to go.
That would be the simplest solution...
Each project runs in it's own context. It is possible to call a VI in another context:
The tricky part is figuring out the application reference.
@paul_a_cardinale wrote:
Each project runs in it's own context. It is possible to call a VI in another context:
The tricky part is figuring out the application reference.
What I understand from ShockHouse is that does happen if you define the project path, but not if you don't.
Anyway, my TestStand experience dates back to TestExecutive, so I'll stick to the LabVIEW part.
