Is FTP faster than NSV sending images from VBAI?

[Photon_Dan]

We love Vision Builder for Automated Inspection (VBAI). We often run VBAI on real time targets and there is usually a PC available to act as the HMI. It is always useful to display result images from VBAI on the HMI, and that leaves us with the issue of transferring images. VBAI offers a few different methods to do that.

1. VBAI API from LabVIEW
   Pro:  Allows very specific selection of image to display.
   Con: Requires dedicated connection to VBAI engine. Creates a strong dependency between the LabVIEW code and Inspection configuration. Not event based.
2. Network Shared Variables
   Pro: They mostly work.
   Con: They are terribly slow, and they are documented to "use disk operations" on the RT side, and that sounds scary. They are evil. Not event based.
3. FTP
   Pro: Has the ability to "run in background". Might be faster than #2 (NSV)?
   Con: Requires FTP server / dealing with files.

With no ability to deal with the 'Cons' on #1 and #2, I decided to investigate #3. What if we had a LabVIEW FTP server that we could customize to keep the image data in RAM instead of writing it to disk? Would that be faster? It could also give us an event based solution since VBAI will send a STOR command each time it sends a new image, and our custom server could send a message to our HMI process when that happens.

Here is where I have a challenge. The server can build a string that contains a PNG image. If we want the image to come with its non-destructive overlay, we can tell VBAI to send it including the vision data. I now have a string with the image and vision data. If I write that string to disk and use "IMAQ ReadFile 2.vi" it will load up the image and everything is fine, but it requires that write to disk / read from disk operation to happen every time. Perhaps that is not so terrible, but it feels dirty if the image is not something I want to save.

There is "PNG Data to LV Image.vi" that will work for getting the image into a Pixmap, but we lose the vision data. The "IMAQ ReadFile 2.vi" function only accepts a file path and not a string. It would be great if it was decomposed into a read-from-file and then a decode function. The alternative is to hack around on the chuck of the string that contains the vision data, but that is still undocumented and therefore risky correct?

Any help or insights are appreciated.

Thanks!

[Brad · Accepted solution]

Glad to hear how much you love Vision Builder AI. The API does what you want, but as you mentioned, it is not event based and requires a dedicated connection to the target. I'm not sure how you plan to get images from the target without some kind of connection, so for simplicity, I would recommend the API. If you really want to come up with your own way of transferring images, but don't want to save images to disk, which is inefficient if you don't them saved to disk, you can use a Run LabVIEW step in VBAI that uses VI Server or TCP to transfer the image data to the host. You can use the IMAQ Flatten Image to String to create the string and then on the host, you can unflatten the string using the LV primitive "Unflatten from String" with an image ref constant wired in as the data type. This will automatically create a new image on the host. 

I would also recommend you add an idea to the Idea Exchange for Vision (https://forums.ni.com/t5/Vision-Idea-Exchange/idb-p/visionideas) to make the inverse of IMAQ Write String. IMAQ Write String outputs a string that is the binary contents of an image file (i.e. BMP, PNG, JPEG, TIFF, PNG with Vision Info, etc.), and so we could have a new IMAQ Read String that could take the string output by this VI and convert it back to an image. 

Use the attached VIs and copy the LLB in the "RT LLB Build" folder to the target, Use a Run LV VI step in VBAI to call "Run LV Code.vi" from that LLB and pass in the image you want to transfer. On the host, run Call Image Transfer (Host).vi. The host will wait for the target to update the image (i.e. no polling, just a simple wait for target VI to complete).

Hope this helps,

Brad

[Photon_Dan]

Thanks Brad!

The Run VI approach is clever, and it does have the advantage of creating event behavior. It also kind of provides that "run in background" functionality of FTP, but only for one image at a time. The example is something I can work with, and perhaps it will prove to be a faster way of getting images over to the HMI.