From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Write and Read VIs need to work at 2 locations


@govindsankar wrote:

But from what I have heard it is not possible. The only way to do that is to connect the first VI to the second VI, but then they cant be in 2 different cases. So can it be done by any method or this is the only way to do it.


Parallel VIs need by reference objects if they need to asynchronously access the data. Everything we said about loops is the same for parallelly executed VIs.

 

At this level, you can thing of the object (the instantiated class) as a cluster. So splitting the cluster in two wires will get you two clusters. Instantiating the cluster twice will also get you two objects.

 

OO is not the problem here, nor the solution. OO doesn't change anything about the wireflow paradigm that LabVIEW uses.

 

If you want or (doubtfully) need asynchronous access, you do need to do things by reference, or by some sort of buffer, like a FGV, Global, 1 elm. queue, etc..

 

It depends highly on your exact situation what would fit best. We don't have enough information.

 

Lets get back to the beginning of your remark:

 


@govindsankar wrote:

I have two sub VIs and both these VIs work in the main VI. One VI accepts data and other VI at another position in the MAIN VI maybe in a different case need to ouptut the data that other VI accepted.


So why can't the writer send the (measurement) data as a scaler object? This can be done in a (user) event, a queue, a channel wire, or even by filling a FGV\buffer. The main can then wait for the queue elements, events, or poll the buffer at it's own pace.

 

To me, this reflects what actually happens much better then any by reference solution.

0 Kudos
Message 11 of 11
(167 Views)