Control a LabVIEW GUI exe from LabVIEW

[bmann2000]

I have a vendor supplied LabVIEW.exe application, it's used to control a device that's part of an automated manufacturing process.   At present we need to manually run the exe from the control PC , read data, make a decision, then input a few values, button clicks etc.   I'd like to automate this step.  Without having the source code for the application, what options do I have for controlling this application from LabVIEW?

I tried using System Exec.vi, but I got beat when I needed to right-click on a graph indicator to retrieve data.  LabVIEW applications don't accept SHIFT+f10 for right-click.

What other methods can I use to communicate with this application?

[GerdW]

Hi bmann,

did you ask the vendor? They should know the answer to your questions… 🙂

To control other (LabVIEW) executables you need some kind of communication protocol. LabVIEW allows a lot of communication ways - but they have to be enabled in the exe. Unless the vendor tells you the information about it you will likely have to play trial-and-error.

[bmann2000]

the vendor may offer support, but it's not certain.

do you know of any communication methods in the exe that would be enabled as default?

[camerond]

---

@bmann2000 wrote:

the vendor may offer support, but it's not certain.

do you know of any communication methods in the exe that would be enabled as default?

---

If the vendor doesn't support their software, then raise hell, all the way to the top if necessary. No company CEO wants to hear about unhappy customers, especially since in a case like yours the software supplied does not meet your (reasonable) requirements and the cure for the problem is so trivial (include output data from graph in an indicator/to a file/etc.).

Cameron

[Dennis_Knutson]

On the other hand, if the specifications that you provided to the software vendor did not include these requirements, then the vendor would be quite reasonable in asking for additional money to make the changes. You should also have required that the source code be provided.

[camerond]

---

@Dennis_Knutson wrote:
On the other hand, if the specifications that you provided to the software vendor did not include these requirements, then the vendor would be quite reasonable in asking for additional money to make the changes. You should also have required that the source code be provided.

---

Of course, this is true. I was making an assumption, that since the OP has experience in LabVIEW, these sort of things had already been taken into consideration by the buyer.

Would source code normally be provided when someone purchases an EXE? If there are proprietary pieces in there (algorithms, etc.), I thought it would be more common for the vendor to just provide hooks to the control and data functions.

Cameron

[Dennis_Knutson]

You make a good point. When I've done contract work, I've provided all source code that was created especially for the project. Existing code that was proprietary was excluded. All of this needs to be detailed in the contract. It sounds like the op does not access to the block diagram or project. This is unusual on my experience.

[bmann2000]

assuming the vendor cannot supply the source, or provide a new build with hooks.  one other option would be to use desktop execution trace toolkit to monitor the comms between the application and the hardware, reverse engineer the comms and create my own code to read/write to the hardware.  is there any wisdom to be shared on the reverse engineering approach?   I've noticed I can export data from graphs using a right-click, so that's one tip to start us off.

[jcarmody]

Might this be an application for AutoIt or AutoHotkey?  I've seen threads suggesting these as valid solutions for GUI manipulation.  I've never used either...