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] <[email protected]> on behalf of Lucas Russo via Tech-talk <[email protected]>
Sent: Wednesday, June 12, 2019 3:07:42 PM
To: [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
- Navigate by Date:
- Prev:
updated download link for rsync-dist (from talk at EPICS Meeting 2019) Goetz Pfeiffer 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:
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
|