How to use User-Events and Queues between Executables

[Tanchris]

Hi, 

I have an application that I want to split up because of its size. This way, parts can be "switched off" when they are not currently needed and the EXE remains compact and not all VIs are loaded into memory. I initially thought of dynamic VI handlers, since I wouldn't have to change much here, except that I always pack all VIs into the EXE, right?
But now I would like to know whether I can also make executables from my daemons and whether my user events and queues can still be used (I read something about VI servers together with action engines). I have already read data from an EXE using VI servers, but how can I use functions that normally only work in the EXE itself?
Many thanks for any suggestions.

[rolfk]

No, LabVIEW refnums are private to a particular application context. That goes even further than executables. Each target in a project is its own application context and they can’t see each other’s refnums.

You’ll have to resort to real inter process communication such as network streams, shared variables or your own TCP/IP communication protocol.

[Tanchris]

Hi,

I found this old post from mikeporter

Solved: path of vi in exe - NI Community

He wrote, you "Also you can essentially use queues and events between executables"...but how to do with VI-server?

Or...how can I replace user-events with commands over TCP? Maybe queues I can manage with network-streams. But replace action-engines , that are used in several VI`s (and later executables) could be difficult ...mmhh 

So this 3 items I think are to check, events, queues and action-engines...thanks for suggestions 

[Kyle97330]

You may want to consider looking into PPLs, i.e. "Packed project libraries", LVLIBP files.

Fair warning, these can add as many problems as they solve, it's not just a simple switch you can flip.  Once you solve them you will have smaller builds and more modular code, but it is a big pain to get there.

Out of curiosity, how big is your program now?  Are you actually getting to the point where the size causes problems, or does it just "feel" too big?

[Tanchris]

Hi Kyle,

to big means, my executable has reached 43MB. And inside there are a lot of (relative loose coupled) daemons, which I don´t need all the time. For example, there is included a daemon for controlling keithley-multimeter, but a lot of collegues don´t need this device. And actually I put all of them into idle-state. And sometimes I got errors for too fast reading/writing.

Maybe I should try again to use dynamically calling VI´s, so that they don´t need memory/CPU. That seem´s to be the easiest way, but not for the future...

One daemon I´ve changed 1 year ago for trying out to TCP-communication. Thats ok for some of the daemons and they can stand alone at the end as executable. But most daemons using user-events and queues for communication...and therefore I need a solution...

[Kyle97330]

If you're willing to re-architect a fair amount of your messaging, you could look into adopting the MQTT protocol.  I don't use it, but one of my co-workers does and he made it work.

If you do a web search for "MQTT LabVIEW" there should be a number of videos that come up about it from old presentations given during NI week or similar events.  There's already open source code for the server and basic communications interactions, so you'd just be adapting it to your code.

Just in general I would note that 43 megs for an EXE isn't super large as LabVIEW goes.  The only application I have that has grown so large it occasionally gives memory errors on build comes in at 90+ megs.