annuler
Affichage des résultats de 
Rechercher plutôt 
Vouliez-vous dire : 

Sharing memory between executables?

I'm working on a set of three programs: one camera interface and two vision processing routines.  Currently, the camera interface runs independently of the two vision processing routines, and the images are simply passed through Labview's shared memory.  In other words, the interface just runs and creates an image with a known name, and the other two routines use the name to read in that image and make their own local copy to operate on.

 

However, eventually these programs need to be compiled to executables, where this method will no longer work.  The two programs need to remain separate, so I can't build them into the same executable.  They will both be run on the same computer, so I was wondering if there was another way to write to and read from the computer’s memory that will still work for Labview-built executables.

0 Compliments
Message 1 sur 9
4 320 Visites

Could you explain why they have to be two different executable?

I have several top level VI that run independent of each other, but they are all compiled in the same executable.

0 Compliments
Message 2 sur 9
4 316 Visites
TCP should be a perfectly acceptable solution. It's a common interface for exchanging data between processes, even on the same machine. The code for sending data really isn't that complicated. Just take a look at some of the TCP shipping examples in LabVIEW.

You could use something like ActiveX if you're running Windows for interprocess communication between the LabVIEW-built exe's, but that would add a bit of overhead and complexity to the matter. Also, that would really only allow you to access a subset of VI Server methods, such as setting control values. Sending and receiving data wouldn't be all that quick.

Another alternative would be writing the data to a shared file, but that makes it hard to stream data continuously.
Jarrod S.
National Instruments
0 Compliments
Message 3 sur 9
4 313 Visites
Joseph's idea is optimal if it fits your requirements.
Jarrod S.
National Instruments
0 Compliments
Message 4 sur 9
4 309 Visites
The two programs are actually part of a larger system.  There are a number of things between the two, especially communications between the components, that are unique to each program.  The biggest concern though is that a health monitoring program watches each component in the system, and it has the ability to restart individual programs if errors occur in them.  If they were built into the same executable, both would have to be restarted if an error occured in either, which isn't ideal for the system.
0 Compliments
Message 5 sur 9
4 306 Visites

I forgot to mention, we'd like to avoid sending the images through any kind of messaging protocol.  We’ve got plenty of processing power, but our IO is pretty maxed out.  Would using something such as TCP put even more strain on other messages coming into the computer from outside sources?

0 Compliments
Message 6 sur 9
4 302 Visites
I could be wrong, but I believe you can start and stop the individual top level VI unless you do an exit. You could also use a global share area.
Message 7 sur 9
4 296 Visites
In the end, we decided that our (and Joseph's) first thought was the best: building both into the same executable.  We think we can still control each component individually with a few small modifications.  Thanks to all those that helped.
0 Compliments
Message 8 sur 9
4 275 Visites
In the end, we decided that our (and Joseph's) first thought was the best: building both into the same executable.  We think we can still control each component individually with a few small modifications.  Thanks to all those that helped.
Message 9 sur 9
4 275 Visites