06-25-2024 04:43 AM
Hi,
I am coding a build tool that can control remote LabVIEW application instances through VI Server.
While there is a convenient method to restart LabVIEW:
I found none to simply exit/quit LabVIEW.
I've thought about doing this but remote access is disallowed:
Also, obviously the "Quit LabIEW" function does not work because it closes the current instance of LabVIEW, not the remote one through VI Server:
A workaround could be to create a VI that contains the "Quit LabVIEW" function, then run the VI from the remote application, but it is complicated in case the remote LabVIEW instance is on a different computer, possibly with a different version of LabVIEW than my builder...
Is there a "simple" way to exit a remote LabVIEW instance?
Thanks,
Raphaël.
06-25-2024 06:25 AM
I haven't tried, but this could work, assuming you have some stop-button:
06-25-2024 07:42 AM
06-26-2024 03:48 AM
@raphschru ha scritto:
Hi,
I am coding a build tool that can control remote LabVIEW application instances through VI Server.
...
A workaround could be to create a VI that contains the "Quit LabVIEW" function, then run the VI from the remote application, but it is complicated in case the remote LabVIEW instance is on a different computer, possibly with a different version of LabVIEW than my builder...
Is there a "simple" way to exit a remote LabVIEW instance?
Thanks,
Raphaël.
I recently had to run a "client" executable in LabVIEW 7.1 getting data from a "server" executable in LabVIEW 2017 - using VI Server of course.
To my big surprise, it worked well.
06-26-2024 02:35 PM
@pincpanter wrote:
I recently had to run a "client" executable in LabVIEW 7.1 getting data from a "server" executable in LabVIEW 2017 - using VI Server of course.
To my big surprise, it worked well.
The VI server protocol is backwards compatible. For the most part there were only a few minor changes in the actual protocol around 6.x to 7.x or so in that the open connection opcode was doing some more work to allow better authentication. The VI server however does version negotiation and if it determines that the remote side is only supporting an older version, it will revert back to that version for the connection. However most of the protocol has not significantly changed in all those years. There probably was also a change in the variant data format around LabVIEW 6.x to 7.x.
For the rest the only real thing that has changed is the new property and method IDs that were added in new LabVIEW versions but the existing IDs remain the same.
If you try to access a property or method ID that the remote side doesn't support you simply get an according error but that is returned by the remote side so you will have a network roundtrip before receiving that error. LabVIEW itself does not attempt to determine if the remote side supports a particular ID or not.
06-26-2024 04:22 PM
Possibly stupid idea:
Use scripting to create a VI containing a quit node, then run it:
In theory this would work on anything new enough to support scripting (8.6?) and even if it's on a different PC it wouldn't matter as you're not referencing an existing file. I don't know if LabVIEW locks out remote VI scripting the way it does with the remote menu operation though.
06-27-2024 07:28 AM
@Kyle97330 wrote:Use scripting to create a VI containing a quit node, then run it:
- My tool is an executable, so scripting is not allowed ("New VI" fails).
- Even in dev mode, the diagram of a VI opened in a remote application cannot be accessed (access denied).
So a solution could be to run an existing VI containing the Quit function:
But the VI has to be saved for the corresponding LabVIEW version, then downloaded to the remote computer.
I've already done something similar in the past, but that's quite complicated...