Experimental Physics and
Industrial Control System

Hi Mark,

I am using Readmode=1 (corrected). The Readmode=0(raw) was not working and I found out this command was removed from this firmware version of the detector (4.0.1). So I would guess this new firmware also changed something in the dynamics of acquisition.

Just so you know, I am testing with 100fps but my goal is to reach the full potential of this detector and reach 1000fps.

I will do the timing diagnostics as you have suggested and I will report my findings. 

Thank you.

Nilson

Hi Nilson,

 

I don't have any experience with this device, but I've just had a quick look at the driver.

 

Are you using Readmode=0 (raw) or Readmode=1 (corrected)?

 

This is the loop of the thread that reads the device.

 

    while (1) {

        /* Is acquisition active? */

        getIntegerParam(ADAcquire, &acquire);

       

        /* If we are not acquiring then wait for a semaphore that is given when acquisition is started */

        if (!acquire || !acquiring_)  {

            setIntegerParam(ADStatus, ADStatusIdle);

            callParamCallbacks();

            /* Release the lock while we wait for an event that says acquire has started, then lock again */

            asynPrint(this->pasynUserSelf, ASYN_TRACE_FLOW,

                "%s:%s: waiting for acquire to start\n", driverName, functionName);

            this->unlock();

            eventStatus = epicsEventWait(this->startEventId_);

            // setStringParam(ADStatusMessage, "Acquiring data");

            // setIntegerParam(ADNumImagesCounter, 0);

              // getIntegerParam(ADAcquire, &acquire);

             

                  

              //printf("Read Mode: %d\tnModules: %d\t chanperline: %d\n", readmode_,this->nmodules,chanperline_);

            if (readmode_==0)       //Raw Mode

                nread_expect = sizeof(epicsInt32)*this->nmodules*(1280/chanperline_);

            else

                nread_expect = sizeof(epicsInt32)*this->nmodules*(1280);

               

            dataOK = 1;

 

            eventStatus = getStatus();

            setIntegerParam(ADStatus, eventStatus);

 

            if (eventStatus!=ADStatusError) {

 

              getDoubleParam(ADAcquireTime,&acquireTime);

              // printf("Acquisition start - expect %d\n",nread_expect);

              // Work on the cases of what are you getting from getstatus

              do {

                nread=0;

                if (readmode_==0)

                  strcpy(outString_, "-readoutraw");

                else

                  strcpy(outString_, "-readout");

 

                status = pasynOctetSyncIO->writeRead(pasynUserMeter_, outString_, strlen(outString_), (char *)detArray_,

                                        nread_expect, M1K_TIMEOUT+acquireTime, &nwrite, &nread, &eomReason);  //Timeout is M1K_TIMEOUT + AcquireTime

 

                //printf("nread_expected = %d\tnread = %d\n", nread_expect,nread);

 

                if(nread == nread_expect) {

                    this->lock();

                    dataOK = dataCallback(detArray_);

                    this->unlock();

                    if (!dataOK) {

                        eventStatus = getStatus();

                        setIntegerParam(ADStatus, eventStatus);

                    }

 

                }

                else {

                    eventStatus = getStatus();

                    setIntegerParam(ADStatus, eventStatus);

                  //printf("Data not size expected ADStatus: %d\n",eventStatus);

                }

                if(status != asynSuccess) {

                    asynPrint(pasynUserSelf, ASYN_TRACE_ERROR,

                          "%s:%s: error using readout command status=%d, nRead=%d, eomReason=%d\n",

                          driverName, functionName, status, (int)nread, eomReason);

                }

              }

              while (status == asynSuccess && (eventStatus==ADStatusAcquire||eventStatus==ADStatusReadout) && acquiring_);

            

           }

           this->lock();

           

        }

        if (eventStatus!=ADStatusError ) {

          printf("Acquisition finish\n");

          getIntegerParam(ADImageMode, &imageMode);

          if (imageMode == ADImageSingle || imageMode == ADImageMultiple) {

            printf("ADAcquire Callback\n");

            acquiring_ = 0;

            setIntegerParam(ADAcquire,  0);

            callParamCallbacks();

          }

        }

        else {

          //Abort read

          asynPrint(pasynUserSelf, ASYN_TRACE_ERROR,

                "%s:%s: error timed out waiting for data\n",

                driverName, functionName);

          acquiring_ = 0;

            setAcquire(0);

          setIntegerParam(ADAcquire,  0);

          callParamCallbacks();

        }

    }

}

 

I see a number of issues in this code.  But these will not impact performance.

 

- It has the lock() released much of the time.  It should only be released during the time-intensive operations of epicsEventWait and pasynOctetSyncIO->writeRead().

- It does not check the status return from pasynOctetSyncIO->writeRead()  before checking nread.  It should do it first.

- This line should be changed to asynPrint(pasynUserSelf, ASYN_TRACE_ERROR) because it is important to know if that happened.

                  //printf("Data not size expected ADStatus: %d\n",eventStatus);

