09-25-2020 05:35 PM
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.
09-28-2020 10:00 AM
Have you tried just running Read From Pipe.vi and Write To Pipe.vi with hardcoded file descriptors?
09-28-2020 11:01 AM - edited 09-28-2020 11:09 AM
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! 😄
09-28-2020 06:40 PM
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.
09-30-2020 11:41 AM - edited 09-30-2020 11:48 AM
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.
09-30-2020 11:58 AM
/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
09-30-2020 12:48 PM
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
09-30-2020 01:02 PM
/proc/sef/fd/1 did not work for Write Binary File - Error 6 at Open File.
09-30-2020 02:33 PM
If you don't have fd=1 open, that's probably on you.
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
/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.)
09-30-2020 03:30 PM
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.