EPICS Home

Experimental Physics and Industrial Control System


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

Subject: Re: EPICS Python client application survey
From: Andrew Johnson <[email protected]>
To: [email protected]
Cc: EPICS tech-talk <[email protected]>
Date: Fri, 2 Oct 2009 11:45:57 -0500
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  <20092010  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  <20092010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024