LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

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 Kudos
Message 1 of 9
(4,091 Views)

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 Kudos
Message 2 of 9
(4,087 Views)
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 Kudos
Message 3 of 9
(4,084 Views)
Joseph's idea is optimal if it fits your requirements.
Jarrod S.
National Instruments
0 Kudos
Message 4 of 9
(4,080 Views)
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 Kudos
Message 5 of 9
(4,077 Views)

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 Kudos
Message 6 of 9
(4,073 Views)
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 of 9
(4,067 Views)
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 Kudos
Message 8 of 9
(4,046 Views)
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 of 9
(4,046 Views)