Hi Lucas,
You listed these parameters 4 parameters as having problems:
ACQ_TRIGGER
ACQ_TRIGGER_EVENT
ACQ_TRIGGER_REP
ACQ_TRIGGER_POL
You said the readUInt32Digital function only seems to be called for those with addr=0, not with addr=1.
When I look up those parameters in your template file I see that those are mbbo/mbbi records. You said that other parameters are called correctly for both addr=0 and addr=1. Can you see if the mbbo/mbbi records all fail to be called with addr=1 and all other record types are called OK with addr=1?
I also notice that some of your mbbo records use asynInt32, e.g. BPM_MODE, and some use asynUInt32Digital, e.g. ACQ_TRIGGER. Does one of the interfaces fail and one work for mbbo records? Why are you using different interfaces for different records?
The code that does the initial call to asynPortDriver::readUInt32Digital is in devAsynUInt32Digital::initMbbo.
status = pasynUInt32DigitalSyncIO->read(pPvt->pasynUserSync,
&value, pPvt->mask, pPvt->pasynUser->timeout);
That code is called for every mbbo record unless init_common returns an error. If init_common returns an error it always prints an error message. Did you check carefully that there are no error messages right after iocInit?
If you still think your driver is not being called for addr=1 with those parameters you could add a debugging printf just before the above call that prints pPvt->portName, pPvt->addr, and pPvt->userParam. That will show you if it is calling the port for addr=1 and that parameter string.
Mark
________________________________
From: [email protected] <[email protected]> on behalf of Lucas Russo via Tech-talk <[email protected]>
Sent: Wednesday, June 12, 2019 11:50 AM
To: Hinko Kocevar
Cc: [email protected]
Subject: Re: Asyn 4-35 IOC upgrade misbehavior
Hi Hinko,
I forgot to point out the correct branch of that repository. I'm using the following https://github.com/lnls-dig/bpm-epics-ioc/blob/base-3.15-synapps-lnls-R1-2-1/BPMApp/src/drvBPM.cpp, which includes the asynNDArrayDriver modification already.
I had taken a look at the ADCore release notes, but couldn't find anything else that might explain the issue I'm having. Maybe I missed something?
Thanks for taking a look!
Lucas Russo
On Wed, Jun 12, 2019 at 1:48 PM Hinko Kocevar via Tech-talk <[email protected]<mailto:[email protected]>> wrote:
Forgot tech-talk ..
________________________________________
From: Hinko Kocevar
Sent: Wednesday, June 12, 2019 6:43 PM
To: Lucas Russo
Subject: Re: Asyn 4-35 IOC upgrade misbehavior
Hi Lucas,
I'm going out on a limb here, and Mark will probably correct me if I'm wrong.
I believe that the asynNDArrayDriver class signature has changed between the ADCore R2-0 and R3-6 (as have other things) and you might be passing parameters to the constructor that end up in wrong place:
Compare
https://github.com/lnls-dig/bpm-epics-ioc/blob/95d26f9ccccb4aebcb5814ec6c9648dab13b031a/BPMApp/src/drvBPM.cpp#L717
with
https://github.com/areaDetector/ADCore/blob/035fdf2d0768cce582646b96831b5fff03d1ae0d/ADApp/ADSrc/asynNDArrayDriver.h#L121
Especially "(int)NUM_PARAMS," part is the one I noticed to be out of sync.
Hope this helps,
//hinko
________________________________________
From: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> on behalf of Lucas Russo via Tech-talk <[email protected]<mailto:[email protected]>>
Sent: Wednesday, June 12, 2019 3:07:42 PM
To: [email protected]<mailto:[email protected]>
Subject: Asyn 4-35 IOC upgrade misbehavior
Hello everyone,
I've been using the following module versions for a BPM IOC (complete code here: https://github.com/lnls-dig/bpm-epics-ioc) for some time:
EPICS base: 3.14.12.6
asyn: 4-26
areaDetector: R2-0
autosave: 5-9
Now, I'm upgrading this IOC to the following versions:
EPICS base: 3.15.6
asyn: 4-35
areaDetector: R3-6
autosave: 5-9
But I'm experiencing some unexpected behavior when upgrading it. I could track down the issue to the asyn upgrade from 4-26 to 4-35, as I kept everything else the same and changed just the asyn version.
The issue is as follows.
With asyn 4-26, device support devAsynUInt32Digital correctly read the hardware values and updated the corresponding my out records for all addresses. So, specifically, records that control acquisitions for two addresses are correct initialized. I instantiate my Db as follows in my st.cmd:
"
dbLoadRecords("${TOP}/db/BPMAcq.template", "P=${P}, R=${R}, ACQ_NAME=ACQ, PORT=$(PORT), ADDR=0, TIMEOUT=1")
dbLoadRecords("${TOP}/db/BPMAcq.template", "P=${P}, R=${R}, ACQ_NAME=ACQ_PM, PORT=$(PORT), ADDR=1, TIMEOUT=1")
"
And I can see that asyn devAsynUInt32Digital called my read function with some simple debug messages on IOC initialization:
"
2019/06/11 16:11:05.914 drvBPM:readUInt32Digital: readUInt32Read parameter addr = 0, value = 0, functionId = 118, paramName = ACQ_TRIGGER
2019/06/11 16:11:05.915 drvBPM:readUInt32Digital: readUInt32Read parameter addr = 0, value = 1, functionId = 119, paramName = ACQ_TRIGGER_EVENT
2019/06/11 16:11:05.915 drvBPM:readUInt32Digital: readUInt32Read parameter addr = 0, value = 0, functionId = 120, paramName = ACQ_TRIGGER_REP
2019/06/11 16:11:05.916 drvBPM:readUInt32Digital: readUInt32Read parameter addr = 0, value = 0, functionId = 122, paramName = ACQ_TRIGGER_POL
2019/06/11 16:11:05.918 drvBPM:readUInt32Digital: readUInt32Read parameter addr = 1, value = 1, functionId = 118, paramName = ACQ_TRIGGER
2019/06/11 16:11:05.918 drvBPM:readUInt32Digital: readUInt32Read parameter addr = 1, value = 0, functionId = 119, paramName = ACQ_TRIGGER_EVENT
2019/06/11 16:11:05.918 drvBPM:readUInt32Digital: readUInt32Read parameter addr = 1, value = 1, functionId = 120, paramName = ACQ_TRIGGER_REP
2019/06/11 16:11:05.920 drvBPM:readUInt32Digital: readUInt32Read parameter addr = 1, value = 0, functionId = 122, paramName = ACQ_TRIGGER_POL
2019/06/11 16:11:05.921 drvBPM:readUInt32Digital: readUInt32Read parameter addr = 0, value = 1000, functionId = 113, paramName = ACQ_SAMPLES_PRE
2019/06/11 16:11:05.922 drvBPM:readUInt32Digital: readUInt32Read parameter addr = 0, value = 0, functionId = 114, paramName = ACQ_SAMPLES_POST
2019/06/11 16:11:05.922 drvBPM:readUInt32Digital: readUInt32Read parameter addr = 0, value = 1, functionId = 115, paramName = ACQ_NUM_SHOTS
2019/06/11 16:11:05.923 drvBPM:readUInt32Digital: readUInt32Read parameter addr = 0, value = 0, functionId = 121, paramName = ACQ_TRIGGER_THRES
2019/06/11 16:11:05.924 drvBPM:readUInt32Digital: readUInt32Read parameter addr = 0, value = 0, functionId = 123, paramName = ACQ_TRIGGER_SEL
"
I can see that parameters from both addr = 0 and addr = 1 are called.
Now, when I changed to asyn 4-35 I get the following on IOC initialization:
"
2019/06/11 16:13:57.703 drvBPM:readUInt32Digital: readUInt32Read parameter addr = 0, value = 0, functionId = 125, paramName = ACQ_TRIGGER
2019/06/11 16:13:57.703 drvBPM:readUInt32Digital: readUInt32Read parameter addr = 0, value = 1, functionId = 126, paramName = ACQ_TRIGGER_EVENT
2019/06/11 16:13:57.704 drvBPM:readUInt32Digital: readUInt32Read parameter addr = 0, value = 0, functionId = 127, paramName = ACQ_TRIGGER_REP
2019/06/11 16:13:57.705 drvBPM:readUInt32Digital: readUInt32Read parameter addr = 0, value = 0, functionId = 129, paramName = ACQ_TRIGGER_POL
2019/06/11 16:13:57.709 drvBPM:readUInt32Digital: readUInt32Read parameter addr = 0, value = 1000, functionId = 120, paramName = ACQ_SAMPLES_PRE
2019/06/11 16:13:57.709 drvBPM:readUInt32Digital: readUInt32Read parameter addr = 0, value = 0, functionId = 121, paramName = ACQ_SAMPLES_POST
2019/06/11 16:13:57.709 drvBPM:readUInt32Digital: readUInt32Read parameter addr = 0, value = 1, functionId = 122, paramName = ACQ_NUM_SHOTS
2019/06/11 16:13:57.710 drvBPM:readUInt32Digital: readUInt32Read parameter addr = 0, value = 0, functionId = 128, paramName = ACQ_TRIGGER_THRES
2019/06/11 16:13:57.712 drvBPM:readUInt32Digital: readUInt32Read parameter addr = 0, value = 0, functionId = 130, paramName = ACQ_TRIGGER_SEL
2019/06/11 16:13:57.713 drvBPM:readUInt32Digital: readUInt32Read parameter addr = 0, value = 0, functionId = 131, paramName = ACQ_TRIGGER_FILT
2019/06/11 16:13:57.714 drvBPM:readUInt32Digital: readUInt32Read parameter addr = 0, value = 0, functionId = 132, paramName = ACQ_TRIGGER_HWDLY
"
In this case, only addr = 0 was called and the records associated with addr = 1 are not initialized with the hardware values.
I can see that other parameters with addr != 0 (1, 2, 3, 4...) are called during IOC initialization (not shown here for brevity), but this set of acquisition parameters are not called at all.
So, this is not a problem that affected all address != 0, but only this set.
Could this be related to the "READBACK tag" issue fixed in asyn 4-33 that somehow affected records not using the tag?
"
Fixed a problem with output records that have the asyn:READBACK info tag, i.e. output records that update on callbacks from the driver. Previously it did not correctly distinguish between record processing due to a driver callback (in which case it should not call the driver) and normal record processing (in which case the driver should be called). A new test application, testOutputCallbackApp, was added to test this. It allows testing all combinations of the following 6 settings for all 4 of these device support files:
"
Cheers!
Lucas Russo
- Replies:
- Re: Asyn 4-35 IOC upgrade misbehavior Lucas Russo via Tech-talk
- References:
- Asyn 4-35 IOC upgrade misbehavior Lucas Russo via Tech-talk
- Re: Asyn 4-35 IOC upgrade misbehavior Hinko Kocevar via Tech-talk
- Re: Asyn 4-35 IOC upgrade misbehavior Lucas Russo via Tech-talk
- Navigate by Date:
- Prev:
Re: updated download link for rsync-dist (from talk at EPICS Meeting 2019) J. Lewis Muir via Tech-talk
- Next:
Re: Asyn 4-35 IOC upgrade misbehavior Lucas Russo via Tech-talk
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
<2019>
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: Asyn 4-35 IOC upgrade misbehavior Lucas Russo via Tech-talk
- Next:
Re: Asyn 4-35 IOC upgrade misbehavior Lucas Russo via Tech-talk
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
<2019>
2020
2021
2022
2023
2024
|