Multiple instances of VBAI

[Photon_Dan]

I know that we can now acquire from multiple cameras in VBAI (thanks!).  However, I feel that doing so leads to very complex inspection sequences.  It does not look like VBAI has fully embraced parallelism for things other than FTP transfer.  What do I do if I have 5 GigE cameras that each must be triggered, and where it is possible that two could be triggered at the same time?  Can I run multiple instances of VBAI on a single PC (hey, it's multicore)?  I predict that the current answer is to just use LabVIEW, but VBAI is mostly LabVIEW.... right?

I would like to maintain only the simple, single-camera, inspections on the PC.  Running multiple VBAI instances would allow me to dedicate an instance to each camera without worrying about what is going on wth the other 4 (or more).

No, I haven't tried to do this yet.  Currently, I am out of town and away from my vision lab.  I figured that if this is possible, it is worth mentioning to the public, and if it is not then it is worth mentioning to R&D.  The system I am picturing would be a future version of a system we just completed where we had 4 NI Smart Cameras and one GigE camera.  The question came up about what to do if all 5 cameras were GigE.  Don't worry, we still love the SmartCams!

On a posting streak,

Dan Press

PrimeTest Automation

[Brad · Accepted solution]

Hey Dan,

Good question! VBAI does support acquiring from multiple cameras, even if they are triggered at the same time. We have a flag in the acquisition step that allows you to specify if you want to wait for the next image or acquire immediately. So in the simple case of two cameras triggered simultaneously, you would have a initial state that tried to acquire from camera 1 and if there was a timeout it would loop back and try again using the Wait for Next Image flag. When an image is acquired, you know the other camera has been triggered, so you transisition to another state that acquires from camera 2 with an immediate flag since we know the image is already there. You can use the Select Imaage to switch between the two images, so all of this is possible, but not neccessarily the cleanest. Even if you had two VBAIs running simultaneously, synchronizing them wouldn't be trivial to ensure you weren't inspecting imageN on camera1 and imageN+1 on camera2, but maybe this wouldn't mattter for your system. In any case, we don't currently support multiple VBAI inspections running simultaneously on a system, but that is definitely a feature we are aware of.

Thanks for your posting streak,

Brad

[Photon_Dan]

Thanks for the response!

I understand the triggering scheme for multiple cameras, but I'd like to throw anther use case at ya.

We have multiple cameras that are positioned on either side of a conveyor.  A pair of cameras is positioned opposite each other to read front and rear 2D barcodes. Depending on the product, those barcodes could be in frame on both cameras at once or only on one and then the other as the product passes by.  We have the ability to adjust the trigger point based on encoder counts for each camera.  So we do not know in advance whether the cameras will trigger at the same time, and we do not know which camera must trigger first.  That is why we must run two inspections in parallel.  We need each camera's acquisition to be ready for a trigger regardless of the condition of the other camera or cameras.

Another use case is when there are multiple cameras on the same side of the conveyor and they must be triggered for two different products.  The inspection results of the second camera might now be ready in time for the first camera to be triggered again for the next unit.  Again, parallel inspections are needed so that each camera can be triggered for one unit and be ready in time for the next.

As always, we look forward to future versions of VBAI!

[The_Chancenator]

Hi Dan,

Thank you for your post.  At this point and time, you are not able to run multiple instances of VBAI (or LabVIEW for that matter, to my knowledge) on one machine, regardless if it is multicore or not.  What I would suggest is to port the VBAI code into LabVIEW and create executables.  That way, you could still run "multiple instances" of different LabVIEW, and would have the ability to communicate between the executables/cameras as needed. 

Of course, if you were using SmartCameras, you could run VBAI on each of these to do your inspection. 

Cheers, 

[Photon_Dan]

Marti,

Thanks for chiming in.

I'm kind of baiting you guys a bit with my use cases and everything.  If you'll reread my initial post you'll see that we are using Smart Cameras right now.  The issue is that we want to deploy a system to our customers that they can modify within the confines of VBAI.  We combine VBAI with custom LabVIEW applications running on the host PC and a cRIO.  The current architecture works very well, but the uestion came up about non-Smart Cameras. 

Multiple instances of compiled LabVIEW apps work just fine.  However, it is beyond our customer's ability to compile a LabVIEW app each time they want to make a small change to an inspection.  

What I am hoping for the future of VBAI is something similar to TestStand in that parallel tests/inspections can be handled.

It looks like I won't be able to make it to NI Week this year (I've made 10 out of the previous 11), so I figured that I'd make up for it by spouting some feedback at the Forums.

