FIFO errors with 1433 and IMAQ 18

[SWIR_cameras]

I am still seeing this bandwidth limit around 410 MB/s causing FIFO errors in a LV runtime, or under MAX using IMAQ 18.0.  Is anyone aware of what is imposing this limit?  The hardware works fine under 17.0. 

[SWIR_cameras]

I've had the opportunity to test this issue with NI-IMAQ 19.0 under a Win 10 Pro OS.  The bandwidth has been further reduced to about 205 MBytes/second.  The 2048 pixel camera with 1000 lines per image becomes limited in MAX to only show ~50 fps second or 50,000 lps.  If I slow the camera to below that rate, MAX acquired fps value follows as expected.  Any faster camera rate only reports 50 fps. If I narrow the image width  to 1000 pixels for a 1000x1000 images acquired, the maximum fps doubles confirming the limit is the MBytes per second.

We now have a customer in China reporting getting FIFO errors with NI-IMAQ 17.1 and with 19.0.

[BlueCheese]

In MAX you can see the PCIe link speed/width negotiated. Can you confirm that the 1433 has negotiated a x4 PCIe connection?

[AmitShachaf]

Hi 

I have notice similar issues when trying to operate my camera Basler acA2000-340km on the 1433.

I was not getting the frame rate I was hopping for from the NI example.

NI Examples are not written to support this speed. 

What I did was to implement Frame Skip on the images sent to the display.

Acquisition still was working full speed. But I was sending to display only 1/30 images. 

I am mostly doing  this solution on the 1477. But I also have 1433 and it is the same principal.

[SWIR_cameras]

The IMAQ 19 machine requested x4 but only received x1 PCIe lanes.  This does explain the bandwidth limit in this case but not for IMAQ 18.

See attachment for MAX display of 1433 and software load, for the IMAQ 19 case.

[SWIR_cameras]

Note that MAX reports frames per second displayed and fps acquired.  The Windows OS is not a real-time OS and there is a fair amount of processing for the images that are displayed on the screen.  The acquired data is what is received in the buffer ring without any processing or memory moves.  If the acquired fps  x image length x image height match your camera's output rate but the displayed fps only shows a fraction of that, it is an indication that the data flow exceeds the ability of the system to display the data. 

[SWIR_cameras]

To BlueCheese - The file name attached to my previous reply has an error but there is no provision for editing an old post.  The file name should have read "NI_IMAQ 19.0 1433 only receives 1 lane.docx"

I have rebooted that computer but MAX still shows only 1 lane negotiated.  How can this be reset to 4 lanes?  The computer is a Dell Precision 7820, a very capable tower with full bi-directional PCIe lane support.  The 1433 was installed in this Tower since last year and used with similar cameras. 

With regard to the PC with the IMAQ 18 installation that was the original basis of this thread.  A new OS security update was executed Tuesday and the 1433 was not listed in Devices and Interfaces after the re-boot.  I powered down, jiggled the board in its position and re-powered the PC.  MAX showed x4 lanes negotiated and was able to acquire at the full camera rate.  Is it possible that the frame grabber only negotiated 2 lanes of the 4 in the prior case?

New issue with IMAQ 18, MAX 18:  MAX seems to be scaling the camera values down by 8x.  In the screen shot in the file attached to this post, the camera is outputting a test pattern ramping from 0 to 4094 across the 2048 pixels of the linescan camera.  The histogram shows pixel values to 255, and the Show Tools Info displays the cursor X/Y position near the bottom right corner of the image, with a value of 255.  The settings show that the MAX Image Format is correctly set to 12-bit Mono, matching the camera bit depth.  The LUT control is set to Normal and its  other settings don't seem to affect the intensity scaling.  With our LV executable program, we see the normal camera values in the images and histograms.

Is there another setting that is telling MAX to scale the digital data down by 8x?

[BlueCheese · Accepted solution]

The PCIe lane width is decided on boot time by the BIOS/firmware and is not able to be affected by any software on the system. Have you tried putting the card in a different slot? The marketing materials for that system note that it has several slots that are x16 mechanically, but are only wired with smaller numbers of lanes:

2 PCIe x16
1 PCIe x16 wired as x8
1 PCIe x16 wired as x4
1 PCIe x16 wired as x1

[SWIR_cameras · Accepted solution]

The issues discussed in this thread appear to be resolved.

The case with IMAQ 18 seeing FIFO errors above ~405 MBytes/sec cleared up after a corporate security update - which also delisted the 1433 from MAX.  After re-inserting the board in its slot the card was again listed and the full line rate was restored.

The case with IMAQ 19.0 on a new computer was resolved by BlueCheese's note that the computer model had 1 slot that only supported 1 PCIe lane back the to PC.  Moving the board will resolve this issue.

A third case, where a customer reported the FIFO error in both IMAQ 17.0 and IMAQ 19.0 was found to be a lane restriction to just 2 lanes.  Moving the card to another slot enabled support for 4 lanes and the full data rate of the camera.

Thanks to the NI team, both on the Forum and in Vision Product support for helping troubleshoot this issue.