why doesn't my vision program work as an executable?

[usrfrnly]

I have a program that works as a vi but fails as an executable even on my development PC. The purpose is to catch a specific image that is generated every so often in an executable and to save that image for offline analysis/troubleshooting. The whole thing works like a charm as a vi but the executable never catches a change in the target image. The names (horz and vert below) are correct, i'm just stumped. the rediculous amount of image resizing is due to the "-1074396154" error i was seeing (again, only in the executable and not in the vi) as this is the only way to stop that error. Thanks in advance for any ideas/helps/critiques/snacks etc. 

[BruceAmmons]

You shouldn't use the shift registers.  The first time through, they contain Image Name and Vert.  The second time through, they contain V Copy and H Copy.  I doubt you are getting the results you want with that.

Bruce

[usrfrnly]

klugy as it may seem, the shift registers are there specifically to pass the reference to the copies of the images from the previous frame to be compared (by the IMAQ absolute difference) the other input of which is wired to a static image reference ("Name" and "Vert"). The static image references are the ones that are supposed to trigger the saving when the images they reference change; The problem is that the change occurs in an other executable that cannot be changed. This is supposed to be a sort of remote monitor.  

The thought process is that you start with the an image, make a copy of it, pass the copy to the next iteration, and then compare the copy from the previous iteration to the current occupant of the "name" and "Vert" memory space. the coppies are made with names that cannot be affected by the main executable. whereas the "name" and "Vert" images are occasionally changed by the main executable.

i hope that makes it more clear. Thanks for your time.

[BruceAmmons]

I understand now.  I would just make an initial copy before the loop starts, then make a copy at the end of each iteration.

If you look for the maximum change != zero, it will save images for every new image.  Just background noise will make the images different by a few pixel values.  If you want to see something significant change, you will need to set the limit higher than zero.  Probably twenty or more.

I don't see anything obvious that would prevent this from running as an executable.  I'm not sure what the problem is.

Bruce

[usrfrnly]

Yeah, I'm m not proud of the code. I DO need it to be sensitive to even a single pixel change and it DOES function exactly as I intend as a vi, but I just don't know why it doesn't as an executable. I'll keep plugging away at it.

[BruceAmmons]

What are you using for the image name?  Does the executable run automatically?  If the image name is blank that could be an error.  I would guess you enter the name first then press run in the development system.

I would use a constant for the image name, then you can prompt for an image file name if you need it.

Bruce

[usrfrnly]

I'm using "Horz" as the value in the text control "Image Name". It was a grasp-at-straws attempt to trouble shoot on the guess that executables might automatically rename image references within themselves. It still functioned (again, only in the vi) and was only the last iteration in my troubleshooting attempts. It was mostly, and is again, a constant "Horz". I didn't mean to post the image of the code with the control but it wouldn't let me edit the post for some reason. As you might notice, the same code is below with the constant "Vert" and that doesn't work, either.

The executable runs automatically and occasionally creates images named "Horz" and "Vert" which are the images that this code is supposed to monitor for changes recording any new images. 

Thanks again,

-Pat-

[BruceAmmons]

Another question - where are the images being updated?  This loops processes the images, but it never acquires a new image.  There is nothing to process.

If you are doing the image acquisition in a different vi and making a separate executable, that would be the problem.  Executables can't talk to each other and don't share data or images.

Bruce

[usrfrnly]

"Executables can't talk to each other and don't share data or images"

What?!? This is madness!

Yes, all the acquisition is being done in another executable. This code is for a seperate executable to monitor the acquisition process. The hope was to monitor the images by monitoring the named memory space allocated by the IMAQ create function. It works in a vi, why not an executable?

The image is passed around using a queue in the acquisition executable; maybe i should use that to monitor. The only problem is that i'll get about 300 extraneous images for every image i need which means the zip file would be too large for the remote facility to email me the results.

Thanks again

-pat-

[BruceAmmons · Accepted solution]

It works in the development system because LabVIEW is the executable and each vi is part of the same executable memory space.

The easiest solution is to run both VIs in the same executable.  You could make a main VI that just calls both VIs, then make an executable from that.

Bruce