Experimental Physics and Industrial Control System
Hi Michael,
On Friday 02 October 2009 07:22:16 Michael Abbot wrote:
> From: Andrew Johnson [mailto:[email protected]]
>
> > As I said, there are already applications that use waveform
> > records configured as an array of CHARs to store long strings
> > (file path-names for example) and standard MEDM and EDM text
> > widgets to display and edit them (the widgets do have to be
> > configured properly though). The $ modifier extends this technique
> > to the IOC's existing string field types.
>
> Ahh. I wasn't aware of this, but a colleague (Ulrik) pointed me to an
> example on one of our beamline IOCs. I've revisited my cothread.catools
> API and I think I have a better solution:
>
> 1. caget and camonitor take an extra flag as_string which defaults to
> False; if as_string is true and if (and ONLY if) the data returned is an
> array of CHAR then the result is converted to a string. Seems to work, but
> I'm going to have to watch my step with malformed strings...
In the Perl API I give the user the ability to specify what type to use for a
get_callback() or monitor subscription. If they specify DBF_CHAR for a
channel containing more than one element, they'll get the result converted to
a string. If they don't want a string, they have to ask for it as DBF_LONG,
which is the only integer data type the API supports.
Good point about the malformed strings, it would be wise to stick a zero in
the last cell of the incoming data before calling strlen() on the result. In
the majority of cases it's not going to be necessary, but if you allow the
user to specify how many elements to fetch and the string is longer than the
request it could save you from a including trash in the string, or in the
worst case from a segfault.
> 2. caput takes an extra flag str_as_array (wish I could think of a nicer,
> briefer, name) which defaults to False. If true and if a string is passed
> to caput then it is converted to an array of CHAR.
Why not make that flag into an optional data type name instead; if not
supplied you would default to whatever you were doing before, but as well as
controlling whether strings get sent as a DBF_STRING or DBF_CHAR, this could
also allow the user to tell your API "please convert my data to this type
before sending it."
The Perl API doesn't actually do that, although I could add some put_as() and
put_callback_as() methods if I wanted to allow it. I look at the number of
elements of both the channel and the supplied data to work out what to do when
the channel's native type is DBF_CHAR; for a long string it's putting a single
item to an array of DBF_CHAR. This approach does make it harder (but not
completely impossible) for an application to send a single integer value to a
multi-element DBF_CHAR array, although I don't believe that's a particularly
common thing to want to do.
HTH,
- Andrew
--
The best FOSS code is written to be read by other humans -- Harald Welte
- Replies:
- RE: EPICS Python client application survey michael.abbott
- Channel access and ca_element_count michael.abbott
- Navigate by Date:
- Prev:
Re: propagating value upward at init Ralph Lange
- Next:
RE: 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 Darren Dale
- Next:
RE: 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