Question on programatically launching compiled LabVIEW app and sending references

[oldmanXJ]

I have a sophisticated LabVIEW 2015 app that I wrote and have been using for quite some time.  It performs throughput and byte error rate testing.  In order to get the performance up to where it needs to be, I wrote three separate LV vi's that get programmatically launched.  The reason for this is that by doing this, each gets launched in a different processor core instead of all going into one core and each is running asynchronously.  The buffering is provided by shared queues.  Performance is significantly improved.  When I launch each one, I pass the handles for queues that are used to pass data asynchronously between the apps.   It works great and the data rates are phenomenal.

The issue becomes that I need to compile the apps for use in production.  It appears that the method for launching VIs will not work for compiled LV apps.  Does anybody have any experience with this?  I am looking at setting up a VI to act as a global variable and putting the queue handles there, but it seems a bit clunky.  The other thing is that when the program finishes up, I use the reference to each launched VI, to shut it down.  I don't remember the exact reason I didn't simply used named queues, but I think it had problems with forcing the all the apps into a single core.  It has been well over a year since I did this.

[tyk007]

A few things occur to me:

1. Are you aware that the path to VIs called dynamically changes in a built application?
2. To "force" a VI to run on a specific core requires you to use Timed Loop Structures. if you aren't using these then the run-time is free to run your code (or even parts aka "clumps" of it) on any thread and any core in your system.
3. There is nothing inherently "not multi-threaded" about named queues over un-named queues. Even un-named queues actually have a name (though you don't get to see it) - all queues come from the same set of global queues. The pros/cons are around the uniqueness of a queue when you acquire one.

[oldmanXJ]

Thanks for your response.  Yes I am aware of the difference in location for the code.  I ran across that quite a few years ago.

I am not running timed loop structures, but from my experience, the compiled code for each ends up in a different core.  It makes a ton of difference since I am trying to hit as high a throughput as I can.

I can't remember why I am passing the reference instead of just a name for the queue, but there was a good reason....I just can't remember.  Getting old is a bitch.  😉

Is there a better way to launch the LabVIEW exe's than a simple system call?  It would be nice to be able to shut down the modules if something fails, without having each module poll a global or such.

[tyk007]

Hang on - are you saying that each launched VI is actually a launched exe? if so - that is your problem. Each executable hosts a unique instance of the LabVIEW runtime - and your code runs, by default, in the default Application Instance. Global structures, like queues, are global only to the Application Instance. This means that references in one exe are not valid in another exe. As I described earlier - this will affect even named queues since they are no different. This will actually be true of every LabVIEW reference type and is generally true for all native (Windows presumably in your case) references as well.

If you want to share data between exes then you will need another mechanism to do inter-process communication. There are plenty of options around from frameworks, network streams or even raw TCP.

[nathand]

Have you tried changing the execution system for the top-level VIs that you're launching? That will force them into separate threads, and possibly separate processors, without needing to break up your code into separately-launched components. You only need to change the top-level VIs; any subVIs they call should be set to run in the caller's execution system.