Experimental Physics and
Industrial Control System

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