Events passed into Labview created exe

[thutch79]

I've been trying to get around an interesting problem. I'm attempting to communicate with a piece of hardware using the vendor's Active X implementation. The problem I ran into is they require the executable to be located in their file structure. I won't get into details on why that is, but for now, this is a hard requirement. Now, I could easily create an exe from labview and place that in the appropriate place. That's fine, but it makes debugging a challenge since it won't work from the Labview development environment. Ideally, I'd like to encapsulate the active x calls in an executable that can be placed in the appropriate location.

The problem becomes communicating with that executable. I've been playing with utilizing Labview's active x communication to that executable, but that is fairly limited. I'd like to use events, but I can't seem to pass either an event reference or the registered event data to the executable. Is this something that is even possible? Or do event references only live within the process? Or is there another way to accomplish what I want to do?

I've also tried to simply use a basic event structure with booleans to fire events. However, when you set a control value via the active x server, it doesn't fire events. I think it might the equivalent of "value" versus "val (sgnl)" in property nodes.

[GregFreeman]

You can use open application reference to open a reference to that executable. See if that allows you to do what you need.

[GregFreeman]

Disclaimer: I have not tried this, but to go into more depth:

You could have a VI in that application which holds the event reference. That VI could have a case structure with all the different events you can fire and that VI can have an enum as an input. When you want to fire a specific event, open a reference from your application to the application/VI which is in the other directory and feed it the enum you want. Then that VI in the application will handle the firing of the event.

Again, this is just off the top of my head and I can't guarantee this will work. I may try testing it later just for future reference!

[Yamaeda]

Active X is limited to the developer of the Active X commands, LV itself has no limitations in this regard. If the other program has a good ActiveX implementation you can use Property nodes and Invoke nodes and handle most things that way, incl. getting callback events and stuff (i've done all of that).

Communication with another .exe is another matter, ActiveX is a way of using another programs functions, but you're still running your own show.

For interprocess communication files, tcp/ip or something else is needed.

/Y 

[thutch79]

I think that would work as well, however, I think that means polling, right? Also communication from the exe is also a problem. What I mean by labviews limited active x implementation is communication to labview created exe's. It is limited to effectively getting and setting control values. It doesn't allow the creator of an executable to expose their own methods or properties. It also does allow for events.

[thutch79]

What about this....

Utilize a shared variable set as a poor-man's events. It looks like there is a read without timeout function that waits for new data in a shared variable. I could write to a shared variable when I have something to communicate. On the other end, I could have a VI that always calls this read function to look for new data. This should work in either direction. Is there any reason why this wouldn't work?

[GregFreeman]

---

@thutch79 wrote:

What about this....

Utilize a shared variable set as a poor-man's events. It looks like there is a read without timeout function that waits for new data in a shared variable. I could write to a shared variable when I have something to communicate. On the other end, I could have a VI that always calls this read function to look for new data. This should work in either direction. Is there any reason why this wouldn't work?

---

Try it, see what happens.

[thutch79]

The shared variable solution seems to work. It doesn't seem particularly fast, but for messaging, it seems suitable. Here are the steps I took:

1. Create a shared variable in the project.

2. Create a VI that with will listen to the shared variable. This VI calls "Read Variable with Timeout". This forces it to only read when there is a new value. 

3. Turn that VI into and executable. Be sure to deploy the shared variable along with the build.

4. Create another VI. Set it up to send values to the shared variable.

5. Start the executable (which should also start the shared variable engine)

When you write data to the shared variable, it should automatically pop-up in the executable. For testing, I just sent strings to the executable and had it pop up a dialog.

Hope this helps someone in the future.