LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Reading Controls and Indicators from the front panel of a hidden executable

Solved!
Go to solution

Hi forums,

 

I'm trying to read controls and indicators from the front panel of a hidden executable that is not in focus. The hidden executable is like a service that runs in the background constantly polling for updates from an Xbox controller. The reason I don't simply poll the xbox controller in my main application is because of issues with the lvinput.dll, which is a topic for a separate post. In short if the Xbox controller is plugged out during acquisition, the environment has to be restarted in order for the reference to become valid again. I don't want my users to have to restart the entire application every time the Xbox controller is plugged out hence I call it in a separate executable and restart just that executable if it is unplugged - I've tested this and it works.

 

The problem I'm dealing with at the moment is that the executable front panel controls don't update unless the executable is in focus and I can't have it in focus as it is a background service (front panel and taskbar icon are hidden). Please see the snippets below for more information.

 

'worker.exe' block diagram. This VI polls the Xbox controller using the LV Makerhub toolkit (which calls lvinput.dll)

worker.png

 

'launcher.exe' block diagram. This VI launches the 'worker.exe' and polls it's front panel controls for updates. It only updates when 'worker.exe' is in focus.

launcher.png

 

Launcher front panel - the Xbox controls don't update unless the 'worker.exe' is in focus

AudioVideoDisco_0-1581631419348.png

 

I hope someone will be able to help me out here, is there a way to poll a remote executable's front panel values without that VI having to be in focus? Or maybe there's a better, more efficient, way of communicating between a 'launcher' executable and a 'worker' - can I register for events from a remote executable? I don't have much experience communicating between separate executables so I'm open to any and all suggestions/advice.

 

~AVD

0 Kudos
Message 1 of 11
(3,052 Views)

How about a Global Variable or better yet a Functional Global Variable (AKA: Action Engine)?

========================
=== Engineer Ambiguously ===
========================
0 Kudos
Message 2 of 11
(3,029 Views)

Can't communicate between two separate .exes using global variables or FGVs unfortunately.

 

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000P8XTSA0&l=en-CA

0 Kudos
Message 3 of 11
(3,023 Views)

Network shared variable?

0 Kudos
Message 4 of 11
(3,015 Views)
Solution
Accepted by topic author AudioVideoDisco

I was going to suggest TCP/IP, possibly via Network Streams (as that's what I use for communicating between my Host Executable and the associated Real-Time Executable), which is exactly what the article that you referenced suggested.  I haven't had to worry about "breaking the connection", but TCP can detect such, and can then go into a "Listening for the connection to be re-established".

 

Bob Schor

Message 5 of 11
(3,013 Views)

Yeah I guess TCP/UDP would work, I want to stay away from Shared Variables (they're more trouble than they're worth imho).

 

I was hoping that there might be a simple method to update & read the FP controls of the remote VI without it having to be in focus but I guess there's not?

0 Kudos
Message 6 of 11
(3,000 Views)

@AudioVideoDisco wrote:

Yeah I guess TCP/UDP would work, I want to stay away from Shared Variables (they're more trouble than they're worth imho).

 

I was hoping that there might be a simple method to update & read the FP controls of the remote VI without it having to be in focus but I guess there's not?


You could also implement a web service and get your updates that way. I would definitely recommend using some sort of TCP/IP based connection. Network streams work nicely but they are proprietary. I generally go with my own TCP/IP implementation. One benefit of this is that applications developed in other languages can also use the same interface. This is also a benefit of the web service.



Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
Message 7 of 11
(2,989 Views)

Great, thanks all - I will go with a TCP/IP solution!

0 Kudos
Message 8 of 11
(2,939 Views)

VI Server can be used.

 

Mark the VI of interest as served and enable VI server in the project before doing the build.

 

The "client" side" can then Open a connection the VI Server in the exe and then open a ref to the Target FP and use "set/get" control value methods.

 

OR

 

Do something similar using an Action Engine that is served via VI server. The target VI will push status updates to the AE and the client side invokes a "Read" operation using a Call By reference method. I have used this latter method to be able to probe the internal state of a exe I wrote running on another machine that had to talk to a application developed by a third party.

 

After additional thoughts...

 

This post mentions the technique and has a link to a Blog Article I wrote. 

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 9 of 11
(2,921 Views)

Seems you have plenty of options.

 

Just wanted to mention that "network shared variables" are of course also over TCP/IP (as any other network method!), so just generically saying  "TCP/IP" is very ambiguous. 😄

Message 10 of 11
(2,901 Views)