IMAQdx session "Attribute updated" event

[_Mike_]

Hello!

I am running a system with GigE camera with NI framegrabber  in continuous acquisition mode - in which I change some attributes every now and then.

So far I have been using following scheme to assert I am getting correct image after attribute change:

• change attribute
• read "Last buffer number" property -> n
• run IMAQdx get image.vi set to "buffer' and parameter n+2 (+2 being due to the fact that i assumed attribute change arrives to camere during running exposure that will be unaffected by attribute change - hence i needed to discard "next" buffer)

Unfortunately I still every now and then acquired image that obviously was aquired with previous attributes (e.g. I've dramatically increased.decreased exposure rate, while acquired image was very similar to previously acquired one). Guessing that it may have something to do with buffers I have increased "magic number" from +2 to +3. It indeed helped, but after longer usage I have discovered, that it only reduced the frequency of the error.

Hence I needed to design more "bulletproof" solution that will satisfy my timing requirements (stoping and starting acquisition is out of question as it takes more than 100ms what is unacceptable for me)

I would like to:

• change attribute
• acquire information from camera that will allow me to fetch image acquired with changed attribute

For such purpose I have discovered IMAQdx events - especially "Attribute updated" and "frameDone". Unfortunately, I could not find any detailed documentation about those functions. Therefore I would like to ask you for help to determine when 'Attribute updated" is triggered. Is it when:

• driver receives the command and pushes it to camera? (pretty useless for me as I cannot relate it to any particular exposure)
• camera confirms getting it (then assuming it arrives during an ongoing exposure, I'll discard "next' image and expect second next to be correct
• camera confirms applying it (then I assume that next image should be obtained with correct settings)
• camera confirms it managed to acquire a frame with new parameter (pretty unlikely scenario - but the i'd expect correct image to reside in "last" buffer)

Could you help me determine which case is true? Also should I be concerned about the fact that there may be a frame "in transition" between camera and IMAQdx driver which will desynchronize my efforts here?

 

[infinitenothing]

Many cameras have a soft trigger function. Maybe you could count images vs soft triggers before the exposure change to figure out the exposure of each image.

[_Mike_]

That indeed sounds interesting!

 I am using Basler ace and Deledyne/Dalsa Genie cameras. I could find some information on "software acquisition trigger" for Basler - i need more insight into teledyne/Dalsa hardware.

How does soft triggering look like (i mean 'softare triggering") from LabVIEW/IMAQdx perspective? I have seen neither any examples nor  palette vis to support such functionality - could you write me a bit more or direct me to appropriate materials?

 

[smithd]

Strangely enough its just a property:

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000004Aa2SAE

I dont know if we are thinking of the same thing, but what came to mind with software triggering was this procedure:

1. Change trigger mode on camera to software trigger
2. Read buffer #
3. Set exposure time
4. read back exposure time (poll until = new value)
5. fire software trigger
6. ignore that new image
7. turn trigger mode back to hardware triggering (or free run if thats what you use).

Seems like this would be a pretty fool-proof way of ensuring the change? If it works you can then start removing things (for ex I think 5/6 are redundant since you paused triggering in 1)

Edited June 21, 2018 by smithd

[_Mike_]

Thank you smithd!

I use continuous mode solely due to the fact, that setting up camera otherwise takes relatively long time (100ms+) so it would be a hassle for me to trigger it correctly. I have not came accross software trigger in LV before - apparently it is not pronounced strongly enough

I will dive into the topic and come back if some things will remain unclear. 

[infinitenothing]

I made a snippet to illustrate what I was thinking. I have a Basler dart camera that I was able to test with and it looked OK in theory. You'll notice it is in continuous mode. I'm hoping that since trigger and the exposure both go through property nodes, the settings will apply in that order. There might be a theoretical race condition that would apply the new exposure to a capture in progress, I guess for that, you could capture the exposure before and after and have some sort of indeterminate case but I think it would be nearly impossible.

[_Mike_]

Thank you a lot!

I will experiment a bit with that but I guess the way to elliminate the possibility of raecondition would be to place an assertion on exposure time in between setting exposure time and triggering a software trigger. I imagine such assertion in two forms:

• asynchronous - using "AttributeUpdated" event (then I need to use it preferrably in all places I change any attributes - to ensure that event I get confirms the change i invoked)
• synchronous - polling IMAQdx for values of subject attributes in wait for update to happen.

[_Mike_]

Also I am not in need to separate proces of parameter setting to independent loops. I will be perfectly content with blocking call each time.