Experimental Physics and Industrial Control System

On Thursday 01 October 2009 05:16:53 Michael Abbott wrote:
>
> 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?

The string will be zero-terminated iff the array request is long enough.  
You're fetching this as an array, and your request specifies how many elements 
to get, so if you ask for fewer characters than the current length of the 
string there won't be space in your buffer for the zero.  Making your request 
as big as the array size reported by ca_element_count(chid) should guarantee 
that you get the terminating zero though.

> 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?

No, the event_handler_args.count has no relationship to the location of the 
zero in the array.  Strings fields are still fixed in length; all this does is 
provide a way for the user to specify that he wants a PV pointing to a 
DBF_STRING or DBF_*LINK field to be reported by ca_field_type(chid) to be an 
array of DBF_CHAR instead of a DBF_STRING, and it makes that conversion work 
properly internally.

> 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?

Please do *not* look at the PV name in your code, there may be other field 
modifiers in the future that will also generate a string as a DBF_CHAR array, 
and existing applications already use waveform records to store long text 
strings (MEDM and EDM have both supported this for many years).

You need to decide how to handle the data based on ca_field_type(), 
ca_element_count() and whether the application is looking for a string or an 
array of numbers.  Unfortunately the last part is essential, only the 
application developer knows whether the aSub.VALA field is supposed to hold a 
printable string or a pixel array.

>     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!)

$ is semi-legal in record names, but the field modifier only applies following 
a period '.' in the name.

> 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$ ?

No.  SOME-PV-WITHOUT-DOT$ refers to a different record, which probably doesn't 
exist.  SOME-PV-WITHOUT-DOT.VAL$ *is* equivalent to SOME-PV-WITHOUT-DOT.$ 
though.

> 5. Are there any string length limits?  I'm guessing not particularly.

Only EPICS_CA_MAX_ARRAY_BYTES.

> 6. Does this also work in the same way for caput?  I'm guessing so.

Yes, puts work as well as gets.  The latest caget and caput programs support 
long strings using the -S flag; if you omit that they just give you the result 
as a series of characters.

> 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!

See my answer to 3 above, don't try to decide what to do based on the PV name!

BTW the easiest way to test this is using the .NAME field of a record, since 
record names can be up to ~60 characters long, or using a link field.

> >  * 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.

Right.  DBE_PROPERTY is a macro, so you can use
  #ifdef DBE_PROPERTY
  #endif
around all code that uses it so it still builds against earlier versions of 
Base.

Note that when you create a monitor, CA *always* sends you at least one event 
with the current value of the dbr type.  In the past applications have done a 
ca_get_callback() for the DBR_CTRL_xx type on channel reconnection, but if you 
make that a DBR_CTRL_xx subscription for DBE_PROPERTY events you'll get that 
initial callback from all IOCs, and newer IOCs will also send out property 
change events subsequently.  In the future other record types will also send 
out DBE_PROPERTY events, and by making this change now your code will adapt to 
that behaviour change.

- Andrew
-- 
The best FOSS code is written to be read by other humans -- Harald Welte

References:

Re: EPICS Python client application survey Andrew Johnson

Re: EPICS Python client application survey Michael Abbott

Navigate by Date:

Prev: Re: EPICS Python client application survey Michael Abbott

Next: FW: EPICS Python client application survey michael.abbott

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  2020  2021  2022  2023  2024 

Navigate by Thread:

Prev: Re: EPICS Python client application survey Michael Abbott

Next: Re: EPICS Python client application survey Tim Mooney

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  2020  2021  2022  2023  2024