Debugging the Camera Link Interface on an NI-1473R and NI-1483R using Vision-RIO

Publish Date: Oct 19, 2012 | 1 Ratings | 5.00 out of 5 |  PDF

Overview

This tutorial will walk you through the steps required to use the Camera Link Logger tool (attached) to debug various issues involving the camera link interface on an NI-1473R or NI-1483R using National Instruments Vision-RIO examples as a base. This tutorial will teach you to log the camera link lines in a compressed form in order to be able to transfer them over a FIFO to be viewed/analyzed on your host machine. This should help diagnose pesky timeout issues and failed triggering as you will be able to view and run basic analysis on the raw data. This tool is NOT meant to be used with deployment code. It both takes up room on your FPGA and hogs a good portion of your data pipeline. You should use this to debug issues with your basic camera link lines and control lines.

Table of Contents

  1. Required Hardware and Software
  2. What You're Debugging and Why
  3. Adding the Logger to the FPGA
  4. Adding the Logger to the Host
  5. The Output File
  6. Troubleshooting and Next Steps
  7. Related Links

1. Required Hardware and Software

Required Software:

  • LabVIEW 2012
  • NI-IMAQ 4.7
  • NI-RIO 12.0
  • NI-FPGA 12.0

Required Hardware:

  • NI-1473R or NI-1483R

Back to Top

2. What You're Debugging and Why

When acquiring from a Camera Link camera, often the only lines you will be concerned with will be the Data Valid (dval), Line Valid (lval) and Frame Valid (fval) lines. These three lines determine when pixel data is sent back to the host. There are many configurations which require/allow the different lines to function in many modes. Some may function Active High, Active Low, or may be ignored entirely. This is dependent upon the camera specifications. The camera manual should be consulted to determine what these lines should look like for a given camera.

In addition to the basic three camera lines, you may be interested in whether or not the output from the card is valid. This example will show you how to include (using the existing Vision-RIO examples) an Output Valid Override. This boolean will allow you to log all values, regardless of if they are being used by the normal acquisition circuitry.

Finally, the Control Enable and Control Lines (1-4) are often of interest for triggering. Keep in mind that adding triggering is often as simple as wiring the appropriate TTL Line to the appropriate Camera Control Line.

Between all of these signals, the majority of timeout and triggering issues should be debuggable with a much greater degree of ease than before. Debugging the serial interface can be done using typical debugging techniques. Keep in mind that the FPGA bitfile must be running (including the Serial Server component) in order for serial communication with your camera to be functional.

Back to Top

3. Adding the Logger to the FPGA

The example application shows how adding a single VI with it's associated inputs and outputs is all that is required to begin logging the camera link lines. Keep in mind that these lines all operate on the same time base. If you attempted to log the serial lines, you would not be able to do so in the same timed loop as the lines being demonstrated. The subVI and it's associated blocks should be added to the primary acquisition loop in any Vision-RIO example.

The DMA references and override control are passed into the subVI. It then passes data back out for debugging. It will load compressed camera link data into the two FIFOs.

The FIFOs

Two FIFOs are required for the Camera Link Logger to function properly. As stated before, there's simply too much data to pass over in an uncompressed form. A simple compressor is implemented which counts how many ticks the FPGA iterates through until there is a change in the values. The count and data are then output in two FIFOs.

The FIFO configuration should be Target to Host - DMA with approximately 8000 elements

The data type should be a fixed point 32/32 value.

The Compressor

The compressor functionality performs simple counting logic to prevent duplicate consecutive data points from being sent over the bus back to the host. This provides many orders of magnitude of compression in the best case. In order for the compression to be effective, the signal must not change more frequently than every other tick. This is because we are using an extra 32 bits to send count information. If the values changed every tick this would mean we were sending double the information we needed (the count value would always be 1).

The compressor was written in VHDL and the code is attacked in the VHDL Code directory within the project.

Back to Top

4. Adding the Logger to the Host

The host side modifications will be minimal as we are not interfering with the existing architecture for acquiring images. Remember that the recommended image size is small (approximately 10 by 10 was used in testing) for use with the logger. This allows the signals to be easily counted and checked for consistency. This also prevents the data from taking up most of the pipeline. Timeouts will be received if your image is too large or your trigger rate is too fast.

Some helper functions are provided to make adding the Logger to any of our Vision-RIO examples as simple as possible.

An initialization function for the FIFOs is provided which configures and starts running the FIFOs. This should be placed in the same section of code as the rest of the FIFO initialization provided by our examples.

Another while loop should be added to your host side in order to process the output from the DMA. This while loop should call the CL Logger Init function in order to obtain a filename and initialize a global variable which contains the data. Then the loop will repeatedly call CL Logger Get Data (and display if desired) until execution is finished at which point CL Logger Close is called and the data is output to file. The data for even 30-60 seconds of acquisition should be no more than 1MB so storing it in RAM vastly simplifies the architecture. This should be modified slightly if the user wishes to acquire for longer periods of time so that the flush to the log file occurs repeatedly. This can be done with simple modifications to the CL Logger Close function to append to file.

Back to Top

5. The Output File

The output file produced by the utility will be a 2D array where the columns are delimited by spaces and the rows by new lines. The first row is the data while the second row is the counts for each point. This data can be read using any standard data processing and your own analysis can be designed to run. Additionally, a Camera Link Analyzer is provided and described in another Developer Zone Example.

Back to Top

6. Troubleshooting and Next Steps

The logger employs extremely simple logic so the only problems you will have are likely to come from managing the FIFOs. These FIFO issues can be debugged using standard FIFO debugging techniques. Some FPGA knowledge and experience will be required.

The Camera Link Analyzer will provide the bulk of the functionality for debugging. The only future work on the Logger should be the addition of extra lines which might be logged. The only other lines which may be of interest are serial lines which can be debugged via other means. A similar architecture could be implemented for serial lines if desired.

Back to Top

7. Related Links

Camera Link Analyzer

 

Back to Top

Bookmark & Share


Downloads


Ratings

Rate this document

Answered Your Question?
Yes No

Submit