LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Launching VI's dynamically in Linux RT

Solved!
Go to solution

Hi Team,

I have a program that previously ran on a Phar Lap system and is now being upgraded to a Linux RT system with LabVIEW 2024. I am using Network Streams for data transfer between Host and RT, which involves launching “network stream subVIs” dynamically. However, we are encountering issues with dynamically launching these subVIs (Error no. 1124).

I would like to know if dynamic launching of VIs is possible on Linux RT, and if so, could you provide a demonstration?

 

Normal path Error.JPG

0 Kudos
Message 1 of 11
(852 Views)
Solution
Accepted by topic author Alwin_Capsys

Pharlap is a simplified version of Windows. It can run VI built for Windows.

 

You need to re-compile your VI for Linux RT. I recommend managing your SubVI under a lvlib. 

1. In LabVIEW project explorer, add a PXI Linux RT target.

2. Create a LabVIEW Library (lvlib). Place your SubVI under this lvlib.

3. Create a new Source Distribution. Add your lvlib as the top-level library.

4. Build the source distribution and transfer the entire built library to the Linux RT target.

 

-------------------------------------------------------
Control Lead | Intelline Inc
0 Kudos
Message 2 of 11
(819 Views)

Can you describe your application a bit more?  PharLap and Linux RT are both OS's that I associate with the "Target" side of a LabVIEW Real-Time application, with the Host running, say, LabVIEW, connecting to a PXI or RIO system running Linux RT and LabVIEW RT, with Network Streams providing a communication path from Host->Target and Target->Host.

 

Is this your situation?  Could you provide a few more details about your "topology"?  There appear to be multiple processors involved, as Network Streams, running over TCP/IP, needs a Source and a Destination with separate IP addresses.  If you can create a small Demo project (maybe with a single Network Stream) and can "Save for Previous" (with LabVIEW 2019 or 2021), then compress the Project Folder by doing a right-click, "Send To:", "Compressed (zipped) folder", and attach the resulting .zip file.

 

I've developed LabVIEW-RT Host/Target routines with a single Host and single Target (both PXI/PharLap and RIO/Linux-RT) communicating over multiple Network Streams (two streams to send messages H->T and T->H, and two more to send data T->H).

 

I've also created a Many-to-One Project, but the Many were TCP/IP cameras, each of which was running as a Detached Task (using Start Asynchronous Call).

 

So tell us (and, preferably, show us) the topology you are trying to create, and we'll try to help.

 

Bob Schor

0 Kudos
Message 3 of 11
(794 Views)

Hi,

Thank you for your kind information. But I want to know more about this, but as a first step, forget about Pharlap for the time being.

 

1.I have a normal VI which is having a while loop & a Boolean in it.

2.I have saved this VI as "Sub VI 1" & transferred (to launch the VI dynamically) to a Linux RT controller using FileZilla transfer.

Alwin_Capsys_0-1717993219611.png

3. Then I have created a RT project for a Linux RT controller & there I have added a VI which programmed to launch that "Sub VI 1" dynamically.

Alwin_Capsys_1-1717995261457.png

4. When I am running this VI, it is throwing error. It showing file exists, but can't be loaded. 

 

So,

I would like to know if dynamic launching of VIs is possible on Linux RT ? If it is, how we can do? Shall we keep our VI's in any path or any particular path is there launch it dynamically?

0 Kudos
Message 4 of 11
(780 Views)

I hope I have explained all scenarios in my previous reply. Please let me know if you need any additional information.

 
0 Kudos
Message 5 of 11
(777 Views)

You can't just copy a VI from your Windows system to your realtime system anymore. In Pharlap that could work since Pharlap is for many practical purposes the same as Windows. It contains the same CPU, the entire OS API is a subset of the Windows API and therefore a VI compiled for Windows can "usually" work on Pharlap just like that.

 

Since then several things have happened. One is the introduction of "Seperate compiled Code" in the VI settings. By default LabVIEW does not anymore write any compiled code in the VI. Instead it maintains the compiled code in a compile cache on your Windows computer.

 

