Experimental Physics and
Industrial Control System

Michael Abbott <[email protected]> · Thu, 1 Oct 2009 11:16:53 +0100 (BST)

On Wed, 30 Sep 2009, Andrew Johnson wrote:
> I would encourage those working on this to read the release notes for 
> R3.14.11 as there are a couple of things we added which you guys are 
> going to want to provide support for:

>  * Long strings.  Important for accessing DBF_xxLINK fields since record 
> names can be up to 60 characters long, so you can't always read or 
> change the value of a link field using a 40 character DBF_STRING.

Yii.  Let me first quote the relevant part of the release note:

Adding the suffix '$' to the field name of an IOC PV name (through either 
Channel Access or Database Access) causes the native type of that field to 
be reported as an array of DBF_CHAR, as long as the field type is 
DBF_STRING, DBF_INLINK, DBF_OUTLINK or DBF_FWDLINK. It is then possible to 
use a DBF_CHAR array to read, write and monitor values from that field, 
and the 40 character string length limit imposed by the DBF_STRING type is 
replaced by the amount of storage allocated for the string on the IOC (for 
link fields the limit is related to the maximum length of a record name).

Let me make sure I understand this.  If I do `caget <pv-name>$` to a .11 
server then then I get back a CHAR waveform of the length of the string.  
Sounds promising.  Let me ask some questions:

1. Is the string null terminated, or is its length determined by the 
length of the waveform?  In other words, does the returned waveform 
include the terminating null?

2. If the string length changes, is this going to be as simple as seeing a 
new .count value in the event_handler_args structure in the subscription
callback?

3. What happens if I ask for a PV name ending in $ on a pre 14.11 server?  
In particular, can I safely just hard-wire the special "ends with $ turns 
into a string" treatment, or is this going to cause backwards 
compatibility pain?
    Our local naming convention forbids $ in PV names, but I don't know 
what happens elsewhere; is it a valid PV character at the moment?  I 
suppose $ was chosen because it's distinctive, and it's a cute backwards 
compatible hack (if slightly wince making!)

4. Does this work for both dotted and non-dotted names, I mean if a 
request is made for SOME-PV-WITHOUT-DOT$ is this equivalent to asking for 
SOME-PV-WITHOUT-DOT.VAL$ ?

5. Are there any string length limits?  I'm guessing not particularly.
6. Does this also work in the same way for caput?  I'm guessing so.

Should be pretty easy for me to support, but it does mean that my dbr 
routines will have to be told whether the '$' suffix is present, as 
otherwise arrays of DBF_CHAR are treated as arrays of uint8; I think the 
conversion will be only mildly clumsy!

>  * DBE_PROPERTY events.  Generated now on the VAL field of the mbb[io] 
> record types when someone changes one of the *ST fields, a DBE_PROPERTY 
> monitor allows a client to always know what the current ENUM strings 
> are.

I guess that's easy enough: presumably if the DBE_PROPERTY bit is set in a 
CA request to a pre .14.11 server it'll have no effect, so I guess I can 
just add DBE_PROPERTY to my list of event types.

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System