RE: Issue or misunderstanding with long string support

[Mark Rivers via Tech-talk <tech-talk at aps.anl.gov>]

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