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