VBAI vs LabView/Vision?

[Nelson_Bridwell]

I am designing a machine vision system that will use 16 GigE cameras, run on a dedicated PC, and will use standard edge and blob tools to perform a fairly routine set of inspection tasks.  I will not need to code any new special-purpose image algorithms.

Because of the large number of cameras, I am interested in using parallel processes/threads as much as possible.

Also, I need to trigger inspections via Ethernet/IP from a Allen Bradley/Rockwell PLC.

Would there be any obvious advantages to using the Labview Vision Development Module rather than VBAI?

[ChristopheC]

> Would there be any obvious advantages to using the Labview Vision Development Module rather than VBAI?

With 16 different inspections, even if you plan to use VBAI, I would still use LabVIEW and the VBAI API to create a supervisor application that launches all the VBAI engines and the inspections using the VBAI LabVIEW API.

The advantage of using VBAI is that it has a lot of built-in features that you would have to rewrite in LabVIEW such as

- all functions include pass/fail criteria

- I/O and communication steps.

In addition, it might be easier to modify update the inspections without having to modify the code of the supervisor/monitoring application. All you have to to is modify the inspection in Vision Builder AI.

You say that the processing is relatively straightforward. If this is the case, you might have less overhead writing the application in LabVIEW rather than lauching 16 VBAI engines. The Ethernet/IP VIs are easy to use, and you might be able to have tighter synchronization for the triggering of the cameras.

If you go that route, I would suggest using the Vision Assistant Express VI to configure the different inspections. This would allows you to easily make edits to each of them using the Vision Assistant UI.

As mentioned, the drawback in LabVIEW is that you'll need to write any I/O and communication code your application needs.

At which frame rate are the cameras going to be triggered? What's the resolution? How much time do you have for each inspection?

Do you plan to run all of them on a single PC? What are the spec of the PC?

To which hardware are the cameras connected to?

[Brad]

Here are some things to consider (in addition to what Christophe said).

1. You had asked about 32 vs. 64 bit OS..even if you're running a 32-bit application, I would always recommend a 64-bit OS. This allows multiple 32-bit applications to each have up to ~4GB of memory, and if you're talking about 16 instances of VBAI running, they can each get up to this limit instead of on a 32-bit OS being limited to the total memory available being 4GB shared between all applications.

2. Because VBAI only allows 1 instance to run the Ethernet/IP Server, you could use LabVIEW to do the communication over Ethernet/IP and manage triggering/acquiring images in parallel and then use the VBAI API to send the images to the VBAI engines with a set image variable call so the VBAI only has to process the image and send the results back to your LV program. I really liked Christophe's idea of using a network trigger that the PLC controls, but I don't know if your cameras support network triggers or if your PLC would support sending a action command to trigger them...maybe the PLC can just trigger them directly with I/O lines...I assume this isn't an option since you're wanting to use Ethernet/IP to tell another application when to trigger them.

3. If all your inspections are exactly the same (except for which camera they use), VBAI unfortunately has a restriction that only one engine can open an inspection at a time, so you'd have to make 16 copies of the same inspection and have each VBAI instance load a unique copy of the same inspection.

4. If this is the case (all your processing is the same), and the inspection is straight forward, I think using LabVIEW to run everything in parallel with a rentrant VI that does the acquisition and vision algorithm might be the simpliest and fastest approach, but it might take longer to develop the code.

Hope this helps give you some more ideas, and let us know if you have more follow-up questions.

Brad

[Nelson_Bridwell]

At which frame rate are the cameras going to be triggered? What's the resolution? How much time do you have for each inspection?

Do you plan to run all of them on a single PC? What are the spec of the PC?

To which hardware are the cameras connected to?

14 of the cameras are 1.3 MP at one frame every 4 seconds...although we will want the results ASAP.
2 of the cameras are 5 MP at 4 frames in 1 second, again every 4 seconds.

And I want to buidl a unified UI that will display images/status from all cameras.

AND...The inspections will be triggered via Ethernet/IP from a Rockwell PLC.  Not one trigger signal, but 8 triggers, each one triggering for 2 cameras.

[Nelson_Bridwell]

Brad:

None of the inspections are exactly the same.  Pairs of cameras do similar measurements, but the ROIs are different...

The cameras are stock Basler Ace GigE cameras...

My goal is to come up with a straightforward way to use VBAI or Labview/VDM, running on a dedicated PC, to handle lots of GigE cameras that are individually triggered via Ethernet/IP from a PLC with the results also returned via  EIP.

     Nelson

[ChristopheC]

The Ace should support Action Commands, as long as they have new enough firmware. So the most elegant way would be to send network triggers to trigger the cameras.

[Gres]

Hi there,

I have Basler ace with new fw which supports Action Commands. There is an example how to send it from Basler Pylon SDK. But do you know the way how to send it from LabVIEW?

Thx

[BlueCheese]

Native support in the API is not present today besides when using hardware like the PCIe-8237R or CVS-1458RT which sends the Action Commands in hardware. Fortunately since these commands are meant to be sent by anyone on the network, it is trivial to just send them via UDP directly from LV code. See the attached VI for an example. Note that there are some optimizations missing like re-using the socket for multiple uses. Additionally, on some platforms, you may need to iterate through all host IP interfaces to send a packet out through each of them.

Eric