LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

cRIO RT program run standlone problem

Hi,

I have an issue of deploy my RT+FPGA program into cRIO to run as standalone since my recent changing of code and labview upgrade. I am using labview 2023 Q1 64bit, cRIO 9063

The problem is when I deploy my RT program as source distribution and use VI server to start RT VI, there is an error 1003 when I try to run the VI (see below pic). The error is generated by the "Run VI" node which means labview can see the VI file in cRIO, but cannot run it (as what error 1003 means). I tried to format cRIO-> install all software->clean-> build->deploy several times, same error. In the source distribution build configuration, I also tried to uncheck all "exclusive files" option, still same problem. See details of what I have tried below the picture. I am wondering is this a software bug? Because both the depoy to memory option and the compile into standlone application option works well, just the source distribution option has problem.

gy10c_0-1692628886636.png

Tests run:

1. Use default configuration of source distribution with default exclusion files. Deploy has no errors, but error 1003 when try to run VI.

2. Uncheck all "exclude" option in source distribution configuration. During deploy labview complain" a package already deploy your application", same error 1003.

3. run the RT VI in cRIO memory, right click the VI -> deploy, run without problem.

4. change the code to run as standalone as compiled application and not use VI server. Run without problem.

Thanks!

0 Kudos
Message 1 of 5
(799 Views)

Hi gy,

 


@gy10c wrote:

4. change the code to run as standalone as compiled application and not use VI server. Run without problem.


That is the default way to run code on your cRIO, so why not go with this option?

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
0 Kudos
Message 2 of 5
(771 Views)

@GerdW wrote:

Hi gy,

 


@gy10c wrote:

4. change the code to run as standalone as compiled application and not use VI server. Run without problem.


That is the default way to run code on your cRIO, so why not go with this option?


Why not go with this option? Because labview provide other options for certain reasons, NI should know better on this.

In my usage, I am using cRIO as DAQ of my experiment. In general I have several RT VIs to run depending on what I want to measure. I need the VI server function such that I can programmable switch between these RT VIs. The source distribution method plus VI server work best for me so far. I know I can achieve similar things using the standalone application deployment, but that increase the complexity of the code, and hard for my group member to understand. I think the nature of the fact that my measurement use different RT VIs and we keep changing them and switching between them decide the standalone application is not the best option.

0 Kudos
Message 3 of 5
(758 Views)

The first LabVIEW Real-Time routine I dealt with used VI Server to start the LabVIEW Target code.  I don't remember quite how it worked, but it was very buggy and temperamental, so I replaced it with a straight built executable that (a) ran at Startup of the RT Target, and (b) that I decided to not name "startup.rtexe".

 

This worked fine until we wanted to use the same PXI box to run (when desired) a different Host linked to a different Target.  We also didn't want the Users (who knew how to run the Host routine they wanted) to have to fiddle with changing the routine that ran on the RT Target when it started up.

 

The solution (as I remember it -- these routines haven't been run in over a decade) involved creating a special Startup routine for the Target.  [This is going to sound a little kludgy, and there are probably better ways to do this, but it worked ...]  This Startup routine (let's call it "Startme.rtexe) expected, when run, to connect (via Network Streams) to the Host, who would send it the name of the desired .rtexe that we wanted to run (say "Program A.rtexe").  It would go into the Linux file system, find where the startup routine's name (currently "Startme.rtexe") was saved, replace it with the name of the routine we really wanted to run ("Program A.rtexe"), and then reboot the PXI.

 

40 seconds later, the PXI reboots, and starts running Program A.  It again connects to the Host (which "knows" to try to connect to Program A) and we are off and running. 

 

The final piece, of course, is when the RT code is ready to exit, it has to go into the Linux File system and change the Startup routine back to "Startme.rtext".

 

Yes, it is a little complicated, but it worked well.  I haven't faced this issue in over a decade -- there are probably neater ways to do this ...

 

Bob Schor  

0 Kudos
Message 4 of 5
(715 Views)

Thanks for sharing methods to walk around this issue!

Labview has the function to deploy the RT codes as source distribution, and it has benefits to simplify the codes by using the VI server. I do hope NI will make this function work as good as other options.

0 Kudos
Message 5 of 5
(696 Views)