Using a frame-grabber in linux

[WibJ]

Hello vision folks,

I did look at the following framegrabber 1473R-LX110 user manual.

It uses both NI-DAQMX(2.8) driver as well as NI Flex RIO driver (13.0).

I want to use it on Linux, since IMAQ isn't availible here is what I'm thinking.

1. Set up a windows machine with IMAQ + NI RIO to develop the FPGA code and create the bitfile, and establish my own FPGA to host interface function calls the NI RIO driver.

2. Set up a linux machine and leverage the FPGA Interface C API to create my own interface to get the data out of the framegrabber on the Linux system.

Do you think this has a chance of working ?

Thanks,

WibJ

[BlueCheese]

I'm pretty sure this won't work. Even if the base FlexRIO driver is supported on Linux, I don't think the various other pieces needed for the 1473R module would get installed. It is definitely not a tested scenario.

Can you describe your use case a bit more? If you aren't actually using the 1473R for on-board FPGA processing, it might not be the best fit anyway. Not that there are any IMAQ frame grabbed boards with Linux support though...

[WibJ]

I was considering passing the data out of the framegrabber to a GPU for additional processing.

The ultimate goal of builing a Real-Time control applciation, using a Linux kernel with PREEMPT_RT patch.

The concern is that the framegrabber's virtex-5 isn't powerfull enough to deal with the processing required, and going down the PXIe route will put a too high price tag on the system.

Thanks,
WibJ

[BoKnows]

I'd probably take an entirely different approach.  If this is something that MUST be on Linux, I'd look at sensors more so than cameras.  There are quite a few of these devices that don't adhere to typical camera bus protocols.  You can find a camera that connects via USB and comes with a shared object library.  Once you have that, you can build wrapper VIs around the functionality (and likely, the camera provider has already done this.  Thorlabs is a good example of a company that does this with their devices for Windows.  I'd have to check for Linux).  With those VIs, you could acquire the images without using IMAQ as you'd be running other calls to interface directly with the sensor.

Once you've removed IMAQ from the equation and aren't trying to hack your way into another framegrabber working, you're at a better starting position.

Are you bound to a camera or still in the pre-purchasing stage where you'd have the option to make this kind of jump?  If you're worried about processing, that's the point you could look to bring in your FPGA portion.

Beyond that, the 1473R isn't a FlexRIO.  It wouldn't be supported by the FlexRIO drivers in the first place.  It's supported by the R-Series drivers.  If you're wanting to look at anything that uses the FlexRIO software/hardware, you're using the PXIe solution you've already mentioned is something you'd like to avoid.

[WibJ]

Gents thanks for the replies.

This is a bit confusing if you look at the first page of the user guide and specifications for 1473R ( which I've liked in the OP )

You will see that NI FlexRIO 13.0 or later driver software is part of the required software. If it's not a Flex rio why do you need the FlexRIO driver for it?

I couldn't find 1473R on the R-Series list either  ... dunno maybe I'm not looking right. So I guess I'm outta luck.

I have worked with NI FPGA before so I was hoping that by using the FPGA node in LabVIEW ( or the C API )  I could work directly with the bitfile to roll my own interface to the Host PC bypassing the need for IMAQ.

In terms of selecting the HW we got a system going allready with Windows installed that does all the processing and works with the current HW, we want to give a shot at taking it real-time to add the capability of being a Control applciation.

The only way I see posisble I'll get an NVidia GPU & the NI HW working together is Linux with PREEMPT_RT patch applied to it. WxWorks or Pharlap are a no no for getting NVIDIA drivers to work.

Originally I was hoping to be able to use the HW I got, and use the NI Linux_RT. 

However that isn't supported, and none of the PCIe drivers exist for it.

My second option was to go with Desktop Linux, hope to find drivers, patch the linux with PREEMPT_RT myself and get it to work... but it sounds steep.

Now I feel I got 3 options left, 2 of them are to stay within the supported NI Toolchain, and the thrid one is an adventure.

1. Try and see if I can do squeze the processing I need on the 1473R.

2. Use a PXIe powerfull FPGA with a framegrabbing adapter module.

3. Forget about NI SW / HW in this case and try my luck with PREEMPT_RT Linux and hope I can get all them drivers workin' on my own.

The only issue is that option number 3 feels like going to cllimb mount Mount Everest with flipflops & sunglasses, solo without even telling your mum, you'll be late for dinner.

Thanks,

WibJ

[BoKnows]

That's interesting.  I'm not sure why they require the FlexRIO drivers rather than the R-Series.  I'd be guessing as to an answer.  But, it is likely due to the device being a bit different than either the FlexRIO or R-Series family.

It sounds like 2 of the 3 options are a bit of an adventure.  If there's any question as to whether or not you can handle all the processing, you'll likely run into quite the adventure optimizing your code to get it to fit or throw your arms up in frustration.

Do you have any other hardware readily available?  What are you hoping to control?  Looking at this card, there's a potential 4th option.  With the addon DIO card, you could send digital output to another device, hopefully the one you're looking to control.  Would that be less of an adventure?

[BlueCheese]

The 1473R is a Vision board, so it doesn't really come from the R series or FlexRIO familiy line (though obviously is built using the same technologies). It is meant to be code compatible with the NI 1483 FlexRIO module, but optimized for deployments that don't need PXI or FlexRIO. For historical reasons, it shares the core driver support from FlexRIO.

I'm honestly not too familiar with the level of Linux support of FlexRIO, but there are additional pieces for the 1473R that don't get included in their installer (only via Vision Acquisition, which is Windows and Pharlap RT-only for the 1473R). It might be possible to manually copy over various installer pieces from Windows over to a Linux system but I think it will be tough without support from NI or some desire to do some deep sleuthing yourself. The lack of official support may be an obstacle if you are looking to deploy a solution and not just prototype. You may want to discuss your Linux support needs with your local NI sales folks so possibly in the future native Linux desktop support might be possible.

Eric

[AmitShachaf]

Hi WibJ,

I am using this frame grabber as part of controll application.

LX110 is fairly large FPGA.

We have started our application with PCIe-1473R and did with NI the devlopment of the PCIe-1473R-LX110.

Depends what you need to do. But the latency in the system is much smaller if you don't need to use GPU for extra processing.

Transfering the data from the FPGA to the GPU is a major bottle neck.

There is space for a lot of code on the PCIe-1473R-LX110.

I would suggest to take the same approch that I did.

I first implamented the whole system on RT-System. Only then transfer the implamentation to FPGA.

I would suggest to try to implament on Window.Lynox will be hard.

[WibJ]

@ BoKnows and Amit:

Yes, if I could fit all the processing on the card with the DIO extension that would definetly be the best option. There are many advantages.

The solution is cheap, no latencies a LOT less complexity 

I think I could handle optimizing I've allready spent hours of my time on figuring out resource issues and those cute timing viloations on other projects 🙂 the only question is is the Virtex - 5 up to the challenge ... this is where I have my doubts, but this is a question that I think I should try to figure out the answer to first.

@BlueCheese

Your post gives me hope that even though this isn't tested I could potentially hope the RIO interface to extract the data out of the grabber on linux potentially using my own API bypassing the elements required by IMAQ. Obviously I'd have to try to find out in practicce... I was kind of hoping someone on this forum has tried this allready and can tell me it worked or din't.

[AmitShachaf]

Hi Wibj,

If you are devloping OEM solution were you will be distributing handreds of systems (like I am doing) then going with the LX110 is a good way. Specially for control application.

If you are doing only couple of systems you probbly better with RT Vision system.

LX110 has space for a lot of code.

RIO interface doesn't work on Linux to my knowlage.