Machine Vision

cancel
Showing results for 
Search instead for 
Did you mean: 

Multiple cameras simultaneously on Labview

Solved!
Go to solution

Hi,

 

I'm new on programming on Labview, so it would be really helpful if you guys could help me...

 

I have an EVS and 2 GigE cameras and I've developed an inspection program using Vision Builder, which works perfect for what I need. The thing is I need to run both cameras simultaneously - like two tasks running at the same time -, and I realized (with the NI technical support) that it's impossible to do such a thing with Vision Builder. So, I have to do all this job on Labview now...

 

At the moment I can't use the EVS, so I'm with a CVS doing some tests... I'm using a scA640-70fm and a A631f Basler cameras, both IEEE-1394. So here's my doubt:

 

To make both cameras work simultaneously, is it enough creating two simple While Loops and put the Vision Acquisition function of each cam inside them? Is it supposed to work this way??

because when I do this and make it run, I can't see on the Labview Front Panel both cameras working at the same time!! It looks weird, with one of the cameras acquiring more images than the other one, and the images disappearing some times... looks like it's not processing the images at the same time.

 

Am I doing something wrong? Should I need to take another procedure to make it works the way I need?

 

Should I have problems when i'll perform this procedure on my GigE cameras with EVS?

 

Thank you so much in advance...

 

0 Kudos
Message 1 of 8
(9,518 Views)

First you have to dissociate acquisition and processing task.

Of course you can acquire simultaneously on two camera at the same time.

But depending on the complexity of your processing on the images , you won't be able to process both images simultaneously.

In Vision Builder you can acquire from two cameras using the Acquire Function multiple times. Then you will hae two images to preocess.

If your script takes 300 ms to run for each image, then you will have to wait 600ms before acquiring the next images.

 

NTA_LabView_certified_Developper.jpg
0 Kudos
Message 2 of 8
(9,503 Views)

That's exacly what I have now on my Vision Builder application - the sequential acquisition of the images. But the customer can't accept this. By the way, NI just specified this hardware (EVS) for me because of this need - the simultaneous acquisition and process of the images. And what's happening now is that it doesn't seem possible to do this in a fair way!

 

It's just what I need: I have two cameras with the same inspection program and a EVS. Considering the cameras acquire images in the same time and the inspection process of each image takes 300 ms, I have to finish the cycle with 300 ms, not 600 ms.

 

Is it possible?

0 Kudos
Message 3 of 8
(9,499 Views)

If it takes 300ms to process one image, if you have twice more datas to process (2 images) , then it will take 600ms, unless you manage to parallelize your processing. The limitation is not due to acquisition, because acquisition takes only a few ms depending on you shutter speed, but to processing.

I know EVS uses a dual core processor, maybe you can parallelize processing on this two cores using parallel for loops in a labview code. But I think, all the VBAI functions already uses parallel capability of the EVS

NTA_LabView_certified_Developper.jpg
0 Kudos
Message 4 of 8
(9,495 Views)

I'm not sure if VBAI uses EVS parallel capability, but even if it happens, I can't make both cameras work in parallel, since the software functions don't allow me to do this job.

 

Just a question: when I create two for loops on a VI, Labview automatically executes each loop on a separated EVS core? There's something I should do to make it works this way?

 

Thanks for the help.

0 Kudos
Message 5 of 8
(9,491 Views)

 

Here you will find a complete tutorial on parallel for loop. I don't know if this work on the EVS.

NTA_LabView_certified_Developper.jpg
0 Kudos
Message 6 of 8
(9,486 Views)
Solution
Accepted by topic author teco

You are correct that Vision Builder AI is sequential in terms of how it runs the individual steps. The algorithms in those steps and how they execute may take advantage of multiple cores helping them run faster on machines with more than 1 core, so in that sense some of the steps may benefit from multiple cores, but multiple steps cannot run at the same time. This doesn't prevent multiple images acquired from the same trigger from being processed though. The acquisition steps support an immediate mode, which means if two cameras were triggered simultaneously, even though the steps run sequentially, the images they return can be from the same moment in time and you can use the Select Image step to switch the image you want to process. It's worth benchmarking your inspection in VBAI on the EVS (much faster than a CVS) before moving to a more complicated parrallel architecture in LabVIEW with multiple loops executing simultaneously.

 

One reason your earlier test with multiple loops may not have worked is that you may have named the image you created the same name. This would basically mean the two acquisition loops would be overwriting each others image. Make sure when you use IMAQ Create, you supply a unique name for each image. Another suggestion for how to help ensure LabVIEW schedules each loop on a separate processor is to make two sub VIs that are configured for different execution systems. You can configure this by going to File>>VI Properties>>Execution>>Preferred Execution System on the VI and selecting different systems.

 

You should definitely be able to have multiple loops running in parallel in LabVIEW, but before jumping to this approach, it may be worth benchmarking the VBAI solution first since this will make it easier to make changes to the code, and it provides high level steps that avoid having to worry about things like having unique names for images.

 

The above comment on For Loop parallelism is good if you want the exact same code to run in parrallel, which, you may not want to do since you're acquiring from different cameras. It would also make handling any results from the different cameras and disguishing which results go with which camera more challenging. That's why I recommended the sub VI running in different execution systems as a more flexible way to help ensure you take advantage of the two processors.

 

Hope this helps,

Brad

Message 7 of 8
(9,484 Views)

thank you Brad and toto26.

 

 

0 Kudos
Message 8 of 8
(9,453 Views)