LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Any way for one VI to dynamically update images shown in another VI's Image Display control?

I've just discovered (in LV v7.0) that, while I can wire to it, I cannot write image data to a "value" input terminal of a property node associated with an Image Display. When the VI runs I get this error:

"IMAQ Vision: (Hex 0xBFF6051A) The Image Display control does not support writing this property node."

(I must admit that I have to wonder why we are allowed to wire to it, if all it does is generate this error)

Is there any way for one VI to dynamically update images shown in another VI's Image Display control?
I am not interested in using IMAQWindDraw windows.
0 Kudos
Message 1 of 3
(2,788 Views)
OK, I have found one way to simultaneously access one VI's image data within another VI without the use of globals. I don't know if it makes use of a known feature of image data that will be with us forever or if it is a bug that will disappear sometime in the future...

It seems that if I create an image data stream in one VI using IMAQ CREATE and name the data stream "ABC" and then create an image data stream in another VI using IMAQ CREATE and also name that data stream "ABC" then in fact they are both the same data streams and they can be read or written by either VI.

Using this feature I can write the common data stream in one VI and using a shared occurrence or semaphore let the other VI know when it is OK to display the data from the common stream.

This method requires that the displaying VI needs to have a while loop around the image display which is not nearly as simple as a display that is updated automagically by another VI writing to a VALUE input that is referenced back to the Image Display. I'd still like to know if there is some way to make that work.

One corollary to this is that if you have several image data streams in use in a system (they can be in totally separate VI's, running independently) and you don't want them tromping on each other's image data then you need to make sure that they (the image data streams) get created with different names. An example of a place where this might bite you (and where I discovered this "feature") is to have multiple copies of the same VI with different names to do image acquisition and display from multiple cameras. Being copies of the same VI, they all had the same image data stream names, defined as constants, within them. When they were run simultaneously, the image data from all of the multiple cameras randomly appeared in all of the image displays. I don't know if this feature would hold up if the separate VI's were turned into separate executables and then run. Do any of you know if this sharing of image data streams with common names works across executables running on the same machine?
0 Kudos
Message 2 of 3
(2,776 Views)
Warren,

Great observation about accessing the same image memory buffer to get images to different VI's. The IMAQ Create sets up a memory buffer with the associated name - thus, when creating two vi's with the same named buffer, there will be overwrite problems.

The reason why you will have to continuously update the image display is because the program needs to access the image in the memory buffer and then display it.

This behavior will not be the same in executables since memory allocation/management is handled differently.
0 Kudos
Message 3 of 3
(2,756 Views)