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
|