Has anyone ever used coaxpress frame grabber with Labview?

[MGould]

Does anyone use this standard for Machine Vision?  If so what frame grabber do you recommend for pulling the video into Labview.

[Rscd27]

The first think we have to look out is if your camera and the bus supported by NI

http://digital.ni.com/public.nsf/allkb/4331B4AA3AE95233862574C200539A2F

[MGould]

Yeah, I first checked NI's offerings to see if they had a native solution, but it doesn't look like it.  I was more wondering if anyone had taken a 3rd party grabber and gotten it work with Labview.

[MGould]

Wikipedia Link for those interested in this new-ish standard:

https://en.wikipedia.org/wiki/CoaXPress

[Rscd27]

Thanks for the information, we have two drivers for vision systems IMAQ and IMAQdx the differences are listed here:

http://digital.ni.com/public.nsf/allkb/0564022DAFF513D2862579490057D42E

I am not completly sure if LabVIEW is going to be capable of recognizing this cameras.

Warm Regards,

Randy Cespedes

Applications Engineering

National Instruments

www.ni.com/support 

[b.ploetzeneder]

Looking forward to hear more about this, if you decide to use it.
After visiting the VISION last year, I'm convinced CoaXPress will win the race when it comes to high-performance interfaces (as opposed to CameraLink HS and 10GigE), mainly because of Genicam. - For that matter, I did experiment with a 10GigE cam.. and was pleasantly surprised that it worked Plug-and-play with LabVIEW.

You probably don't get around writing a wrapper for a third-party SDK at the moment. And this has definitely been done.. for example, by these guys http://www.lambertinstruments.com/hicam-fluo ..

[Rscd27]

Hello and thanks for the information,

We at NI appreciate this kind of information, I do not believe we have a released for a driver that supports the CoaXpress yet. I believe that maybe in the future it will be. I am also glad that the GigE worked properly.

I will let you know if I got any internal information.

Warm Regards,

Randy Cespedes

Applications Engineering

National Instruments

www.ni.com/support

[Rscd27]

LabVIEW works with third party framegrabbers but onlu witht the IMAQdx driver:

The NI-IMAQdx driver software is needed to use third-party image acquisition devices which use the following buses and standards:

• Gigabit Ethernet Cameras Supporting GigE Vision
• FireWire IEEE 1394 Cameras
• USB 2.0 Cameras Supporting Microsoft DirectShow
• USB 3.0 Cameras Supporting USB3 Vision

So any of this standards is going to work with LabVIEW and the Vision Acquisition software.

Warm Regards,

Randy Cespedes

Applications Engineering

National Instruments

www.ni.com/support

[b.ploetzeneder]

Well, just because NI officially only supports those standards doesn't mean we users don't occasionally make things happen.. 😉 

Actually, I'm expecting a few CoaXPress cameras with a tender I will run next year, different cameras, but hopefully only one kind of framegrabber.  I'm thinking about the following approach: I will use the third-party API and write a little TCP/IP program that pretends to turn it into a GigE - device. I don't need a lot from the framegrabber SDK: I need to be able to read the XML description file, and I need to be able to do register read/writes instead of using high-level functions.

Pretending to be a GigE cam when talking to LabVIEW isn't too hard, I've misused this interface before.
The IMAQdx driver doesn't need much: It sends a discovery ping, you answer. When you click on the MAX/open the device, it sets a locking bit. It reads out a few standard things .. heartbeat etc, but it doesn't verify anything, so you can send dummy data. Then it reads the GenICam description file. This one we also have from CoaXPress, so you can just send forward it and IMAQdx should have no problem parsing it. It also reads out some random registers.. You can either fake that (it doesn't check plausibility) or pass these readouts along via the SDK.
You configure grabbing, the driver sets up a few ports for a streaming channel and sometimes requests a test packet.  Then you start the grabbing (snapping with the NI drivers is an illusion.. just a single-picture grabbing) by setting the register specified in the XML file (OK, here you might have to modify the CoaXPress XML, I'm not familiar enough to know if CoaXPress does specify AcquisitionStart and stuff, but if not, I will just fake a start and stop and add it at the end of the file). Parameters gets and sets are simply forwarded, and that's it. You don't need more than that.
And that's my roadmap to get generic support for any CoaXPress camera. Will probably suck in terms of CPU load at the beginning, but it will probably be sufficient for plug-and-play / lab prototyping... and maybe one day there will be some official driver 🙂
Nice and fun project for a few rainy afternoons. It's a shame I don't have time for this at the moment.

@threadstarter: Keep us updated please.

[MGould]

b.p,

Awesome post!  Honestly I have no idea what we will do, we've never been sucessfull doing a wrapper for a 3rd party framegrabber. The product we build outputs HD-SDI video nativily and NI had no solution for us.  Luckly, for years we were able to use a framegrabber that implemented a directShow interface, but that option is going away because Mircrosoft and the frame grabber company is abandoing DirectShow.  NI didn't have any suggestions for implementing a wrapper for the SDK that came with the HD-SDI grabbers, but luckly a company called Pleora came out with some USB3 Vision compatible grabbers.