Linux Users

Showing results for 
Search instead for 
Did you mean: 

LabVIEW VIs called from .SO - application space

I am following trying out calling LabVIEW Code wrapped in .SO from C code that I build into EXE using the GCC compiler on my Cent OS 7.6 PXIe-8135 system.  LabVIEW is 2018 SP1.


I got the .SO building working.  I have the GCC compiler creating the C exe code.  I can create and write to files to verify that my LabVIEW called from C code is working.  I can see in Linux using TOP that my Code is running.


Once I verified with a simple VI to create and write to a file I then tried is writing a Notifier Sender using a Named Notifier, and a Notifier Receiver using the same Named Notifier.  Then I also created a Functional Global to store a Stop Flag that both VIs read.  My point of this was to see if the LabVIEW code called by the C code out of the .SO, but all using the headless LabVIEW Runtime Engine option would all be run in the same LabVIEW Application Space, and thus could all access the same Functional Globals, Named Notifiers, Named Queues, DVRs, etc.  What I think I am seeing is that they are not all running in the same application space under LabVIEW runtime.


My Notifier Broadcast – runs in a While Loop, writes out on a Notifier every 1 second the value of the Iteration terminal.

My Notifier Receiver – runs in a While Loop, reads using the attempts to grab the Notifier Ref by name, then Wait on Notification to get the Broadcast value of the Iteration and writes to a text file so I can verify the transmission is working.

I have the Stop Functional Global VI set to Write True when called from a C code exe as well.


I can see in TOP that both VIs are running. 


Results making me think they are not in the same application space:

Calling the Write Stop FG C Code does not stop the Broadcaster or Notifier.

The Notifier Receiver is creating the text file where it is supposed to write the received Iteration, but if it does not get the Notifier Reference (create is set to F) then it keeps waiting for it until Stop = T or it gets the reference on another iteration.  It is not writing the Iteration Value to file, thus I know it is stuck in the "attain ref." part of the code.


Is this expected behavior?  Is there a way to open a VI in this manner from C code and have all the VIs in the same LabVIEW "Application Space"?


I did see the check box in the Shared Library Properties for “Execute VIs in private execution system” - I turned that off thinking that would allow all the VIs in the .SO to run in the same LabVIEW Run-Time Engine and thus access the Named Notifiers, Named Queues, DVRs, etc. as if they were running in the LVDEV environment, or a single LabVIEW EXE.


I understand I can write a "top level" VI that calls the lower level VIs and include that in a .SO - but I was hoping to leverage C code to and launch LabVIEW VIs and have the LV VIs be able to access the same LabVIEW application space.


Is this not possible?

Ryan Vallieu CLA, CLED
Senior Systems Analyst II
NASA Ames Research Center
0 Kudos
Message 1 of 1