[The_Chancenator]

Dan,

Thanks for your insight, I'll file a product suggestion based upon your post.

Cheers,

[mvonstein]

FYI, feedback to Marketing / Product Development from an industrial user of several brands of vision systems...

I agree that it would be very useful to be able to run multiple instances of the VBAI application!   Since each one would run in it's own process space, you could:

- Shut down individual inspections for program adjustments without affecting others that may be in the same program on different cameras.

- Make the programs simpler and easier to understand without as much branching logic.

- Make the NI software a better value, by allowing people to use 1 piece of generic hardware instead of multiple dedicated processors. (PC, CVS, SmartCamera, etc)  This would make the NI software a more attractive choice for applications where we currently buy lower cost Banner, DVT, or Cognex units or if more power is needed-- an easier to maintain Keyence unit.

Currently IMO, because of the difficulties and expense involved with licensing, software version dependencies, and working with the NI hardware in general, I only consider NI where the additional functionality/flexibility is required.  I have had good luck with PC-based applications of VBAI.  If I could use an off-the-shelf industrial PC and run inspections in parallel-- making it easier to maintain and lowering the average cost per inspection, I probably would reconsider.

Thanks,

Mike 

[Brad]

Not sure if you all are aware that VBAI 2009 SP1 introduced the ability to have multiple instances of the VBAI application running on windows. This will allow you to have multiple inspections on Windows running in parallel! You can even monitor inspections running on multiple targets simultaneously from multiple VBAIs on the host. You can still only have one instance run for each target, but you can have multiple instances run on windows (either running inspections on the host, or monitoring inspections running on targets).

When you have multiple instances running inspections on the host, you have to share resources like which variables are shared, calibration files, TCP/ethernet/modbus/serial devices defined, framegrabbers, cameras, etc. (i.e. two different instances can't use the same camera at the same time...unless it's an IP camera). You can check out the new version here:

http://joule.ni.com/nidu/cds/view/p/id/1545/lang/en

When you have multiple VBAIs each connected to a target, each target has it's own dedicated resources/HW, so this isn't an issue. 

Hope this helps,

Brad

[mvonstein]

Sounds great!!!  This could be a game-changer... I'll check it out.

If you or anyone else has any experience running multiple instances on a PC host (not multiple targets) in a real production scenario, I'd like to hear any feedback you'd be willing to give.

Thanks,

Mike 

[sensij1]

It has been a few years, but maybe this is a thread worth reviving.  I've got GigE images coming in from a Jai multi-spectral camera, and would like the image processing to keep up with the 30 fps framerate from each sensor.  The most time consuming step (per the VBAI benchmarking routine) is a vision assistant step that extracts the color planes from the image, and performs a few arithmatic operations on and between them.

It would seem (as suggested by the OP) that relative to sequential processing, running multiple instances of VBAI to handle each video stream would allow more efficient use of a hyperthreaded multi-core processor.  With these processors much more common than they were a few years ago, has anyone looked closely at managing multiple data streams this way?

Currently, my i5 670 w/ 3.5 GB ram (32 bit system max) can process about 12 fps from one sensor.  I'm looking to substantially increase CPU performance by building a more up to date dual cpu / multi-core workstation, but want to make sure VBAI will benefit from that.