The issue with long strings documented in this tech-talk thread
https://epics.anl.gov/tech-talk/2021/msg01491.php appears to be present in both base 7.0.5 and 7.0.6. It is fixed in 7.0.6.1.
The main impact for us is that that the OPI screens in the synApps calc module do not work. For us upgrading to 7.0.6.1 is not an option because of the vxWorks issues with
base 7.0.6 and 7.0.6.1 described in another thread. To use base 7.0.5 and work around the long string problem I have created a new base_7_fix branch in the synApps calc module:
https://github.com/epics-modules/calc/tree/base_7_fix
The branch removes all of the final $ characters from the OPI screens. This means they won’t be able to write strings longer than 40 characters, but at least they don’t
only write the first character (!!!), which is what happens without this change on IOCs with base 7.0.5 and 7.0.6.
Mark
From: Mark Rivers
Sent: Tuesday, May 31, 2022 3:07 PM
To: tech-talk at aps.anl.gov
Subject: Issue or misunderstanding with long string support
Our IOCs are now all running base 7.0.5. We see an issue with medm screens containing string files using PVs that end in a “$”. We can only change the first character
in the string.
This is easy to reproduce using the caput and cainfo clients from base 7.0.5 to a PV in an IOC running base 7.0.5.
cainfo without the $ modifier shows the field is a DBF_STRING.
corvette:local/epics-devel/base-7.0.6>/usr/local/epics-devel/base-7.0.5/bin/linux-x86_64/cainfo 13BMD:userTran20.CLCA
13BMD:userTran20.CLCA
State: connected
Host: ioc13bmd.cars.aps.anl.gov:5064
Access: read, write
Native data type: DBF_STRING
Request type: DBR_STRING
Element count: 1
cainfo with the $ modifier shows the field is a DBF_CHAR of size 120
corvette:local/epics-devel/base-7.0.6>/usr/local/epics-devel/base-7.0.5/bin/linux-x86_64/cainfo 13BMD:userTran20.CLCA$
13BMD:userTran20.CLCA$
State: connected
Host: ioc13bmd.cars.aps.anl.gov:5064
Access: read, write
Native data type: DBF_CHAR
Request type: DBR_CHAR
Element count: 120
A caput without the $ modifier works, but that would be limited to 40 characters.
corvette:local/epics-devel/base-7.0.6>/usr/local/epics-devel/base-7.0.5/bin/linux-x86_64/caput 13BMD:userTran20.CLCA "A+B"
Old : 13BMD:userTran20.CLCA
New : 13BMD:userTran20.CLCA A+B
A caput with the $ modifier does not work, only the first character in the string was changed. It should have changed from A+B to B+A, but instead it changed to B+B.
corvette:local/epics-devel/base-7.0.6>/usr/local/epics-devel/base-7.0.5/bin/linux-x86_64/caput -S 13BMD:userTran20.CLCA$ "B+A"
Old : 13BMD:userTran20.CLCA$ A+B
New : 13BMD:userTran20.CLCA$ B+B
I see the same issue when writing to the DESC field of an ao record.
corvette:local/epics-devel/base-7.0.6>/usr/local/epics-devel/base-7.0.5/bin/linux-x86_64/caput testAo_1.DESC "123"
Old : testAo_1.DESC H23
New : testAo_1.DESC 123
When writing with the $ modifier it should have changed “123” to “321”, but instead it is “323”.
corvette:local/epics-devel/base-7.0.6>/usr/local/epics-devel/base-7.0.5/bin/linux-x86_64/caput -S testAo_1.DESC$ "321"
Old : testAo_1.DESC$ 123
New : testAo_1.DESC$ 323
Is this a bug, or am I misunderstanding how long strings are supposed to work?
This looks similar to this bug that is fixed in 7.0.6.1, but that says it was specific to the CALC field.
https://github.com/epics-base/epics-base/issues/194
Thanks,
Mark