error 1000 in VI Server, but no VI editing - Why?

[comrade]

Hello,

after trying to stop a WHILE-loop in a subVI via a stop-button of the calling VI I have come across the "famous" error 1000. What I don't understand is the following:
As you can see from the example VIs attached I DO NOT EDIT the calling VI that's opened in the SubVI via a strictly typed VI reference. I merely read out an indicator of that VI. My conclusion is, that no running VI can be opened with a strictly typed VI reference, which is not exactly what is said in the KnowledgeBase article for "Common VI Server Errors" under
http://digital.ni.com/public.nsf/websearch/E1B8CA0B546A803486256A33005AF221?OpenDocument

*** quote starts here ***

"The state of a VI reflects whether the VI is reserved for running. When a VI is reserved for running (or is running), you cannot edit it. Make Current Values Default is an example of a method that edits a VI because it actually changes the composition of the VI. Set Control Value is an example of a method that does not edit the VI because the VI itself does not change when a control value changes. All strictly-typed references reserve the VI for running. Therefore, anytime you use a Call By Reference Node, the VI is reserved for running. You must close this reference before you can edit the VI. Otherwise, you will receive error 1000."

*** quote ends here ***

Again - I am in no way editing the VI, I merely want to use the efficient CALL BY REFERENCE (CBR) node for the strictly typed VI reference to directly read from the indicator. Is the fact, that generally I could also use a CBR node to WRITE data to the control (which could actually be a way of editing the referenced VI) possibly the reason and therefore generally the CBR node is considered to be an attempt to edit a VI?

I know the workarounds using the Set/Get Control Value methods for the INVOKE node, however this takes up much more space on the block diagram plus I have to reset latching booleans because the Get Control Value method doesn't cause the Boolean to return to default state. I am asking mor for a bit of understanding, why I can't use the CBR node here, as I am not editing anything in the VI.

[TCPlomp]

Could you show some code?
Maybe you need to call the VI reentrant?

Ton

[comrade]

oops - I know I did attach two VIs, may be they didn't make it over the "Preview Post" function...

[TCPlomp]

Hello Comrade,

Preview has that nasty habit...

But what happens is totally normal.
You can't create a typed vi reference to an already running VI, when loading a type def'd VI the compiler will load this VI ready to run (or edit) but it can't because it is already running...
Only reentrancy will work (but that is not what you want)
You have two options:

1. Feed the reference, just like numerisch
2. Open a non strict type VI and use Set value (variant) to stop the calling VI

Ton

[TCPlomp]

Here's some more info:
LV help
'The VI must be executable as a subVI. That is, it cannot be active as a top-level VI unless the VI is reentrant.'

Ton

[comrade]

Thank you very much for your help, TonP!

I now used the "usual" way with "Open VI Ref" and the "Get Ctrl Value". When choosing "no names" for the invoke node options it doesn't even take up that much space 😉

Stopping the running VI in order to use a typed VI ref is not useful here, as the running VI is intended to be the "master" over continuing or stopping the subVIs WHILE-loop and must not exit to be able to accomplish that.