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

[Jed_Davidow]

Hold on a minute...

Last night I dealth with issue after issue witht he cameras and the driver...

Soe does the dx driver ALWAYS overwrite the camera settings with the "saved" MAX values every time I call Configure?  So If I set up my camera \, run an acquisition, then stop it I will need to reprogram everything when I want to run again?  Is there any way to avoid it?

In my app I am setting:

Gain

Shutter

Trigger

Trigger Delay

White Balance

Pixel Format

Video Mode

And a bunch of other options on the camera that aren't revealed in MAX.

Do I need to re-write these values every time I want to restart my acquisition?

Also, if the camera registers are not in agreement with the NI driver, what does that mean?

Yesterday, I got everything working on my system.  Then I transferred the code over to another PC.  I could not get some of the triggering to work.  I then copied the ICD and IID files over to the new PC and still had the same problem.  I then loaded the AVT driver and checked in SmartView, everything worked and was set correctly on the cameras.

So I reloaded the MS driver, downgraded and then checked MAX.  Everything looked good.  Still not working.

Then I put the cameras back on my laptop, where they had been working perfectly.  My laptop would not recognize the first camera in the daisy chain.  Windows would sound that "error" bong you get when it can't load a driver or something.  We had to swap out the camera.

So...

1) Is there a way to prevent MAX from reloading the driver with fresh values when I call configure?  Is there a way to avoid using configure after an acquisition is stopped?

2) If I run the same code on top of the same ICD files, why would my cameras have any different characteristics under different copies of windows?

3) Is there a good methodology for moving the code/settings that does not involve setting each setting in MAX?

4) It appears that some functions must be called ahead of the configure call, and some after (Trigger options before, shutter/gain after so they aren't overwritten).  Is this true?

I am frustrated.  I am ready to chuck IMAQdx and code in the native driver.

Can anyone point me to a thorough document that will help me understand the dx driver?  There's a lot on the site, but a lot is not that deep.

[BlueCheese]

Jed,

Sorry to hear about your frustration. Firstly, the "saved" settings from the camera file are loaded into IMAQdx's attributes _only_ on opening the camera (or when told to explicitly load settings from a file). Next, all of IMAQdx's attributes that control operations on the camera are written into the camera at various points in its internal state machine. As long as you interact with the IMAQdx attributes rather than direct register accesses into the camera, you won't get any settings overridden.

All the settings you listed (Gain, Shutter, Trigger, Trigger Delay, White Balance, Pixel Format, Video Mode) are all features that IMAQdx expects to control via its attribute system and expects the user to not use direct register access to control. IMAQdx will take care of writing the registers at the appropriate time. If you are bypassing IMAQdx's state machine and write those settings directly via registers you'll probably encounter IMAQdx overridding settings.

Eric 

[Jed_Davidow]

Thank you for the quick response.  So here's a specific issue...

I am using the Advanced Trigger Delay to set the delay.  This is Register 0xF1000400 (I think, the code's not open right now).  On our Pike camera, I believe that the camera will use this over the std Trigger Delay (which is set through dx) if it is written AFTER the std one.

I incorporated this into my trigger subroutine; so I use the property node to set Trigger Mode, Polarity, Timeout and Delay.  Then I call and set the register.

I have found that I will get an error if I call the Configure BEFORE the Trigger property settings, but that when I do call the Configure, the F1000400 register is zeroed out.

I can post code later today or tomorrow.

Is this supposed to be happening?  Is the Configure function supposed to affect any settings?

[BlueCheese]

Hi Jed,

Remember I said that IAMQdx uses a state machine to decide when to write registers. When the camera is not acquiring (or about to acquire) all the feature control attributes operate on cached data structures rather than directly manipulating the registers. During the Configure step, those values are flushed to the camera (along with other settings needed to setup the camera). So even if you set the property nodes first, it will not necessarilly be set prior to your register operations. If you provide a snippet of code, what you are doing may become more clear.

Since the Pike's 0xF1000400 "Trigger delay advanced register" is custom, IMAQdx does not touch this register. I am guessing that the Pike is clearing that register because settings are being written into the standard Trigger Delay feature. I would expect that if you configured the trigger delay advanced register _after_ the Configure step, it should allow you to get what you expect, but this is purely up to the camera's implementation as to how those registers interact with each other. You would probably have a much easier time if you used the standard feature. When in Absolute mode I would think it should have almost the same resolution capability as the microsecond delay provided by the custom feature. Is this not the case?

Eric 

[Jed_Davidow]

I hope you guys are still out there.  I have been getting good support from AVT directly over AVT issues, but the rep does not have a lot of experience with the NI driver.

I have 2 issues now...

#1 is bus speed

I tried to set the three cameras up with S800 bus + 2048Byte packets.  One camera always errored...

I have the three cameras capturing to the FIFO in parallel.  They don't actually acquire in parallel, but the code is waiting in parallel.  I poll the cameras individually to see the number of images in the FIFO.  when all the shots are there, I call SEND N for that camera and then read each one into a loop using NIdx Get Image.  The first camera will start to send images on the bus right after it's done, then the second, then the third.  Always in the same order (due to HW triggering).  What I have noticed is that unless I set the packet size down to about 512Bytes, when the third camera starts to send images it will cause the second camera to error and lose 1+ images (the higher the packet, the more images lost).

So I serialized the code so that none of the image transfer is in parallel.  This works.  No errors.  I can set the packet back up.  However, now we are not utilizing the bus completely.  since all three cameras are configured at the same time, the dx driver will error whenever I "overclaim" the bus.  Is it possible torun the cameras in FIFO mode, then release the bus so that I can transfer the images at full speed from each camera serially?  It seems that stopping the acquisition (not necessarily erasing/closing) clears the FIFO.

#2 deals with the quick config mode.

We want to acquire 10-15 images in MONO and then get one image in RGB.  All via an external trigger, and all triggered very quickly.  The AVT rep says I can use a quick config mode on the Pike100C; I could pre-program each frame's shutter/Video mode and White balance separately.  Will this work through the dx driver?  I tried using the batch register mode and it did not seem to overwrite the settings I had previously made through the enumerated interface.