08-09-2026 03:22 AM - edited 08-09-2026 03:25 AM
I thought quite a bit on what you wrote, also on writing this comment, which I hope wouldnt be overly disappointing.
I try to phrase clear and direct questions. After rereading my question I think that if you want, you could understand the question: I'd like to know which reference (ThisContext? Runstate.something?) can I pass to LabVIEW and use to r/w locals of the sequence no matter that the VI - which I used to receive the reference - is not running anymore.
I dont understand why do you need to go assumptions. My question was direct and I'm able to evaluate the risks myself. And what is the capital red DANGER we are talking about here exactly? That I'm planning to r/w variables of a running process? We - developers - all do it everyday! We do it with FGVs, Queues, Property nodes, Local variables, file operations, and in many other ways. How reading/writing variables of a TS sequence would be any better/worse, more/less dangerous than writing variables of any processes. Race conditions could occur? Yes. Things can go bad? Yes, but we still do it because we know how to do it properly.
I'm glad that you added a bit of a personal note to your comment. Here is my part: when saying "we know that you are under pressure", or "its against my personal policy to answer this question (and btw I dont know the answer anyways)"... yeah, thats condescending even if it was not meant to be. And when I read that "I wont be responsible"... Seriously?
While my intention is not to offend anybody the risk is there. Today I take it, as it is a risk coming from honest communication.
If you happen to know the answer to my original question, I'd be more than happy to get it.
08-10-2026 09:14 AM - edited 08-10-2026 09:31 AM
Hey there. I'll try to address your questions:
I'd like to know which reference (ThisContext? Runstate.something?) can I pass to LabVIEW and use to r/w locals of the sequence no matter that the VI - which I used to receive the reference - is not running anymore.
You pass the literal reference of the local var, file global, station global, temporary global, or any other PropertyObject.
I'm attaching a demo of this. It's in TS/LV 2021, which is the oldest version I have on hand.
On the VI that you call from TestStand, you'll need a reference of class PropertyObject on the front panel.
There's probably a less cumbersome way to create a PropertyObject ActiveX ref on the front panel, but what I did was:
Connect the ref to a terminal on the connector pane.
Call the VI from TestStand. In the Step Settings, set the value of the ref on the VI front panel to &LocalOrFileGlobal, the ampersand being the address operator, or colloquially, the "reference to" operator.
In the VI, use an invoke node with the "GetValNumeric" method, or the appropriate method for the data type of the local or file global.
What is the capital red DANGER we are talking about here exactly?
I placed "WARNING" there, because in my opinion, both transmitting and receiving data with a running VI via PropertyObject values has a few pitfalls and I don't think it's the best method.
I believe you when you say that you know how to do it properly, but for the sake of keeping my prior explanation as succinct as possible, I decided not to go there.
When one gives advice in the forums, one also has to consider that possibly thousands of people will read this in the coming years, including bots who will regurgitate whatever is written.
There's no way I can know the reader's level of expertise. (I'm considering a broad audience, not just you.)
You probably know this, but it's like using global variables in LabVIEW instead of using something more appropriate like queues, something with intrinsic synchronization.
You'll have to implement synchronization somehow with a semaphore/mutex or something similar, and you'll also have to consider what happens when a value is potentially dropped because the producer and consumer of data are publishing and polling at different rates.
Obviously, how this is best implemented depends on what you're trying to do.
Apologies if I'm stating the obvious. I just don't think it's a good idea, but do what you think is appropriate for your use case.
Jim
08-11-2026 04:11 AM - edited 08-11-2026 04:22 AM
Thanks for keep responding to this question, pls keep up the good work.
The files you attached don't answer the question I tried to ask, I could do this earlier. The problem I have is that once the VI which is called from TS finishes its execution. I modified your VI to show the my true problem:
1984_0-1786438539328.png
This VI does almost exactly the same as your original except that it stores the reference in an FGV. When running from TS this VI displays the variable name and 123.0000 as expected.
So now the reference is in an FGV, I assume that I can use it in other VIs. So while while the same sequence is still running, I call the following VI:
1984_1-1786438746268.png
As you see on the probe value, the reference is the same as what we stored, but nonetheless the VI returns an error and can't retrieve neither the variable name nor its value.
So this is my problem I try to find a solution for: I can only use the reference only in the VI I called from TS and once that it finished its execution the reference doesnt seem to be valid anymore, no matter that the sequence is still running.
Proof: If I keep the original VI running and call the second VI then the second VI - which previously thrown error1 - can display the variable name and value.
1984_0-1786439758087.png
I have attached the FGV for your reference although the internals wont be any surprize.