watching for dropped frames while grabbing sequences...

[...]

hello to all -

I have a question on using this function -
imgGetAttribute (sessionID, IMG_ATTR_FRAME_COUNT, &frameCount)

and how it may relate to an .icd file parameter.

I made an .icd file for a custom camera and it worked fine in older versions of IMAQ (v2.6).

When I updated to IMAQ v3.1, the same function and .icd file is returning frameCount as 0 and should be an increasing number retrieved from the frame grabber for each new frame.

I use this variable to check if processing of the frames has not kept up with the pace of incoming frames.

I was wondering about what the _FRAME_COUNT attribute relates to in the .icd file and if there's a possible link to having the wrong polarity or other attribute in the .icd file.

The camera grabs fine under MAX in both v2.6 and v3.1 - I've just lost the ability to monitor frame counts as indicated by this attribute.

I'm testing for dependencies but as I do, I was panning for any hints or clues that someone may have...

thanks.

[MarcoPolo5]

We do not support the creation / custom camera files as Application Engineers, however I can point you to the Camera File Generator which is a utility we provide for those who want to work on creating custom camera files:

ftp://ftp.ni.com/support/imaq/pc/ni-imaq/cfgenerator/

The lastest version - version 2.0 requires NI-IMAQ 3.1.3.

With this utility you will be able to see how your attributes are setup and be able to test them.

Camera files can be requested from: www.ni.com/cameras (see the 4th option)

[...]

Thanks Marc -

I was looking for anyone with some possible insight on the mechanism of the imgGetAttribute (sessionID, IMG_ATTR_FRAME_COUNT, &frameCount) function and what it was tied to or evaluating signal-wise. With a hint, that might limit what we would have to watch with a trial and error approach...

anyway, a change of polarity of the Enable A (VSync for this camera) got this function working today. What was odd was the difference in results between v2.6 IMAQ and currently v3.1.3 now. Something subtle changed in the recognition of the Enable A signal and NI doesn't document either API functions or hardware operation to this level.

I'm aware of the Camera Configurator program, that's great that NI developed this - I haven't had to make a new .icd file yet with the program and someday we'll give it a shot. The support of new cameras by NI has mostly been determined by the volume of cameras sold - it left anyone (like us) that may work with a dozen cameras or so out in the cold with your frame grabbers. We've worked our way through it and got to know the .icd file format, but without the help of any documentation of the format by NI. Which you either should have by now or perhaps you now trust the documentation of your Camera Configurator program. I'll take a look for that when we get started...

thanks...

Wes

[MarcoPolo5]

Wes,

Sorry I overlooked the fact that you wanted some info on the imgGetAttribute function. That function returns the value of an attribute in the icd or camera file.

In camera files you can have various attributes for your camera setup. These attributes will have values associated with them - for example, a common attribute is Integration Time. Lets say that this attribute has a range from 0 to 1000. If the camera was initally setup with an integration time of 50, this value would be returned when the imgGetAttribue function is called for Integration Time.

Some cameras are controlled with camera control lines and some cameras are controlled via serial communication lines. Each attribute configured for a camera details either the serial or camera control line interaction that the NI frame grabber board will take to set that attribute. When the board is first initialized, the camera is configured with the current settings in the camera file - calling the imgSetAttribute function will send a different value to the camera and save that value in the camera file. The imgGetAttribute simply returns what value is in the camera file.

Hopefully this details a little better how the the imgGetAttribue function works.

[...]

thanks again Marc.

in this case, the attribute I want to get is the frame count, which isn't specifically in the .icd file. The purpose of getting the frame count is if you're recording video to disk - say in a lossless or compressed (AVI) format, you can check that frame count to see if there is a missing frame to the sequence. It's a useful attribute.

In this situation, we were grabbing just fine in MAX but the frame count always returned 0. I wanted to get an idea of what the frame count was tied to.

The solution turned out to be the polarity of the ENABLE A line, which was pretty high on our list of suspects. By reversing the polarity, we were able to get the frame count attribute to increment.

With some scientific cameras, they stop the pixel clock during sync periods, and I believe this is something a bit odd with the camera we were using.

Also odd, as I mentioned, was that this was fine in IMAQ v2.6 but it changed by IMAQ 3.1.

So, no harm done and we have a grip on this for the time being. Thanks again for your notes and information.

Wes