Second change is that your LinuxRT system is not Windows anymore. Depending on the type of cRIO it may still use an Intel compatible CPU, but it could also be an ARM CPU. Even if it uses an Intel CPU, the binary code needs to be compiled in a different way to be loadable on a Linux x64 system.

 

So you need to compile the VI explicitly for your specific target and then "deploy" it onto the system in question. Just copying it won't work because it either does not contain any binary object code (when Seperate compiled code is enabled) or even otherwise the compiled code in the VI is for Windows, not for Linux RT. Your Linux RT system can NOT read the VI diagram and compile it itself since it is only a runtime system, not a complete development system with built in compiler.

 

You will most likely want to look into static VI references. That way your VI will automatically be included in the build for your main program and be both findable and callable by your main VI. If you need for some reason an external file, your best bet is to start looking into VI libraries and then compile them to packed VI libraries for execution. You will need to build packed libraries for every single type of target you want to use this on. A packed VI library is compiled code and the one you created to run on Windows is unrecognizable gibberish for the Linux RT target.

Rolf Kalbermatter
My Blog
Message 6 of 11
(759 Views)

Hi,

Thank you for the valuable information. Additionally, could you please explain how to compile a normal VI for a Linux RT? If possible, could you also provide a demonstration for that?

 

Note: My requirement is to dynamically launch a VI stored on a Linux RT system when I press the "START" button in the Host UI.

0 Kudos
Message 7 of 11
(742 Views)
Solution
Accepted by topic author Alwin_Capsys

That is what ZYOng wrote in his answer: create a source distribution under the RT target and copy the created files to your RT system.

 

Add your VI it to the always include files and make sure that the compiled code is embedded in the VI. Then build it and copy to RT.

 

cordm_0-1718017936950.png

 

0 Kudos
Message 8 of 11
(727 Views)

Hi,

Thank you for your valuable information. I have added my Sub VI like the below added image.

Alwin_Capsys_0-1718018670171.png

 

And created source distribution like below mentioned image.

 

Alwin_Capsys_2-1718018735257.png

 

And an output got in below mentioned path.

 

"F:\29-5-2024\builds\RT Try\NI-PXIe-8861-032B7257\My Source Distribution\home\lvuser\natinst\bin\Sub VI 1".

 

Alwin_Capsys_3-1718018787596.png

 

I need to copy the obtained output to the RT target and then launch the VI dynamically as mentioned in the previous message. Is that correct? If not, please correct me.

 

0 Kudos
Message 9 of 11
(721 Views)

What you now describe sounds (to me) like a "normal" LabVIEW RT Project (and your picture of the Project file looks similar to one of mine, except I explicitly deploy the code that I want to run on my RT Target).

 

The RT Target (and code) is set to automatically run when the Target is powered up.  It initializes by trying to establish 4 Network Stream connections with the Host (to transfer Messages back and forth, and to send data streams to the Host) -- if no connection is made within 30 minutes, the Target reboots itself and tries again (because I set it to "auto-run").  Once the connection is made with the Host, the Host and Target "stay in synch" by sending Network Stream messages to each other to say "Now you go there" (both Host and Target are running Message Handler loops).

 

Once both Host and Target are running their respective Message Handler loops, all the Host needs to do is to send the Target a Network Stream Message that is interpreted as "Do Such-and-Such".  In your case, when the "Start" button is pressed on the Host, it sends the Target the message "Run this piece of code".

 

So now you need to consider how you want to Target Task (or Tasks) to be run.  Are there multiple "very independent" tasks?  Are they "steps" that are part of a single over-arching Task?  Would it be simpler to write one Target routine that carried out "separate instructions" on a common base of data or hardware, or multiple semi-independent Tasks that would be dispatched by a single "loader" routine?

 

Bob Schor  

 

 

 

 

 

  

0 Kudos
Message 10 of 11
(691 Views)