LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Trying to Follow White Paper - Running a LabVIEW Application on Linux Without a Graphical User Interface

Solved!
Go to solution
Highlighted

Playing around further - I was able to get the C Code that takes over the port monitoring from xinetd to pass the SocketFD to LabVIEW - but this is where it falls apart, as expected.

 

I have no valid way of using that FD (file descriptor) to write and read from the port.

 

The PipeVIs do not work with the FD.

 

I tried just using the making a simple .so for the C write function that uses the FD.  That appears to work, it compiles and I can access it with a Library Interface Node, but the FD trip from the main C to LabVIEW, then LabVIEW to C write() loses the "context" of the FD connection to the memory descriptor table I suppose.

 

Although the write() called by the LabVIEW Library Interface Node does return it wrote out the correct number of bytes and not a -1, nothing shows up on on the client side.  I'm not sure WHERE the string I wrote ended up, but it wasn't on the SocketFD.  😄

 

I'm thinking about how to set up Linux to launch my EXE and make sure it stays running (not that I expect it to ever crash).  I'm looking at the Monit tool. https://mmonit.com/monit/ , although that costs $, and Supervisor http://supervisord.org/

Ryan Vallieu CLA, CLED
Senior Systems Analyst II
NASA Ames Research Center
0 Kudos
Message 21 of 25
(85 Views)
Highlighted

Have you marshalled the file descriptor through some means as explained in this post or simply send the numeric value over?

 

File descriptors are not direct inode references but rather process specific indices into an array of file entry records that identify the actual stream, socket or file inode.

Rolf Kalbermatter
Averna BV
Message 22 of 25
(78 Views)
Highlighted

I was evidently treating the FD incorrectly using a LabVIEW VI in a .SO for the main socket monitor C program to pass the Int_t value to LabVIEW.

 

Though I am not sure using this RX method being called by LabVIEW by using a Library Interface Node would work once the FD is read by LabVIEW and in its application space.

Ryan Vallieu CLA, CLED
Senior Systems Analyst II
NASA Ames Research Center
0 Kudos
Message 23 of 25
(66 Views)
Highlighted

I'm not sure either but supposedly those methods marshal the file descriptor between process spaces. Basically the fd is an int value that only has a meaning in th context of the process in which it was created/opened. It maps to a data structure that is maintained by the C Runtime library for the actual process which does things like buffering and such. It also contains a v-node pointer which points to the kernel structure that manages the actual file/directory/socket/device in kernel space.

 

It also is indicated by a remark that supposedly the integer value of the two file descriptors is not the same in the two processes despite being for the same file/device.

Rolf Kalbermatter
Averna BV
0 Kudos
Message 24 of 25
(54 Views)
Highlighted

The integer value not being the same makes sense if the two processes aren't maintaining the same length list of descriptors.

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