Multiple instances of VBAI

[Brad]

If you can easily separate your inspection in two so that each inspection only processes one of the images, you should be able to run both inspections in parallel and take advantage of your multi processor machine. I would recommend using the VBAI API in LabVIEW to start two local VBAI engines, load the two different inspections where each engine processes a different one, and then you can programmatically run both in parralel and get the results in LV so you can make a decision based on the results from both inspections, and then run again. The alternative would be to have two VBAI executables running, but then you would have to figure out some way to coordinate the two applications and share data between them and synchronize them (assuming you need to share results between them...if both inspection can run independently without any information from the other inspection, this approach isn't hard...if you do need to coordinate results, this approach is more challenging, and using the API to control the engines would work better).

Hope this helps,

Brad

[sensij1]

Brad,

Thanks, your reply is helpful.  Although I don't necessarily need the inspections to communicate with each other, I would like for them both to communicate with an external controller.  I could imagine using the Modbus functionality to do this, although I'm not sure how the software will respond if Modbus is called from two instances of the executable.  I'll dig in deeper and see if I can find something that works, although it is nice to know that the API would be able to manage multiple engines cleanly.

Jason

[ChristopheC]

Jason,

Modbus will work with multiple VBAI Instances. The modbus server is an application that runs in the background and listens for the Modbus queries sent by the server on port 502. Based on the Modbus frames received, the master can read or write the VBAI Modbus registers that are implemented as shared memory. The registers are therefore accessible by each VBAI instance that can read and also update those registers.

Christophe

[sensij]

So I've been scouring the forums and knowledge base for more information on parallel processing, and I'm starting to see that designing my computer hardware around multi-threading may have less payoff than just going after maximum performance in each of just a few threads. Without using LabVIEW to intentionally create work that can be done in parallel, each VBAI instance will basically run sequentially in single thread, at least for steps that process the image. By running multiple instances, VBAI gets the opportunity to use multiple threads. However, without control of the VI re-entrant setting, is it possible that if the most time consuming step in both instances calls the same VI, they will be forced to run sequentially anyway? Thanks, Jason

[Brad]

It depends on what the most time consuming VI is. If it's calling a DLL that is single threaded, not much you can do. If it's calling a DLL that is optimized for multi threading, no problem (some of the vision functions are optimized for parallel operations), if the VI contains mostly LabVIEW code, they will be run in seperate processes, so you shouldn't see any bottle necks in regular LabVIEW code when in parallel in seperate processes (unless they require the same resources like hardware or files I/O possibly).

I agree that focussing on getting faster processors is probably better than more processors, especially if you only have two main processes and almost every computer you buy will have at least two processors.

Hope this helps,

Brad

[sensij1]

Brad,

So the followup question I have to ask is if there is any documentation on what DLL's are optimized for multi-threading.  Even within VBAI, there are sometimes multiple ways a particular analysis can be done.  I could try to design the process to rely more heavily on the multi-threaded steps, if I know what they are.

Thanks,

Jason

[Brad]

I meant to say that all the Vision functions can be used in parallel (i.e. they don't block each other unless they are working on the same image), but only a hand full have been optimized for multi core to take advantage of multiple processors at the same time. I would not worry about designing your code around the multi core algorithms since there aren't many and they are very specific. Particle analysis, label image, convex hull, and particle filter are some I found here:

\\us-aus-argo\NISoftwareReleased\Windows\Distributions\Vision Development Module\2009\9.0.0\readme.html

but some of the newer algorithms also may have been optimzed, but it doesn't look like we document this.

When you have multiple processes running, all the Vision functions used by these processes should be able to run fine in parallel since they can't be using the same image across multiple processes.

Hope this helps,

Brad

[Brad]

Sorry about the link, here's the public link if you want to see the detailed list of functions that were optimized for multi core machines:

http://download.ni.com/support/softlib//vision/Vision%20Development%20Module/2009/readme.html