Argonne National Laboratory

Experimental Physics and
Industrial Control System

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  <20192020  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  <20192020 
<== Date ==> <== Thread ==>

Subject: Asyn 4-35 IOC upgrade misbehavior
From: Lucas Russo via Tech-talk <tech-talk@aps.anl.gov>
To: tech-talk@aps.anl.gov
Date: Wed, 12 Jun 2019 10:07:42 -0300
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

Navigate by Date:
Prev: Re: .opi from CSS to Phoebus Kasemir, Kay via Tech-talk
Next: Re: Unexpected change in behaviour of ai/ao device support J. Lewis Muir 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  <20192020 
Navigate by Thread:
Prev: Re: Re:Re: .opi from CSS to Phoebus Hinko Kocevar via Tech-talk
Next: Re: Asyn 4-35 IOC upgrade misbehavior Hinko Kocevar 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  <20192020 
ANJ, 28 Jun 2019 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·