Machine Vision

cancel
Showing results for 
Search instead for 
Did you mean: 

Do IMAQdx and NI hardware support GigE Vision 2.0?

Solved!
Go to solution

Hello,

 

From my brief research, GigE Vision 2.0 has some very nice features I'm after that aren't supported by the earlier GigE Vision 1.x standards:

  • Camera-side compression
  • IEEE 1588 (PTP) synchronization and timestamping

Does NI currently support these? If not, are there any plans to add support in the near future?

 

 

Thanks!

Certified LabVIEW Developer
0 Kudos
Message 1 of 5
(5,452 Views)

Hi,

 

Most of the GEV 2.0 features are optional, and we've slowly been adding them in to each IMAQdx release. Regarding the two you requested:

 

- Camera side compression is unfortunately not supported (or on our roadmap). This functionality is only supported by a few niche cameras for some very specific application areas, as traditional machine vision applications historically have demanded uncompressed data. I'd be interested to know if you have specific cameras in mind that use compression, and what applications you may be thinking of. IMAQdx does, however, support several IP cameras (from Basler and Axis) that do use MJPEG compression, as in that application space the compression is well-adopted. Depending on your needs, maybe an IP camera could be a better fit.

 

- IEEE 1588 is mostly just implemented on the camera side. IMAQdx always has let you retrieve the timestamps encoded within all the images acquired from the camera. I can provide some simple LabVIEW code that can convert that into a LabVIEW timestamp datatype from the 1588 format. As long as you have cameras that support 1588 and have a network topology that also supports distributing a 1588 clock, it should all just work. If you have requirements for the hsot CPU to also be synchronized to the camera, we have a variety of different options that depend on what hardware and software you intend on using and what your synchronization needs are (precision as well as to external I/O or not).

 

Hope this helps, and let me know if you have further questions.

Eric

Message 2 of 5
(5,379 Views)

Hi Eric,

 

Thank you for your informative reply.

 

Perhaps I've been trying to solve an XY problem, so I'll explain my context.

 

I have a customer who wanted 1280 x 1024 images, saved to disk at 30 fps, from 4 cameras simultaneously. Each image is to be associated with a GPS time and position, so that the image can be correlated with other data sources (the system also performs other live measurements). He doesn't need raw uncompressed data, so we acquired 8-bit colour images and then saved them as JPEG files.

 

The customer chose a GigE camera, so we built him a system with 2x PXIe-8234. We noticed that the PXIe-8820's CPU was barely keeping up with the compression, so we upgraded to a PXIe-8135 controller. This controller handled the load comfortably.

 

For the timestamps, I simply logged the GPS time at the instant I called the IMAQdx Grab VI. There's a bit of uncertainty involved, but it's acceptable. I guess IEEE 1588 level precision isn't necessary after all.

 

Now, the same customer wants a new system which captures 1900 x 1200 images from 6 cameras simultaneously. I'm not sure if the CPU can handle the load (and we don't currently have a camera to run tests with, unfortunately), so I was looking at ways to reduce the CPU load. Camera-side compression came to mind, and I assumed that I can write the pre-compressed image directly to disk as a JPEG file. (I haven't yet checked to see if the disk can handle the required write speeds, but that's a separate issue)

 

We are open to other protocols though. Would you recommend something other than GigE Vision? (No hardware has been selected yet, so we'll probably select based on the chosen protocol)

 

 

Thanks again!

Certified LabVIEW Developer
0 Kudos
Message 3 of 5
(5,361 Views)
Solution
Accepted by topic author JKSH

Hi again,

 

Thanks for the additional context.

 

Assuming your only usage of the camera is to log JPEG images to disk, and you're concerned about performance of the acquisition system, I think an IP camera might be a better bet. These cameras acquire compressed images, so you can pretty much save them direct-to-disk without any extra overhead. This is going to save both network bandwidth and CPU time. The network bandwidth might be nice because you could probably just run all 6 cameras into a gigabit switch and connect back to one port on the PXI chassis instead of several 8234 ports. This is possible because not only is the bandwidth reduced, but IP cameras can use TCP and share bandwidth much nicer than GigE vision cameras can. To save the raw images to disk, you can use the IMAQdx VI "Get Image Data", which for an IP camera will just be a JPEG file that you can save directly.

 

Regarding timestamping the data, it all depends on the precision needed. Since you were just recording the time after Get Image returned, this was pretty imprecise as it really isn't correlated to the acquisition time. You could get a more precise time in two ways: IMAQdx records a CPU timestamp upon driver reception that you could use (helpful if the CPU is synchonized to GPS/NTP or similar) or you could use a timestamp recorded in the image itself as metadata (both GigE Vision and IP cameras can do this). I think the Basler IP cameras can use NTP and record the timestamp to the JPEG images as EXIF metadata that you could extract. This latter mechanism will of course be much more precise as it eliminates transmission delays/jitter from the time. If you have some requirements of precision (microsec, millisec, seconds?) it would probably give a better idea of what your options are.

 

I'd suggest taking a look at the line of Basler IP cameras. You can't control the image parameters directly within the IMAQdx driver (you have to use their web interface or write some extra HTTP code), but once you have the camera configured it will keep those settings.

http://www.baslerweb.com/en/products/network-cameras/ip-fixed-box-cameras

 

It is likely the cameras will be more expensive than some cheaper GigE Vision cameras may be, but I suspect you could save enough on other system costs going down this route to make up for it. I think trying to do on-the-fly JPEG compression with 350+MB/sec of raw camera data might be challenging unless you had a fairly beefy multi-core system.

 

Eric

Message 4 of 5
(5,336 Views)

That sounds like a good idea, Eric. I'll talk to the customer and go from there.

 

Thanks again.

Certified LabVIEW Developer
0 Kudos
Message 5 of 5
(5,272 Views)