FIFO overflow using PCIE 1429 on a windows 7 64bit system

[odedbd]

Update:

We tried the 1429 card on a new machine our neighbours from the lab next door just bought, and verified that it is working well on a GA-EX58-UD3R rev 2.0 (gaming edition) machine:

http://gigabyte.com/products/product-page.aspx?pid=3449#ov

We want to buy the GA-EX58-UD3R rev. 1.7, that has an extra PCI slot on expanse of one PCI ExpressX1 slot, which is preferable for our needs:

http://gigabyte.com/products/product-page.aspx?pid=3265#ov

We are guessing that since these are virtually the same motherboard it should work, but if anyone can verify this it'd be of great assistance.

Thanks!

[Kristoff2]

odedbd,

The two motherboards you listed use the same chipset so if it works on the GA-EX58-UD3R rev 2.0 it is likely it will work on the GA-EX58-UD3R rev. 1.7.

Regards,

Sam K

Applications Engineer

National Instruments

www.ni.com/support

[henryz]

This seems like the appropriate forum although I am experiencing FIFO overflow with a PCIE 1433 rather than a PCIE 1429 (I'm the 'Me too' in the first discussion):

I have a PCIE 1433 frame grabber that worked beautifully a few months back.  Recently, it mysteriously started generating constant FIFO overflow errors.  In other words, it is now unusable.

I did recently install IMAQ 4.6.1 via VAS_September_2011, however I have another (much slower) lab computer that I also updated VAS on that does not have any issues with the same 1433.

Windows 7 Professional

Xeon CPU

X5650 @ 2.67GHz

12-core

Are there any logs or other configuration files that could shed some light on this?

Thanks,

Henry

[BlueCheese]

---

@henryz wrote:

This seems like the appropriate forum although I am experiencing FIFO overflow with a PCIE 1433 rather than a PCIE 1429 (I'm the 'Me too' in the first discussion):

I have a PCIE 1433 frame grabber that worked beautifully a few months back.  Recently, it mysteriously started generating constant FIFO overflow errors.  In other words, it is now unusable.

I did recently install IMAQ 4.6.1 via VAS_September_2011, however I have another (much slower) lab computer that I also updated VAS on that does not have any issues with the same 1433.

Windows 7 Professional

Xeon CPU

@X5650 @ 2.67GHz

12-core

Are there any logs or other configuration files that could shed some light on this?

Thanks,

Henry

---

What size images are you using? There are certain combinations of parameters that could cause the transfer to be more or less efficient (like the image width). Also, double-check your power-savings settings on the PC. Certain power-save items could cause delays in data transfer that can cause overflows. Try setting your PC to the "max performance" profile and see if that changes anything.

Eric

[henryz]

2040x2048@187Hz (781,271,040 bytes/sec).  The 2040 image width does stand out here (the imager will not allow 2048x2048).

The reason I was unsure that this was pertinent information was that it all worked perfectly before I updated VAS.

(per your guidance in a separate discussion thread related to the x64 version of clsernat).

By the way, thank you again very much for your assistance with that!

I seems that I can run 2040x2048 resolution in MAX ver 5.0.0f1 on two other systems, so I'm going to rule that out.

I'll try all of your suggestions, but am baffled as to why I can run the same 1433 on three different systems

(all running IMAQ 4.6.1 with the same Windows settings) and only my 12-core system seems to be adversely affected?

It might also be important to note that I am also experiencing a handful of errors related to serial problems.

These errors are all related to serial timeouts and baud rate failures (using the 32-bit version of clsernat with Pylon).

I can verify that clsernat is NOT the culprit here, as very low serial rates will work.  It all seems to be related to the PCI bus.

Could IRQ conflicts be a culprit?  That is what I'm leaning towards, although I'm unsure how that could have changed?

Henry

[BlueCheese]

If you change the width to 1984 does it help? This is the next multiple of 64-bytes down from 2048.

Eric