LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Opening LabVIEW executable/VI on remote PC

Solved!
Go to solution

Hello Everyone ,

 

I am trying to execute either a VI or an executable of the VI on a remote PC from LV IDE on a dev PC . Ultimately the vi/executable will be called from a Compiled RT code running standalone.

 

There are 3 devices that concern this question :

 

1. Dev PC : LV IDE installed ; Windows 10

2. Remote PC : All LV dependencies such as runtime , VI server , etc installed ; Windows 10

3. NI RT Target with Linux RT

 

I am trying to achieve 3 things ; all from within LabVIEW :

 

1. Open a .vi on the Remote PC from Dev PC .

2. Open a LV executable in the same way as above 

3. Open either .vi (preferred) or LV executable on the aforementioned remote PC from a RT Target running Linux RT

 

The .vi in question performs certain processing and communicates with its host using network streams and NPSV. Hence I don't care about front panel communication . All I require is to have the vi or LV executable open when I call it from the code.

 

Point 1 and 2 is purely for learning / experimentation purpose and point 3 is how the idea will be implemented.

 

The RT target runs an HMI . I plan to call the VI during the initialization phase of the HMI . The called VI is automatically stopped when the HMI is stopped . I destroy the stream endpoints in the shutdown state of the HMI and this generates an error on the remote VI which stops it.The point of implementing this distributed computing is to offload CPU intensive calculation from the RT Target  onto the remote PC which is more powerful.

 

A side question which concerns point 3 : If I were to provide the path of the VI/Executable on the RT target via open VI reference , how do I provide the path that is comprehensible by windows ? I am unable to paste the path of the VI as it is interpreted by windows since LV RT Linux reverses the slashes.

 

Current work done :

 

Dev PC :

SP_TT_1-1617805205996.png

 

Dev PC IP : 192.168.42.8

Remore PC IP: 192.168.42.1

Both have subnet of  : 255.255.0.0

 

Test Remote.vi is a simple for loop running 100 iterations of random number generated , indexed and displayed on a graph.

 

The VI server has both the PC added to access permitted list and firewalls on both PC are disabled.

 

Thank you taking the time to read my question and I look forward to some interesting solutions ,

 

Best ,

SP

 

0 Kudos
Message 1 of 7
(1,717 Views)
Solution
Accepted by topic author SP_TT

My first question is why? Second question is what (exactly)?

 

It seems you're looking to use creative ways to achieve something. What exactly isn't clear (to me), as you mostly explain how you want to do it, not what or why.

 

If you want to trigger a VI on another PC, why not send a TCP\IP message to the exe running on that PC, and let the exe start the VI. VI Server seems like a complicated way to do that, if you get it working.

 

VI Server over applications have lots of caveats. Separate compiled code, missing subVIs, paths, VI server access rights, etc., on top of the usual networking problems (firewalls, ip ranges, etc.).

 

It's also not clear to me what you mean by "open a LV executable". Starting an exe on another PC has little to do with LabVIEW specifically. I'm not sure if it can be done nowadays.

 

If you want to open a connection to an executable, make sure the executable has the correct ini file settings:

 

[myexe]
server.app.propertiesEnabled=True
server.ole.enabled=True
server.tcp.paranoid=True
server.tcp.serviceName="My Computer\VI Server"
server.vi.callsEnabled=True
server.vi.propertiesEnabled=True
WebServer.TcpAccess="c+*"
WebServer.ViAccess="+*"
DebugServerEnabled=False
DebugServerWaitOnLaunch=False
colorHistoryItemA=00B9FF2A
server.tcp.enabled=True
server.tcp.port=3369

server.tcp.acl="290000000A000000010000001D00000003000000010000002A10000000030000000000010000000000"
server.vi.access="+myvi.vi"

 

You should be able to open a reference to myvi.vi by it's name. Open VI Reference is polymorphic, it accepts strings (the name that must be in memory) and paths (the name is used if it's in memory).

0 Kudos
Message 2 of 7
(1,702 Views)

Hello wiebe,

 

To answer the why :

The RT target isn't able to keep up with some analysis that I run on it (can't go more in detail) . It causes CPU saturation and late completion of loops. I have seen very good success by offloading this section of code onto a multicore PC . The input data is streamed to the remote PC and results are streamed back to the RT target.

 

What I am trying to do is to have the vi on the remote PC run as I power on the HMI . I don't want to have a procedure on the remote system where the VI runs automatically upon the system powerup and then it simply communicates with the HMI (this of course being absolutely sure that the vi on remote pc will ideally always behave as expected). This behaviour isn't strictly defined and it bothers me . Hence , I am trying to have a system where the HMI will ensure the code on remote PC is executed during initialization and then it communicates with the remote PC. This further helps me with handling unexpected situations and events.

 

I chose to use VI server since it seemed logical for me to deal with everything within LabVIEW. I looked into using winexe on linux and openssh but I wasn't too keen on using these options.

 

Thank you for the inputs on opening a connection to an executable and the modification of the .ini file , it is of great help and I shall try it out.

 

I shall also look into sending a string over TCP/IP to an exe . I like this idea too .

 

concerning "open a LV executable" I am referring to a built .exe of the VI , excuse my nomenclature haha.

 

Thanks for your inputs ,

Best , SP

 

P.S : Happy to see a response from a Carya employee . You guys build amazing stuff 🙂

0 Kudos
Message 3 of 7
(1,686 Views)
Solution
Accepted by topic author SP_TT

An alternate way to do this: have your exe launch on the remote PC on startup. Then you don't need to have any procedures.

 

You should be able to hide the taskbar icons and such so it runs in the background, but you might have to run it as a service depending on how your user accounts are set up.

Message 4 of 7
(1,668 Views)

@SP_TT wrote:

I chose to use VI server since it seemed logical for me to deal with everything within LabVIEW. I looked into using winexe on linux and openssh but I wasn't too keen on using these options.

 

Thank you for the inputs on opening a connection to an executable and the modification of the .ini file , it is of great help and I shall try it out.

 

I shall also look into sending a string over TCP/IP to an exe . I like this idea too .


Come to think of it, it's been a while, but I've used VI server for RT\PC communication myself. Not to start a VI, but to set control values in a VI. This gave me a 'current value' synchronization, so maybe the use case is different. 

 

You could consider network streams over raw TCP\IP. This kind of communication seems to be the reason for their existence. I think they don't really deliver in practice, as 1) re-establishing a connection disrupts the scan engine SCTL (it looses scans), and 2) it seems like a queue, but when the connection is lost, you simply loose all stacked elements. So you need a DIY queue mechanism around it.  

 

Shared variables are a mechanism that could be used. Not a fan of those either, but IIRC they do have a FIFO-ish feature that could be used.

0 Kudos
Message 5 of 7
(1,625 Views)

Thank you for your suggestion , I tried this approach and it seems to work well . I am running TCP listen on the RT target and opening the connection on the remote PC by setting the executable to run on start-up and establish the connection upon loading the executable .

0 Kudos
Message 6 of 7
(1,575 Views)

I am using the variables to set certain values used to define the acquisiton and signal processing . I don't require the FIFO behavior .

and yes , I am using network streams to send the data to the remote PC and another network stream to send the data from the PC to RT target

0 Kudos
Message 7 of 7
(1,573 Views)