Insufficient Transfer Engine Resources - Can't solve with packet size

[Jed_Davidow]

I have an app with 2 (eventually 3) AVT Pike 100C cameras and Vista with LV 8.6.  I am getting the Insufficient Transfer Engine error when I call Configure Acquisition on the second camera.

I have reviewed and tried the solutions in this thread, but I still get the error:

http://forums.ni.com/ni/board/message?board.id=200&thread.id=12460&view=by_date_ascending&page=1

Some notes:

These cameras have a FIFO, and I am using that to capture just a few images in a deferred image transfer mode.  So throughput is not important.

I have set each camera's bus speed to 400Mbps.  I have set each packet size to 1024 bytes.  The cameras are  daisy-chained on the only 1394 bus I have on this laptop

I have set the bus parameters both through the IMADdx driver, via MAX and by setting registers.  Each method appears to affect the others (that is, I can set the packet size via the enumerated interface, and see the result by reading the appropriate register on the camera).

 

[BlueCheese]

Hi Jed,

Are you using Vista 64-bit or 32-bit? There is a known issue that 64-bit Windows XP and 64-bit Vista changed the maximum single payload size of a firewire buffer to be ~1MB. If your Pike is using a sensor larger than this it would run into this issue. There is a workaround within the IMAQdx driver that will be in the next release. In the meantime, if you can change your acquisition ROI to be smaller it should fix the issue (if that is what you are running into).

-Eric

[Jed_Davidow]

Hi Eric.  Thanks for the suggestion.  I am running on 32-bit Vista, and I have not set an ROI since I need the entire image.

Should I try this on XP?  I will need to install LV/IMAQ but do you think that could be the problem?

[oliver.guennel]

Hi,

if you have the possibility, please use XP & downgrade the 1394 driver. The needed files & the description can you find under:

http://forums.ni.com/ni/board/message?board.id=200&message.id=19300#M19300

Under Vista, you can nevertheless run the cameras, but only with 100MBit and 1024Byte/packet in sum.

To do so, please set all cameras in MAX to 100MBit & give each a packet size of 512Byte (or 340 for three cameras).

We plan to release a replacement driver for the Microsoft 1394 stack soon. This will allow non-restricted usage of the cameras at full bandwidth, also under the Imaqdx driver.

[Jed_Davidow]

Ah.  I knew the Vista driver stunk, but I didn't know how bad...

[Jed_Davidow]

I have another question...

You can't tell from the image above (the code is in a subVI), but I am setting the bus speed and the packet size using the registers for the PIKE 100C.  However, when I changed that code I stil had the same problem.  To get it working, I went into MAX and changed the values there, then saved.  This worked.

So my question...

1) Do I need to set it in MAX and in the registers?  Do they have to match?  Does setting it in MAX cascade down to the register?

2) Can I get the same effect as changing it in MAX by using the IMADdx property node to change the values?

3) What's the difference?  This is a question that has been nagging at me- some of the camera properties are obviously for the camera (shutter) and some are for the driver (timeout) but some are hybrids (bus speed/packet).  How do I know and what is the best way to make sure they get set?

Thank you.

[oliver.guennel]

As I remember right, does the Imaqdx Configure Acquisition call the default settings, stored for the camera in Max. In your case does this overwrite the settings, done before.

So...

1) You don't need to set the Isospeed and bandwidth in MAX & in the app. In MAX is enough, the settings are stored to the camera ICD file and used in LabView.

2) The property node does has the same options as the GUI in MAX, so it can be used to set the same things in LabView. Just note, that any open camera, configure camera or snap does overwrite the settings with the values in the camera ICD file

The location of the ICD was described in this thread:

http://forums.ni.com/ni/board/message?board.id=200&message.id=18384&query.id=369821#M18384

Deleting the file is not recommended, I assume the camera won't work in LabView without.

3) IMHO: MAX settings are permanent, LabView settings are only temporarely until the camera is closed or initialized again. The best way to set & have a permanent solution is using MAX. This does also decrease the needed complexity of your VI.

[Jed_Davidow]

I agree that MAX has its place, but I find that when I am writing full applications (not just engineering code) that many end-users don't want to deal with MAX.  Add to that the debugging that's necessary when someone who doesn't know what they are doing messes around in there, and, well, you get the picture.  I mainly use Max as a debugging tool, and then try to incorporate as much as I can into the final user code.

But I have one more question, while I have your ear...

I am trying to set the Video Format, Mode and Color coding programatically.  I can set these with the dx property node interface (set active attribute, then set value to 0x09 for RAW8, etc).  However, the Tech manual says that RAW8 is set on register F0F08010 with value 0x09000000.  To arrive at that x09 value, I had to play around in labview to find the right setting.

Furthermore, I can read the mode via the register, but I can't seem to set it that way.  I can only set it through the dx property node interface.  I can set shutter via both methods but not mode/format/color.

I would like to use the Parameter List function to update several params at once, to quickly jump into another mode.  But when I write my 6 x 4-byte words to the list (and the ParamInfoByte returns 0x80030000), nothing is applied.

Is this the correct behavior?

[BlueCheese]

Hi Jed,

I'll try to give some more information to help you understand IMAQdx's behavior...

From the sounds of it, the problem you were encountering was that the bus speed and packetsize settings were set at values that did not work with two cameras acquiring on the bus. While you were setting the values via direct register calls, IMAQdx was overriding those values as soon as you configured the camera, making it still error. As soon as you changed the saved settings in MAX such that they agreed with the settings you were setting directly, the error presumably went away.

Firstly, IMAQdx has an internal state machine that expects to manage the registers on the camera that control packet size, bus speed, pixel format, etc. If you change any of those settings outside of going through IMAQdx's own attributes, depending on when you change things they will either get overridden when IMAQdx changes state or worse, could cause undefined behavior. The main idea is always use IMAQdx attributes to set anything it expects to have control over. The only things you should probably ever use direct register calls for are for camera-specific features that don't modify the format of the data the camera sends.

From what you've described and shown, it sounded like you tried setting some of the VideoFormat/Mode settings via IMAQdx's property control and had problems. One thing which you may not be aware of is that most of those settings are exposed as enumerations within IMAQdx. I believe some of those might not have fixed integer values, rather the enumerations are dynamically generated based on the list the camera supports (so a given camera model will always have the same value->mode mapping, but it will not be the same on another camera). Because of this you would be much better off setting those parameters using a string name which is fixed for a given mode. You can use the same strings that you see in MAX via the drop-down listboxes, or you can programatically enumerate the list of string/value pairs via LabVIEW. You basically set ActiveAttribute to set which atrribute to get/set, then set it via the ValueString item (instead of say ValueU32).

Finally, MAX isn't necessarily required for any usage of IMAQdx. What MAX allows you to do is save a snapshot of the camera's settings to a data file. These settings are then used as the initial defaults of IMAQdx attributes whenever the camera is next opened in MAX or any other application. This does give you a convenience factor in many applications because you can rely on MAX to do all the tuning of your camera settings and have minimal code in your application. Any settings that MAX saves can be set by the user using attributes via the property nodes. There is fundamentally no difference between settings loaded via MAX and any settings you set via the property nodes, expect that the MAX settings are loaded first upon opening the camera. You can also read/write camera files using VIs IMAQdx provides on the palette without using MAX. This could allow you, for instance, to have several camera configurations that you switch between within your application without having to put all that logic in your application.

Hope this helps and let me know if you have any more questions,
Eric

[Jed_Davidow]

Thank you for your excellent answer.  I figured that something like that was the case.  For our application, we are constantly changing just about every aspect of the acquisition, so using MAX is not really convenient.