-          This line should be changed to asynPrint(pasynUserSelf, ASYN_TRACEIO_DRIVER) so one can enable that message to get the information.

                //printf("nread_expected = %d\tnread = %d\n", nread_expect,nread);

 

The inner do while() loop looks very fast and straightforward assuming pasynOctetSyncIO->writeRead() always succeeds, nread=nread_expect, and dataCallback() returns 1, which it should always do.

 

I think you need to turn on ASYN_TRACEIO_DRIVER to the underlying drvAsynIPPort and capture the communications with the device into a file.  You can do this with commands in st.cmd or with the asynRecord OPI screen.  That will let you look at the timing: is the device responding promptly, and is the IOC sending the next command promptly after receiving the previous data?  You may be correct that to get more than 100 frames/s it will be necessary to read multiple images per transfer, but you should get this diagnostic information before doing that.

 

Mark

 

 

 

> -----Original Message-----

> From: Nilson Pereira [mailto:[email protected]]

> Sent: Thursday, February 15, 2018 11:46 AM

> To: Mark Rivers <[email protected]>; [email protected]; [email protected]

> Subject: Re: Mythen M1K - Low fps

>

> Hello Mark and Mark,

>

> The image size is only around 3.1KB per frame (1028 bins with 24 bits

> each).

>

> I am only running 1 NDStardardArray plugin and it seems to be fine.

> There are no dropped frames that could be observed by the plugin and it

> is configured with blocking "Disable". The same behavior is observed

> with all plugins disabled.

>

> It Is the array count itself on the IOC that shows the discrepancy

> between the numbers of frames requested and received.

>

> On the detector side, I can use the same settings to acquire data within

> its own web interface application. The aplication is capable of

> acquiring up to 1000 fps with no loss. So I believe it should be between

> the detector and the IOC.

>

> Any suggestions?

>

> Nilson

>

>

>

>

> On 15.02.2018 18:31, Mark Rivers wrote:

> > Hi Nilson,

> >

> > When you say it is dropping frames, can you be more explicit?  Can you tell where the

> frames are being dropped, i.e. between the detector and the IOC, or in an IOC plugin?

> >

> > What plugins are you running in this IOC?

> >

> > Are they configured with blocking=Enabled or Disabled?

> >

> > What queue size are the plugins using?

> >

> > Mark

> >

> >

> >

> >

> >> -----Original Message-----

> >> From: [email protected] [mailto:[email protected]] On

> Behalf

> >> Of Nilson Pereira

> >> Sent: Thursday, February 15, 2018 10:50 AM

> >> To: [email protected]

> >> Subject: Mythen M1K - Low fps

> >>

> >> Hello everyone,

> >>

> >> I started to work with a Dectris strip Detector Mythen2 X 1K and I am

> >> using the Mythen module from AreaDetector. This detector can reach

> >> 1000fps, however the IOC starts to drop frames with frequencies higher

> >> than 100fps.

> >>

> >> Has anyone experience this limitation with this type of detector?

> >> To avoid network issues, I have a straight network connection between

> >> the PC and detector.

> >>

> >> I also noticed that the IOC only requests 1 frame at a time when it

> >> could (according to the manual) requests multiples frames to avoid

> >> communication overheads. Has anyone tried implementing this?

> >>

> >> My versions:

> >> - Ubuntu 16.04

> >> - EPICS base 3.15.5

> >> - ADCore 2-6

> >> - ADMythen 2-0

> >>

> >>

> >>

> >> ________________________________

> >>

> >> Helmholtz-Zentrum Berlin für Materialien und Energie GmbH

> >>

> >> Mitglied der Hermann von Helmholtz-Gemeinschaft Deutscher Forschungszentren e.V.

> >>

> >> Aufsichtsrat: Vorsitzender Dr. Karl Eugen Huthmacher, stv. Vorsitzende Dr. Jutta

> Koch-

> >> Unterseher

> >> Geschäftsführung: Prof. Dr. Bernd Rech (kommissarisch), Thomas Frederking

> >>

> >> Sitz Berlin, AG Charlottenburg, 89 HRB 5583

> >>

> >> Postadresse:

> >> Hahn-Meitner-Platz 1

> >> D-14109 Berlin

> >>

> >> http://www.helmholtz-berlin.de

>

>

> ________________________________

>

> Helmholtz-Zentrum Berlin für Materialien und Energie GmbH

>

> Mitglied der Hermann von Helmholtz-Gemeinschaft Deutscher Forschungszentren e.V.

>

> Aufsichtsrat: Vorsitzender Dr. Karl Eugen Huthmacher, stv. Vorsitzende Dr. Jutta Koch-

> Unterseher

> Geschäftsführung: Prof. Dr. Bernd Rech (kommissarisch), Thomas Frederking

>

> Sitz Berlin, AG Charlottenburg, 89 HRB 5583

>

> Postadresse:

> Hahn-Meitner-Platz 1

> D-14109 Berlin

>

> http://www.helmholtz-berlin.de