Handling IMAQ Images in the TestStand Opeator Interface

[Cabman]

---

@dowNow wrote:
Ha ha, no I do not have experience with sharing an image handle across
processes, I saw your post and thought I would join the question
because I need to do this too and I don't want to pass/copy the image
as a big string of bytes.



I will say, however about the escape characters, if you are passing the
string from a LabVIEW code module up to Locals, there is a setting in
the Specify Module dialog that allows you to set a LabVIEW string
control entry in the table to ASCII or binary, that might help getting
it into the Local correctly.



Another approach would be to pop open a floating LabVIEW window from
within your seqeunce/execution and display the image there and not on
the front panel of the OI.

---

So much for my attempt to get you to do my work...

Yes, you have to use the binary option in Specify Module or you the flattend data VI won't save anything in the local.

Yes an external window would work. For a number of reasons I'd like to display right in the interface if possible.

[VuD]

Hello dowNow,

Thank you for using our discussion forum.  In regards to what you mentioned about opening a floating LabVIEW window, this can also be done using the "IMAQ WindDraw" VI if you have NI Vision software.  This VI displays an image in an image window automatically when the VI executes.  This is just another work around to try out.

Regards,
Vu D
Applications Engineer

[dowNow]

Vu D,

Your posts have not ruled out passing an IMAQ image handle from a LabVIEW code module to TestStand, and then to a LabVIEW OI for display in a LabVIEW image display. Is there a way to do this with either a LabVIEW or a CVI code module?

[~jiggawax~]

You can just use UIMessaging to pass the information back to the OI.

http://zone.ni.com/devzone/cda/tut/p/id/2898
http://zone.ni.com/devzone/cda/tut/p/id/4532

Regards,

Message Edited by Sam R on 11-27-2006 03:23 PM

[Cabman]

I've managed to pass an image from one LabVIEW executable to another. Haven't compiled it into my Operator Interface as of yet:

SharedImageDLL.zip
----------------------------

Demonstrates passing an image from one LabVIEW executable to another through a Windows DLL.

Run "WriteImage.exe" and select an image file.
Run "ReadImage.exe and that image will be read out of memory and displayed.

SharedImageDLL.c - Use LabWindows/CVI to compile into a DLL.

Based on the code on MSDN "Using Shared Memory in a Dynamic-Link Library"
Modified to use byte arrays instead of strings. The problem with using a string is that the flattened Image image is loaded with NULL characters and processing stops when read. Because an array is used, the 'SetSharedMem' function needs to be passed the size of the array. The function 'GetBuffersize' was added so LabVIEW can initialize an array before requesting the array data.

Developed with:
LabVIEW 7.1
LabWindows/CVI 7.1

To run executables:

IMAQ 3.7.0 (make work with earlier versions, but "IMAQ Flatten to String" is required.
LabVIEW Run-Time 7.1 

I was too deep into this to try the UI Message suggestion.

[dowNow]

About the UI Message suggestion,

I assumed the whole exercise with the SharedImageDLL.zip was necessary precisely because the UI Message suggestion doesn't work. I guess I'll try it myself, but I thought if you passed an IMAQ image handle up from a code module and posted it as a UI Message, when you processed the UI Message in the LabVIEW OI (write to a LabVIEW image control) it didn't work, and that was why the workaround was neccessary.

[Cabman]

I guess I'm not sure on the terminology here. I thought I was using the TestStand API directly to try and transfer the Image data from the sequence to the OI . From what I now understand the UIMessaging is how I was tapping into the sequence to get the data. At any rate, I don't see how to make that work with and I needed the workaround above.

Did you try my example out?

[~jiggawax~]

So you don't pass the handle around.  That's why you have to use the IMAQ Flatten To String VIs.  Because you are correct that you have a handle to the image and then when you use those IMAQ VIs it takes the actual image and not the reference to the image and flattens that to a string.  Then once you have the string of the actual image you can pass it around just like normal strings.  So that way you can pass it back to the OI using UI Messaging.  Then you have to use the IMAQ VIs again to get the image from the string and therefore giving you back the handle that you had in the first place.

Regards,

[Cabman]

Yes, that is what I attempted. As I said before:

"When the GetValString reads the local it does not interpret the escape code '\'. i.e. if the string contains '\00' it ends up as '5C 30 30'. The Unflatten From String vi is expecting hex 00 and an error occures.

I wrote a crude VI to look for the escape code and convert what follows to pure hex. It first converts the string to byte array, interprets each byte, creates a new hex array then converts it back to a string. The good news is that it works for numeric arrays, and I was able to read the array values in the Operator Interface by reading the flattened data from the sequence. However, when I applied the VI to the Image Flattened data, the array was 2,295,879 elements long and my VI was way too slow to convert the whote image."

Is there a way around this?

[~jiggawax~]

You are correct Cabman.  You will have to have LV code that will decode those characters that put the / in there.  It should be simple to create that.  Basically you just need to loop through and look for all the / in your code and the characters following the /.  Let's say I do have /00 then just replace that with 00.  This way you can still pass it as a UI message you just have to have the decoder in your OI to handle the string correctly.

I'm sorry this is a pain but for now that's how it is.  The problem with this method is that in the future if TestStand handles strings differently then your OI will have to be modified.

Regards,