In the attached example IAM.vi launches IAM2.EXE via "system exec". I would like IAM2 to communicate to IAM.vi. Note: Eventually the caller, IAM.vi, will also be running as a compiled code.
Considering both applications use LabVIEW, I tried using VI Server's "Ctrl Val.Set". When that didn't work, I tried "Ctrl Val.Get" - as seen in the example.
On my PC it's taking 10 or 12 seconds to launch the EXE!(?)
For those that don't want to run this, the call to "Ctrl Val.Get" returns the following error:
Invoke Node in IAM2.vi
"String" not found
It's interesting that "Ctrl Val.GetAll" works, but not "Ctrl Val.Get". I hope that by solving the "get" problem, "Ctrl Val.Set" will also work, which is my real goal.
By the way, I'm using LabVIEW 2017 under Windows 7.
The .zip includes the EXE project\Build. If you modify IAM2.vi and build IAM2.exe, it must be moved/copied beside IAM.vi
Oh, and see the "FP Close" in the "FP Close" button handler? That doesn't seem to work either!🤣
Thanks in advance!
You can't set or get the value of a boolean control, if it has a latching behaviour. Thats why Control values get returns an error
Hi aptivo, Please have another look; it's trying to get the value of a string control. The string is named "String" - hence the "String" in error message.
According to an AE, I should use TCPIP to communicate between processes. For anyone looking at the example, Ctrl Val.Get will work if VI Reference is wired on the Invoke Node. 😉 However Ctrl Val.Set still would NOT work!
I have a working example which uses UDP to communicate between processes, but I don't know how to get UDP messages in my main app without polling the connection. I guess that's a separate question...
If you open the target vi FP after setting the control, you will see that CtrlVal.Set actually works.
However, it has no effect on the original vi on disk. What do you actually want to do?
pp, Thanks for your reply, but I'm not understanding...
Assuming a "Ctrl Val.Set" is added after "Ctrl Val.Get" (in IAM2.vi) the "target" VI is IAM.vi. IAM.vi is running and open, but the string control labeled "String" is always the original value. I tried minimizing and "opening" to try to see the effect you describe.
I want to implement "emergency stop" (AKA: "E-Stop") logic that is as reliable as possible. This is a best-effort in the absence of a mechanical E-Stop. When the software (IAM2.exe) E-Stop is triggered, it will send a shutdown command to some equipment, then inform the top-level process that the E-Stop was triggered.
The first implementation depended on the ability of IAM.vi (exe) to respond and process a menu event. However, if the main process was hung, E-Stop menu event was not processed. So I'm separating the "E-Stop" logic from the top-level process. Running as a "separate" EXE, problems in the main app should not prevent the E-Stop from working. I say "separate" EXE because there's some behind-the-scenes linkage that allows IAM2.exe - through VI server - to read the control values of IAM.vi
It's the last bit - informing the top-level app of E-Stop. I'd like the E-Stop condition to generate an event in the top-level process, but all I have working is a UDP link that requires polling.
Any ideas are welcome!
pp, IAM.vi is the "target", no? It's open, running, and always shows the same value in "String". I tried minimizing and opening, but the text is not updated by "Ctrl Val.Set" in IAM2.exe.
I want to implement an "emergency-stop" (E-Stop) button. It's going to be a best-effort in the absence of a physical switch. When user clicks button, a shutdown command will be sent to a device and then the E-Stop condition will be communicated to the main process. The main process can then shutdown gracefully, if it's not hung.
I want the E-Stop logic to be independent of the main process - so if main process hangs, the E-Stop will still do its job (send shutdown cmd).
I used VI Server several times to Get/Set control values of a remote application over a network, but as far as I know you cannot do the same with another process (i.e. a running exe) on the local machine.
VI Server is not the solution to your problem anyway: it will not generate an event in the target process, but will simply set a value. The target process will need to poll the control value, so why not doing the same on a UDP port (for example)?