Why are the Pipes VIs missing on PXI Linux RT systems?

[RVallieu]

This looks like it will work

[RVallieu]

Worked, thanks for the reminder.

[RVallieu]

Experimenting - I changed the rtexe to run at start-up.  Tehn rebooted, and stopped the program.

Then ran the script file to launch the rtexe again - this time the VI appeared on the gui, but then quit.

"Startup Application:/home/lvuser/natinst/bin/startup.rtexe

Welcome to LabVIEW 19.0.1f1 

LabVIEW caught fatal signal

19.0.1f1 - Received SIGSEGV

Reason: Address not mapped to object

Attempt to reference address: 0x0x7f07c8005104

./lvrt-manuallaunch: line 6: 11673 Segmentation Fault    /usr/local/natinst/etc/init.d/lvrt-wrapper $STARTUP_PARAM $PID_LVRT_WRAPPER SUI_ENABLED"

"

When I don't set it to Run as Startup and run the bash file to launch lvrt-wrapper - it simply stops at 

"Welcome to LabVIEW Real-Time 19.0.1f1"

And doesn't open the VI front panel....odd.

[RVallieu]

Oops had a Front Panel open property in a VI - removed that.

No more Segment faults.

The RTEXE has to be set to Run as Startup for the lvrt-wrapper call to launch the VI - which is kind of annoying.  I'll have to see if I can avoid having to use that setting.  It's not looking that promising.

I can't find any information about /usr/local/natinst/labview/lvrt binary

Hm...

[rtollert]

---

@RVallieu wrote:

The RTEXE has to be set to Run as Startup for the lvrt-wrapper call to launch the VI - which is kind of annoying.  I'll have to see if I can avoid having to use that setting.  It's not looking that promising.

---

Don't bother. It won't work without it.

[RVallieu]

Well shoot. That's annoying.

I guess I will be replacing xinetd with just a LabVIEW exe to monitor the ports of interest and launch applicable code.

[RVallieu]

Had another idea - 

So I have to have the system set to Run as Start-up - fine.

I can create start-up script to run to set a flag in an INI file to False (do not run LV Code) that my code will check on start.

I can set the start-up script to run before the LVRT Daemon start-up process I believe.

Then I add code to the xinetd start-up script I created that first sets the flag to TRUE to allow the startup.exe code to run.

Thus is we ever have a power-up event the system won't just up an run the LabVIEW code and will wait for xinetd to open the connection.

I am still struggling to prove that xinetd will pass the information to/from the LabVIEW EXE - I guess that is the next step again after I prove I can get a start-up script to work to shut down my code via flag and then the shell script that xinetd will call can start it.

[rtollert]

How set in stone is an inetd-style load process again? Because it usually tends to simplify system operation, and this is moving very far away from that.

[RVallieu]

It's how all the other systems and legacy systems are set up.  This isn't that much more complicated compared to rewriting all the other system code.

[RVallieu]

Well I actually got xinetd to run a service and change the run Flag to TRUE when I connected from a TCP client on my laptop to the PXIe on the port specified in the service, now I just need to incorporate the start of the LVRT EXE into that shell script.

Then I need to see if I can pass information through the xinetd connection...  😕