LabVIEW RT - Linux RT PXI - xinetd -System.in and System.out

[Ryan Vallieu]

I am trying to figure out how to get LabVIEW EXE running on NI Linux RT for PXI 2019 to communicate over System.in and System.out when it is called by xinetd so that the Client that connected can communicate to the LabVIEW exe.

I don't have the Pipes VIs on the palette on the RT VI functions palette.  Maybe LabVIEW RT doesn't realize it is running on Linux.

Is there a simple way to accomplish this that I just don't know about from my limited Linux experience?

[Ryan Vallieu]

This has since changed.

I am now compiling my LabVIEW code into .SO library and calling that from C as apparently I can only get xinetd to launch one instance of LabVIEW, the system must be set to run-at start-up, etc. etc.

I can call any number of LabVIEW VIs from .SO through a C call and have them happily chugging away in their own app spaces.

What I am missing still is how to get the STDIN/STDOUT through to the LabVIEW program.  I suspect if I was better at C this would be easy (easier?). Just trying out a simple demo at first so the LabVIEW code doesn't need to be a full-blown architecture.  I just need to get that damn "pipe" or File Descriptor.

[Rolf Kalbermatter]

On 9/26/2020 at 12:43 AM, Ryan Vallieu said:

This has since changed.

I am now compiling my LabVIEW code into .SO library and calling that from C as apparently I can only get xinetd to launch one instance of LabVIEW, the system must be set to run-at start-up, etc. etc.

I can call any number of LabVIEW VIs from .SO through a C call and have them happily chugging away in their own app spaces.

What I am missing still is how to get the STDIN/STDOUT through to the LabVIEW program.  I suspect if I was better at C this would be easy (easier?). Just trying out a simple demo at first so the LabVIEW code doesn't need to be a full-blown architecture.  I just need to get that damn "pipe" or File Descriptor.

A bit of a wild guess but there is a function 

MgErr FNewRefNum(Path path, File fd, LVRefNum *refNumPtr)

exported by the LabVIEW kernel which takes a File, a Path (which could be an empty path as the File IO functions don't really use it themselves) and returns a file refnum that you can then use with the standard File IO functions.

Now File is a LabVIEW private datatype but under Windows it is really simply a HANDLE and under Linux and MacOSX 64-bit it is a FILE*. So if you can manage to map your stdio fd somehow to a FILE* using some libc functions

FILE *file = fdopen(fd, "w");

you might just be lucky enough to turn your stdio file descriptor into a LabVIEW refnum that the normal LabVIEW Read File and Write File nodes can use.

Also note that libc exports actually stdin, stdout and stderr as predefined FILE* handles for the specifc standard IO file descriptors so you may not even have to do the fdopen() call above.

After you are done with it you should most likely not just call LabVIEW's Close File on the refnum as it assumes that the file descriptor is a real FILE* and simply calls fclose() on it. Maybe that is ok depending how you mapped the file descriptor to the FILE* but otherwise just use FDisposeRefNum(LVRfNum refnum) on the refnum and do whatever you need to do to undo the file desriptor mapping.

 

Edited September 29, 2020 by Rolf Kalbermatter

[Ryan Vallieu]

Solution:

Since we need xinetd to be able to open N number of LabVIEW VIs as this is how the legacy system is configured and the "institution" doesn't want to change that at this point, I had to figure out how to make this work.

Compiled my test VI into a .SO Shared Object library on my PXIe-8135 running Cent OS 7.6.  Selected Advanced options in Build to use EMBEDDED version of run-time engine - doesn't require a GUI for the code to run.

Wrote simple c code to launch the LabVIEW VI.

Installed and configured xinetd to launch C code that launches LabVIEW code. Used the package: xinetd-2.3.15-14.el7.x86_64.rpm

LabVIEW Test VI uses LabVIEW Linux Pipe VIs with hard coded 0 (STDIN) and 1 (STDOUT) to communicate over the socket.  As explained basically here: http://www.troubleshooters.com/codecorn/sockets/

Result is that the LabVIEW code runs and can communicate over the Socket connection through the Pipe VIs.  It turned out to be easier on the LabVIEW side than I expected. Hard coding the 0 and 1 into the Read from Pipe.vi and Write to Pipe.vi worked.  

 

Edited October 1, 2020 by Ryan Vallieu