with extern trigg startAcq is not synchronuous

startAcq should wait for about 200ms before returning otherwise the detector can miss the first trig signal. This issue is confirmed by Xspectrum support (Andrea Beckmann), hereby his answer to this issue.

Hi Laurent, Florent,

starting an acquisition is unfortunately slightly more complicated. When you call startAcquisition(), the library programs the detector for the acquisition but does not start it yet. It then sends an internal synchronization event to the receiving instance to prepare itself for data reception. Afterwards detector state changes to busy and the startAcquisition() method returns. But the detector has not yet been started (and thus does not look for triggers). When the receiving instance received the sync event, it clears internal queues, reset counters and sends back another synchronization event to indicate it is ready. If the controlling instance received this sync event, it then actually starts the detector by sending the start command to the detector. Only then, the detector starts looking for triggers.

The reason for this complicated setup is that the controlling and receiving instance could possibly run on different servers. But even if they run inside the same process (which is the usual case for single module detectors), the sync events are transported using a separate sync thread, and you never know in advance when this event thread is running. This unfortunately leads to a latency between return of startAcquisition() and the actual start command to the detector, and this latency is non-deterministic.

However, the library creates a so called START event to the user application, right before it sends the start command to the detector. A user application can register a handler for this START event and run additional code right before the detector is started. An example is given below (also shown in chapter 3 of the user manual):

auto s = createSystem("/etc/opt/xsp/system.yml");
auto d = s->detector("lambda");
d->setEventHandler([&](auto t, const void* d) {
    switch (t) {
        case EventType::READY:
            // handle detector ready event
            break;
        case EventType::START:
            // handle detector start event
            break;
        case EventType::STOP:
            // handle detector stop event
            break;
    }
});

The handler should not block or perform long running tasks. The handler is called right before the start command is sent to the detector, so that the detector is still not sensitive to trigger signal, but there is a pretty deterministic latency between the return from the handler and actual start of detector.

One can possibly discuss, whether sending the START event right before or after the actual start command to the detector. Any argument for or against doing it one way or the other is welcome, One can also think of creating both events (something like PRE_START and POST_START) or so. I am open to discussions and further enhancements of the library. I definitely need to improve the user manual, to clarify such details.

Best regards,
Andreas


> Am 28.04.2022 um 12:01 schrieb Laurent Claustre <claustre@esrf.fr>:
>
> Hi Florent and Andreas,
>
> I recently got access to the lambda detector 700K of BM02 beamline (French CRG) and did not get troubles about blocking status.
> Question: are you using hardware trigger to grab the frames?
> If answer is yes, I find a bug in the thread command Camera::CameraThread::execStartAcq() which swith the status to "Exposure" before the camera has been started ( at line 97, m_cam->detector->startAcquisition(); )
>
> Thats means the Lima startAcq() will return with status set to Exposure, before the detector is really prepared to receive a external trigger. Depending how you are fast to start lima then send the trigger, the detector can miss the trigger (because not yet ready) and Lima will wait for ever, with status "Running", because no frame has been grabbed.
>
> In that case, the fix is to  move the setStatus(Exposure) just after calling "m_cam->detector->startAcquisition();" .
>
> Andreas, can you confirm that the sdk function startAcquisition() will only return when the detector is really ready to accept a trigger and there is no latency ?
>
> Best regards,
>
> Laurent