Are property nodes across applications synchronous?

[GregFreeman]

If I open an application reference from one LabVIEW application to another and set a value change property, is that a call that will be blocking until the value is truly set? I assume so, but I wanted to verify there is some sort of ack/nak under the hood before the property node returns, versus something completely asynchronous.

[mikeporter]

I don't have an answer to your specific question, but for my own edification, what are you doing where this is a concern?

Mike...

[Hooovahh]

I think it would have to be.  When a property node is used in a VI it doesn't return until that value is set, which is where the error wire can be handy for data flow.  So I'd assume this is true that a property node doesn't return until the value is set.  I don't see a reason why this wouldn't hold true if the reference happened to be in another application instance.

[GregFreeman]

We are automating some testing of built EXEs, ensuring that certain things happen when control values are set. But, in order to do so we need to verify the control value truly was set to what we expect before moving on in our script. To do this, we were going to read back the value after setting it. But, if it's asynchronous I may have to do this read in a loop with a timeout vs being able to make the assumption that if I set a value and read it back, it should already be set. Also, if it's synchronous I can probably just use the property node error to verify.

Edit: Hooovahh, I completely agree, but I just wanted to confirm.

[VItan]

---

@Hooovahh wrote:

I think it would have to be.  When a property node is used in a VI it doesn't return until that value is set, which is where the error wire can be handy for data flow.  So I'd assume this is true that a property node doesn't return until the value is set.  I don't see a reason why this wouldn't hold true if the reference happened to be in another application instance.

---

I would also want to use them in this way to be able to use dataflow on the caller.

However, I know that shared variable nodes for Network Shared Variables hosted on a different target are NOT synchronous in this sense and it's always a pain that you don't know that the value is actually written when you get your error wire from the node.

[JÞB]

Considering P-nodes are garunteed to operate top-down I reason there cannot be anything async and the node can't return before a property is set.

The belt and suspenders confirmation would be to add a property read in each node, change them to writes and benchmark the difference (you won't see one)

[VItan]

---

@JÞB wrote:

Considering P-nodes are garunteed to operate top-down I reason there cannot be anything async and the node can't return before a property is set.

The belt and suspenders confirmation would be to add a property read in each node, change them to writes and benchmark the difference (you won't see one)

---

Hmm that's a good point.

The only concern that I still thought of after that is if property nodes operating on a remote target behave differently in terms of when they consider their write to be complete - they could still operate top-down, but they might consider successfully sending the data to the target (such as just receiving a TCP ACK) to be a return without error, even if there is not an application layer message back confirming that the write has finished.

They can't know until runtime whether they will be acting on their own application or a different one, but they could be compiled to be always ready for both and conditionally decide what to do.

[GregFreeman]

---

@VItan wrote:

---

@JÞB wrote:

Considering P-nodes are garunteed to operate top-down I reason there cannot be anything async and the node can't return before a property is set.

The belt and suspenders confirmation would be to add a property read in each node, change them to writes and benchmark the difference (you won't see one)

---

Hmm that's a good point.

The only concern that I still thought of after that is if property nodes operating on a remote target behave differently in terms of when they consider their write to be complete - they could still operate top-down, but they might consider successfully sending the data to the target (such as just receiving a TCP ACK) to be a return without error, even if there is not an application layer message back confirming that the write has finished.

They can't know until runtime whether they will be acting on their own application or a different one, but they could be compiled to be always ready for both and conditionally decide what to do.

---

LabVIEW is written on top of OOP, so the open app refnum could instantiate a different class under the hood and the property node abstraction is the same, it just delegates to a different communication mechanism (TCP/IP vs setting the control explicitly via a reference when in the same application). I'm not sure this is the case, but it is a way it may be being done. You're correct that it would still be a runtime decision, however it's probably OOP and not a bunch of conditional logic in terms of case/if statements. Note however this is just me conjecturing. 

^^^ my response is relatively irrelevant to my posed question  

[GregFreeman]

Just had a thought, maybe property nodes are using the same interface under the hood regardless of the application they are communicating with (themselves, or a reference opened to another app). If this is the case, then the functionality should be identical.

[JÞB]

Vi server should be consistent but the benchmark suggested should offer insight if the data is a largish structure