epics-modules / caPutLog

Channel Access Put Logger, from DESY/BESSY

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

caputLog + qsrv1 makes pvmonitor not work with waveform PVs

gabrielfedel opened this issue · comments

Hi, I have found this interesting issue when using caputLog + qsrv1 with a waveform PV. Using that combination if the waveform PV is changed (using CA or PVA) the pvmonitor is not notified about the change. What is also curious is that the issue doesn't happens when we use qsrv2 (pvxs).

Here an example (inspired by @mdavidsaver one) on how to replicate the issue:

$ cat st_vanilla.cmd 
#!../epics-base/bin/linux-x86_64/softIocPVA
dlload ../caPutLog/lib/linux-x86_64/libcaPutLog.so
dbLoadDatabase ../caPutLog/dbd/caPutLog.dbd
registerAllRecordDeviceDrivers
dbLoadRecords wave.db "P=TEST:"
asSetFilename "unrestricted_access.acf"
asInit
caPutLogInit localhost:7654
iocInit

$ cat wave.db 
record(waveform, "$(P)WAVE"){
    field(NELM, "$(SIZE=100)")
    field(FTVL, "DOUBLE")
}

$ cat unrestricted_access.acf
ASG(DEFAULT) {
   RULE(1,READ)
   RULE(1,WRITE,TRAPWRITE)
}

On that example if you try to:

pvmonitor TEST:WAVE

and

pvput TEST:WAVE [1,2,3]

the pvmonitor will not change. This issue can have effects on other tools (like the CSStudio Phoebus Save and Restore, which will not be able to restore values on these PVs if using pva as default protocol).

The issue doesn't affect camonitor.

Great that you found a way to reproduce the issue, @gabrielfedel ! I think Michael (Davidsaver) would be interested to hear this. We should move to qsrv2 as soon as we can, but we need to accelerate the release of qsrv2 in EPICS Base.
(Sorry for the in-house tone, I was so excited that I did not notice that this was on Github and not in our internal JIRA...)

The bug causing this seems to be in the implementation of QSRV on pvAccessCPP as apparently it also occurs in autosave. Please close this issue and move the discussion to the epics-base/pva2pva project moving forward. Thanks to @simon-ess who is investigating further.

Ok! Closing the issue here as it seem to be located to pva2pva.