NI Linux Real-Time Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

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

New Tact on this.

 

We moved to Linux CentOS 7.6

 

I have compiled LabVIEW code into .SO shared library so that I can call a VI with C Code.

This allows me to launch separate LabVIEW processes quite nicely.

 

Where I am still struggling is getting that damn xinetd STDIN/STDOUT connection through to the LabVIEW code.

 

My task is to demo this very simple system, and not even have the LabVIEW code do anything difficult. Maybe in response to Telnet input, Echo back + Reply #

 

My sticking point remains the xinetd connection into the LV Code - I am thinking it should be simeple for the C code to pass the FD (file descriptor) to LabVIEW Code on Call, passing in as params - but I am no C programmer to know how to get that info.

Ryan Vallieu CLA, CLED
Senior Systems Analyst II
NASA Ames Research Center
0 Kudos
Message 31 of 41
(238 Views)

Have you tried just running Read From Pipe.vi and Write To Pipe.vi with hardcoded file descriptors?

  • Read From Pipe: use file descriptor=0
  • Write To Pipe.vi: use file descriptor=1
0 Kudos
Message 32 of 41
(229 Views)

Gonna try that this morning.  First I have to install the Linux Utility VIs to my Linux Desktop system - I am guessing I can just copy them to ../LabVIEW#/Addons  - note my system is disconnected from the internet and must remain that way for govt security reasons.

EDIT: NVM - PIPE VIs are installed on this instance of LabVIEW on Linux Desktop.

 

What is mentally messing me up is I think I would need the STDIN fp* from the C process that started the LabVIEW process?  That's what seems to make the most sense to me?

 

So in the C caller I'd maybe have to have the C program pass the STDIN to the LV process through a Parameter - maybe Int32, even though we know it is zero?

 

My C LabVIEW caller would need

 

#include stdio.h

#include unistd.h

 

so I could use STDIN callout and then pass as the param to the LabVIEW VI in the .SO

 

I'll muck around and try both - I can't believe I am the first person to try this.  Guess I am going to learn C whether I like it or not!  😄

Ryan Vallieu CLA, CLED
Senior Systems Analyst II
NASA Ames Research Center
0 Kudos
Message 33 of 41
(224 Views)

You're overthinking this. If you really are spawning each instance in a separate process, you won't need to pass anything additional in. Just use 0 and 1.

0 Kudos
Message 34 of 41
(214 Views)

YES!

 

I am able to read the STDIN from the port through code launched by xinetd by simply using the Read Pipe VI with 0 input.

 

The Write is another story, I can not just simply wire a 1 to the input of the Write.  According to the Help on that VI the pipe must first be opened as a Write.  I can not open the block diagram of the Open Pipe VI to see what I would need to change to make this work.  

 

I'll try the /proc/self/fd/1 Path  into the Open Pipe VI to get the FD for STDOUT as you suggested earlier in the thread.

Ryan Vallieu CLA, CLED
Senior Systems Analyst II
NASA Ames Research Center
0 Kudos
Message 35 of 41
(203 Views)

/proc/self/fd/1 for the filepath into the Open Pipe.vi did not work.

 

Trying the binary Write to File instead of the Open Pipe.vi and Write Pipe.vi

Ryan Vallieu CLA, CLED
Senior Systems Analyst II
NASA Ames Research Center
0 Kudos
Message 36 of 41
(196 Views)

With the Open Pipe.vi - it gave Error 6 when trying /proc/sef/fd/1

 

Shouldn't be because there is not a reader, one would hope, since xinetd is "reading" the pipe.

 

https://forums.ni.com/t5/Linux-Users/error-6-open-pipe/gpm-p/3438746

Ryan Vallieu CLA, CLED
Senior Systems Analyst II
NASA Ames Research Center
0 Kudos
Message 37 of 41
(192 Views)

/proc/sef/fd/1 did not work for Write Binary File - Error 6 at Open File.

 

Ryan Vallieu CLA, CLED
Senior Systems Analyst II
NASA Ames Research Center
0 Kudos
Message 38 of 41
(189 Views)

If you don't have fd=1 open, that's probably on you.

 

2020-09-30-141803_706x618_scrot.png

 

 

Guess I am going to learn C whether I like it or not!  😄

I'm going to go out on a limb here and say

 

  1. This is not a good way to learn C.
  2. You're actually learning Unix, not C. In particular, you'd go through this particular school of hard knocks if you were writing Perl CGI scripts.

/proc/self/fd just mirrors what file descriptors you already have open. If fd=1 isn't open, the most likely explanation is that xinetd isn't opening it for you, for whatever reason. (Or I guess LabVIEW might have already closed it, though I don't see how.)

0 Kudos
Message 39 of 41
(179 Views)

Binary Write did not work either.

 

xinetd is supposed to do the redirect of the STDOUT to the socket...so not sure why there wouldn't be a listener already created.  Hmm.

Ryan Vallieu CLA, CLED
Senior Systems Analyst II
NASA Ames Research Center
0 Kudos
Message 40 of 41
(171 Views)