LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

UART protocol and Camera+IMAQdx

Solved!
Go to solution

Hello everyone

I have a general question about whether it is possible to use IMAQdx if I connect the camera to the I/O ports, and read the data using the UART protocol on the FPGA?

What I mean is that so far I have done it classically, that is, I have used the IMAQdx Open Camera block and looked for the port to which it was assigned. On the other hand, I guess that in my case the camera will not be detected in MAX.

Is my concept feasible?

0 Kudos
Message 1 of 6
(331 Views)

The reason to use LabVIEW and IMAQdx to access cameras is that the fairly complex/complicated communication with the camera to handle the control of the camera (using a defined protocol such as GenICam) and handling the (sometimes messy) details of organizing Image data in computer memory are handled by IMAQdx, so that LabVIEW can deal with high-level concepts such as acquiring and manipulating Images (including saving them to disk in various standard formats.

 

My own experience with LabVIEW Vision came after several years using LabVIEW for DAQ tasks, including learning LabVIEW Real-Time.  Becoming facile with LabVIEW Vision took another few years (though I did have a colleague who had done some Vision work for several years before I was asked to "join the team" (making two of us).

 

From your description, I cannot say that I understand what you want to do, but my best guess is it will take a long time to learn if it can succeed.

 

Bob Schor

0 Kudos
Message 2 of 6
(277 Views)

yes the signals are definitely triggered by the motion activated camera. So you suggest its a GPIO instead of a UART? I don't see any similar pin outs on the board

0 Kudos
Message 3 of 6
(257 Views)

You are talking in very general terms like UART and GPIO. They mean not much without some real context. UARTs typically are serial communication standards most often transferred through RS-232, RS-422/485 or similar electrical interfaces. They in themselves are not really suited to transfer the amount of data that image cameras usually have. But cameras can have an UART interface too, which allows to communicate with them on a side channel to query or change their settings. If your camera has that or not depends entirely on the model.

GPIO is even more general but in many cases also not really high speed enough for image data transmission. Typically you have specific communication interfaces, for instance Firewire, CameraLink, USB3 or GigE for external interfaces, and nowadays MIPI for internal interfaces. They are anything but GPIO, but instead very specific and dedicated interfaces. The main function of all these interfaces is to transfer image data in high speed but they generally also support embedded side channels for communication with the camera itself to change their settings.

 

The whole technology is highly complex, varies greatly between different interfaces and definitely not a project to get started in FPGA development. Most people who are in the know about this would rather try to avoid having to deal with it themselves.

 

From what you have disclosed so far, it would seem that you have a quite limited idea of the complexity and the specific interfaces your camera uses. Without more detailed information about these things all you can receive are very general statements about that it is complex, most likely not what you want to deal with and almost certainly much cheaper to buy a ready made solution for what you want to do.

Rolf Kalbermatter
My Blog
0 Kudos
Message 4 of 6
(250 Views)

My question comes from the fact that I have mastered/written the I2C and UART protocols on an FPGA. As a result, I can now freely manipulate the devices in a way that I can understand. On the other hand, I made some time ago an elementary program for reading images from cameras, and it appears suddenly I am fighting with errors that were not there before, and I have not changed anything in the circuit. That's why I wanted to buy a camera with such an interface, which I already know how to use, and not to play with detecting devices in MAX, but to connect to specific ports and connect through FPGA, and then send data further by HOST.
The question is, will I then be able to use the IMAQdx library?

 

0 Kudos
Message 5 of 6
(242 Views)
Solution
Accepted by topic author spalinowy

@spalinowy wrote:


The question is, will I then be able to use the IMAQdx library?

 


No! IMAQdx is a driver in itself that knows a certain amount of hardware interfaces, namely USB3, GigE, NI-1427/143x CameraLink boards, NI-178x  Smart cameras, Firewire (not anymore since IMAQdx 20.0), 

 

https://www.ni.com/pdf/manuals/vision-acquisition-software-2023-q1.html

 

IMAQ I/O Driver lets you reconfigure selected NI FPGA hardware to specific camera interfaces but that is not trivial at all. I2C or similar implementations in FPGA are quite trivial in comparison.

 

While I2C or UART may be an option for some cameras to program their configuration, the image data transfer for sure will not happen over that interface. It would not be able to transfer much more than a poststamp sized image with more than a few images per second.

 

Rolf Kalbermatter
My Blog
0 Kudos
Message 6 of 6
(231 Views)