Proper beahviour for Triggering

[MarcusZuber]

We are currently implementing multiple uca-plugins and are a little bit confused how the triggering/grabbing should work with the different trigger_sources "AUTO" and "SOFTWARE".

• "AUTO": I think a "trigger"-command is never required. A grab will always yield a frame. Is the camera running freely in the background and the grab will give me the last finished frame? Or will it trigger a new one and return after it it finished? Or will it block until the currently running frame is finished and then return?
• "SOFTWARE": A frame is started with the trigger command. Is the trigger command required while the grab is blocking and waiting for a frame, or is the grab directly returning the last acquired frame?

@matze , @tfarago : Could you comment on this? I think the behavior is even inconsistent within the uca-pco-plugin depending which camera is attached.

[ltjax]

Hello, I'm implementing those plugins with @MarcusZuber. I think one major design problem is that it is not really possible to say when or if a trigger is "valid". The naive idea is that you initiate a grab on thread A, then send a trigger on thread B and the grab in A will return.
However, since that must happen on different threads, it is not possible to know whether thread A is already in the grab. What happens when the trigger is sent before the camera is ready to receive the trigger? will the camera block indefinitely?
I think a proper solution would require the grab interface to be split in two: e.g. initiate_grab and wait_for_image. triggers are valid after the initiate and before wait_for_image returns.

[matze]

Sorry for the late reply, the message slipped through. One word in advance: the trigger semantics originate from the pco-family of cameras and other cameras were mapped as good as possible. But of course they all vary slightly in certain regards. Anyhow:

1. AUTO is supposed to be used with cameras that support free-running mode, i.e. the camera triggers internally (maybe configured through some property). I would not dare to say every grab will yield a frame but only that an explicit trigger (either through software or hardware interfaces) is not required. Internally, we do not trigger anything.
2. In SOFTWARE mode the trigger was supposed to be sent by software before grabbing a frame, but that meaning was diluted …

However, since that must happen on different threads, it is not possible to know whether thread A is already in the grab. What happens when the trigger is sent before the camera is ready to receive the trigger? will the camera block indefinitely?

You will always have the problem especially when switching to hardware triggers where you never know when a trigger even happened. If you can provide a backwards-compatible PR, I am all open to review it

Different behaviour with different pco cameras must come from hardware (but we could of course accomodate for that in software) because the plugin calls the lower-level command API the same way, regardless of the camera model.