Machine Vision

cancel
Showing results for 
Search instead for 
Did you mean: 

Insufficient transfer engine resources/ driver problem with Win7?

Hello everyone

 

I recently installed LabView 2009 on a new Win7 system. Next I tried to get a simple test VI running that simply takes image after image with the Ni-IMAQdx driver (using a AVT Stingray camera). It loops over the Snap sub-VI. But no matter what camera settings I tried at some point the VI will crash throwing the "Insufficient transfer engine resources" Error. This sometimes happens after 3 images sometimes after 30 or more images. Since there is really no other thing involved I would guess this is a Win7 driver problem. So does anyone know a fix for this or should I downgrade to WinXP?

0 Kudos
Message 1 of 13
(5,929 Views)

Ok I found the solution by myself.

 

The problem was with the Windows 7 Firewire Driver. The Solution is to activate the Legacy 1394 driver.

I hope this helps anyone who runs into this problem.

Message 2 of 13
(5,906 Views)

Hi,

 

I'm having the exact same problem. Thanks for guiding me in the right direction, but could you specify how you managed to install/use the legacy drivers? I cannot find them in MAX so I figure I haven't installed them yet. But I can also not find a download for it on the NI site.

 

Thanks in advance

0 Kudos
Message 3 of 13
(5,612 Views)

Hi,

 

We are tracking this issue internally as CAR# 285685. It appears to be a bug in Windows 7's new 1394 driver stack that others have reported here and here. Unfortunately there is no resolution that I know of from Microsoft at the moment. We are investigating possible solutions with Microsoft and hopefully we will have some better resolution in the future.

 

For anyone reading this post please note that the Insufficient Resources error can be returned for many other reasons besides this particular bug. If you are getting this error the first time you do a Snap it is unlikely to be related to this error. It is likely due to too many devices on the 1394 bus simulatenously reserving resources, or by using a larger packet size than is supported by the current speed of your device. The workarounds listed below should only be applicable if you are encountering the mentioned error when doing a Snap inside of a loop after multiple iterations (in-house we reproduced this only after 400 iterations)/

 

For now, there are several workarounds you could use:

 

- This is a problem related to reserving and unreserving 1394 bandwidth in a loop. When you do a Snap, this happens on every iteration. If you are going to be acquiring continuously, switching to a Grab will setup the camera/system in a continuous mode and let you retrieve the latest image at any point after starting it. This is a more efficient operation in general and would also eliminate the reserve/unreserve in a loop. You can check out the included examples that use a Grab.

 

- It appears that Microsoft still ships the old legacy 1394 driver with Windows 7 that you can optionally use. Please note that "legacy driver" here refers to Microsoft's legacy 1394 OHCI driver, not NI's "Legacy 1394 driver" (aka "IMAQ for 1394") that was supersceded by IMAQdx several years ago. Both IMAQdx and the NI Legacy 1394 driver sit on top of the Windows OHCI driver for the 1394 controller chipset in your PC. Switching back to Microsoft's legacy OHCI driver has not been tested by NI but has been reported to fix this particular issue by others. Note that it is quite possible that other bugs present in the older version (such as the inability to use speeds over 100/400Mbit) may still be present in the legacy driver. I found a good post showing how to switch to the legacy OHCI driver here: http://kc.flexradio.com/KnowledgebaseArticle50433.aspx

 

Once again, I apologize for this issue and wanted to let you know we are working towards a better resolution.

Eric

 

 

Message 4 of 13
(5,590 Views)

For anyone else tracking this issue, it is issue KB363689 with Microsoft. There is no public fix out yet but one is expected at a future point in time. Until then, you can try any of the several workarounds listed above.

 

Note that there is also another issue with doing a Snap in a loop with FireWire cameras on Win7 that can cause a memory leak -- http://support.microsoft.com/kb/982669. The hotfix provided in that article appears to already have been rolled into the recently released Windows 7 SP1 so you should not need this particular hotfix.

 

Eric

0 Kudos
Message 5 of 13
(5,474 Views)

To anyone following this thread, Microsoft has just released a hotfix for Windows 7 that addresses this particular issue: http://support.microsoft.com/kb/2524249

 

Eric

0 Kudos
Message 6 of 13
(5,329 Views)

I'm seeing the same problem with win7. This legacy issue also occured with WinXP, for which there was a roll-back hotfix to address.

 

Another issue we are seeing in MAX, is that it makes no consideration for multiple cameras running simultaneously. So it allocations nearly full packet size for the selected camera bandwidth. As you cannot grab from two devices at once in MAX, you see the problem until you code dual-camera acquire in LabVIEW.

 

To run two cameras, you'll need to manual decrement the packet size, something like 4096 in Max. It slows down the frame rate.

 

It would be also nice to see some confirmation in MAX if the adapter is 1394A or 1394B, We have a 1394"B" interface, which should be faster, but not sure if MAX is properly 'seeing' it's a "B" adapter via it's connection to the windows driver. This could be a win driver issue or MAX, but impossible to tell.

 

By tweaking the packet size, we are getting two 2440x 2028 cameras acquiring simultaneously in LabVIEW. (without the win hotfix mentioned in the post above)

 

Regards

Jack Hamilton

0 Kudos
Message 7 of 13
(5,281 Views)

Any updates regarding this issue?  I just ran into the problem on a machine running Windows 7 32-bit service pack 1.

Robert Eastlund
Graftek Imaging, Inc.
Phone: (512) 416-1099 x101
Email: eastlund@graftek.com
0 Kudos
Message 8 of 13
(4,965 Views)

@Robert Eastlund wrote:

Any updates regarding this issue?  I just ran into the problem on a machine running Windows 7 32-bit service pack 1.


Hi Robert,

 

Just to confirm, you are seeing the insufficient resources error after a while of configuring/unconfiguring in a loop?

 

Currently there are three ways around this:

- Get the hotfix from Microsoft (http://support.microsoft.com/kb/2524249) which fixes the issue (as of today this is not yet in a service pack from Microsoft. Pehaps it will be in a future one)

- Switch to Microsoft's legcy OHCI driver for the 1394 chipset. This is the identical driver from Microsoft as what shipped in Vista/XP. This does not have this particular bug but it does have the same legacy issues of not properly supporting the 800Mbit speeds of 1394b.

- Refactor your code to not continuously re-allocate firewire resources. The problem only shows up when resources are continuously allocated and free'd. This occurs if you do something like Snap in a loop or Configure/Unconfigure in a loop. If you do a single continuous acquisition then you should not run into this issue unless your application is started/stopped many times.

 

Eric

0 Kudos
Message 9 of 13
(4,956 Views)

Eric, 

 

It seems MS took the hotfix download away. What happened? I was going to try the hotfix and see if it solves the issue. 

0 Kudos
Message 10 of 13
(4,891 Views)