Re: Long String support in phoebus

["Johnson, Andrew N. via Tech-talk" <tech-talk at aps.anl.gov>]

Hi Mark,

On Jul 10, 2020, at 10:41 AM, Mark Rivers via Tech-talk <tech-talk at aps.anl.gov> wrote:

2. The server must be told to show fields that are supposed to be long strings as arrays of char to Channel Access. This is a data type issue on the server side, and done by adding the '$' to the PV name.

Can you point me to where this is documented?  The only place I have been able to find it is in the 3.14 Release Notes: https://epics.anl.gov/base/R3-14/12-docs/RELEASE_NOTES.html

I cannot find it in a reference document, i.e.

- Application Developer's Guide 3.16.2 https://epics.anl.gov/base/R3-16/2-docs/AppDevGuide.pdf

The $ sign is called a field modifier, and they are briefly mentioned in the AppDevGuide but unfortunately not anywhere that users would be looking for them (the description of them in section 15.4.1 is also out of date anyway). The $ modifier has been part of Base since R3.14.11, this talk introduced it starting at slide 5: https://epics.anl.gov/meetings/2009-05/SA1/BaseR3.14.11.pdf

We introduced additional field modifiers to the IOC in R3.15.1 and later; in most cases they use JSON syntax to provide parameters for a filter, but there is a short-hand for the array filter that uses square brackets [start:increment:end] to select the array elements to be included. These filters are all detailed in the Channel Filters document which is also generated as part of the Base build (look in Base/html/filters.html for the specific filters available in your release).

I have been very remiss though in not documenting the $ modifier properly. It’s not obvious where it should be described though, so I’ll probably add it to that filters document.

- Channel Access Reference Manual https://epics.anl.gov/base/R7-0/4-docs/CAref.html
<https://epics.anl.gov/base/R7-0/4-docs/CAref.html>- Channel Filters https://epics.anl.gov/base/R7-0/4-docs/filters.html

Field modifiers are implemented inside the IOC, below the level of Channel Access, which is how we were able to add them without having to modify the protocol at all, so older CA clients such as MEDM that already supported accessing strings as char arrays can use them. That is also why you can use them with QSRV over PV Access, the network protocols just present the IOC with a PV name and the IOC handles parsing it and working out how to present it to the server.

HTH,

- Andrew

From: Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of Ralph Lange via Tech-talk <tech-talk at aps.anl.gov>
Sent: Friday, July 10, 2020 8:54 AM
To: EPICS Tech Talk
Subject: Re: Long String support in phoebus

On Fri, 10 Jul 2020 at 15:34, Mark Rivers via Tech-talk <tech-talk at aps.anl.gov<mailto:tech-talk at aps.anl.gov>> wrote:
[...]

It would probably be good to mention that the .VAL$ syntax is required in the lso record documentation here:
https://epics.anl.gov/base/R7-0/4-docs/lsoRecord.html


Actually, there is nothing special about the long string output record.

There are *two* sides to the issue (client and server), and - depending on the field type of the record - there are *two* related switches you may have to activate for long strings to work across Channel Access.

1. The client must be told to send a string as an array of char, and to show an array of char as a string. This is a representation issue on the client side, and done using '-S' with the command line tools.
2. The server must be told to show fields that are supposed to be long strings as arrays of char to Channel Access. This is a data type issue on the server side, and done by adding the '$' to the PV name.

The waveform record doesn't need the server side switch, because its native data type of the VAL field is already an array of char.
Any string type field that is longer than 40 characters (DESC, link fields, lsi/lso VAL fields, ...) need the '$' switch to be shown as array of char instead of string.

Cheers,
~Ralph

-- 

Complexity comes for free, simplicity you have to work for.