Image-aquisition with LabView2020 for Linux from a GigE Camera

[Yaw Mensah]

I am trying to read images from my Gige camera, but on LabView Linux Imaqdx is not available. So i tried wrapping the vendors Gige implementation.

But i had some problems regarding  passing handles and the callback function to receive the images. If someone have experience regarding image- aquisition without imaqdx or

know a different way, i would be grateful for your suggestions.

[Rolf Kalbermatter]

38 minutes ago, Yaw Mensah said:

I am trying to read images from my Gige camera, but on LabView Linux Imaqdx is not available. So i tried wrapping the vendors Gige implementation.

But i had some problems regarding  passing handles and the callback function to receive the images. If someone have experience regarding image- aquisition without imaqdx or

know a different way, i would be grateful for your suggestions.

Data buffer handling and especially callback functions really requires you to write an intermediate shared library in C(++) to translate between LabVIEW and your driver API.

Memory management in LabVIEW has some specific requirements that you need to satisfy and usually goes against what such drivers expect to use. They are written with C programming techniques in mind, which is to say the caller has to adhere to whatever the library developer choose to use. LabVIEW on the other hand is a managed environment with a very specific memory management that supports its dataflow paradigma. There is a clear impedance mismatch between the two that is usually best solved in a wrapper library in C that translates between the two. While it is possible to avoid the wrapper library here, it usually means that you have to both implement the proper C memory management as required by the driver and additionally deal with things that are normally taken care of by the C compiler automatically when you try to implement the translation on your LabVIEW diagram directly. It's possible but pretty painful and gets very nasty rather quickly and results in hard to maintain diagram code especially if you ever intend to support more than one target architecture.

As far as callback functions goes, anything but a wrapper library written in C(++) that handles the callbacks and optionally translates them into something more LabVIEW friendly like user events, is simply inventing insanity over and over again.

Edited January 21, 2021 by Rolf Kalbermatter

[ensegre]

If the only way of commanding your camera is through the vendor sdk, bleh. As Rolf wrote, though YMMV.

If by chance the camera is supported by v4l2, there you go; shameless self ad.

 

[Yaw Mensah]

How about using a named Pipe to transport the images?

[dadreamer]

I have used PostLVUserEvent Manager function for a few times in my own callback libraries to send the video/image data from the framegrabber into LabVIEW. It was always working fine for me. I'm sure, back in the days I have used this code sample as the base for interaction with a callback DLL. On Linux you may use dlopen (instead of LoadLibrary) and dlsym (instead of GetProcAddress) from \usr\lib\x86_64-linux-gnu\libdl.so to pass your callback into the vendor's API.

Edited January 21, 2021 by dadreamer

[Rolf Kalbermatter]

18 hours ago, Yaw Mensah said:

How about using a named Pipe to transport the images?

What would the named pipe achieve? How do you intend to get the image into the named pipe in the first place? If you need to write C code to access the image from the SDK and put it into a named pipe in order to receive it in LabVIEW through the Pipe VIs, you could just as well write it to disk instead and read it through the LabVIEW File IO functions. Functionally it is not different at all, while the File IO is million times proven to work and the Pipe interface has a lot more potential problems.

If your SDK driver has a way to simply put everything automatically into a pipe then it may be worth exploring but otherwise stay far away from this. Any effort in writing C code anywhere is better spend in creating a wrapper shared library that massages the driver API into something more suitable to be called through the LabVIEW Call Library Node.

[Yaw Mensah]

I want to write a c application the acquire images send it to the pipe. On the orther side of the pipe, i would than use  the  read.vi to read the images in labview.

[Yaw Mensah]

There is an example application that acquires an image and streams it to the display. With minor changes i could send those images to the pipe.