EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  <20202021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  <20202021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: Long String support in phoebus
From: "Johnson, Andrew N. via Tech-talk" <tech-talk at aps.anl.gov>
To: "Rivers, Mark L." <rivers at cars.uchicago.edu>
Cc: EPICS tech-talk <tech-talk at aps.anl.gov>
Date: Fri, 10 Jul 2020 16:47:11 +0000
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.



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.


References:
Long String support in phoebus Nonn, Patrick via Tech-talk
Re: Long String support in phoebus Mark Rivers via Tech-talk
Re: Long String support in phoebus Nonn, Patrick via Tech-talk
Re: Long String support in phoebus Mark Rivers via Tech-talk
Re: Long String support in phoebus Ralph Lange via Tech-talk
Re: Long String support in phoebus Mark Rivers via Tech-talk

Navigate by Date:
Prev: Re: Long String support in phoebus Mark Rivers via Tech-talk
Next: RE: Asyn/StreamDevice for HP3458A through Agilent E5810 LAN/GPIB Gateway Mark Rivers via Tech-talk
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  <20202021  2022  2023  2024 
Navigate by Thread:
Prev: Re: Long String support in phoebus Mark Rivers via Tech-talk
Next: Re: Long String support in phoebus Nonn, Patrick via Tech-talk
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  <20202021  2022  2023  2024 
ANJ, 13 Jul 2020 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·