On Friday 02 October 2009 12:16:19 [email protected] wrote:
>
> > 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."
>
> Very tempted to do this for caget, but for caput I don't currently offer
> the caller control over the conversion -- instead, I convert the data to
> whatever format fits, so for scalars I only do caputs in LONG, DOUBLE or
> STRING (waveforms get the lot, except for ENUM). Hmmm.... very tempting to
> add a datatype specifier, actually, not sure if it'd be useful though?
My original example actually said something like "please send this large array
of numbers as a DBF_SHORT array" — I think a data-type specifier *would* be
useful in some circumstances, especially for the small IOC people.
> Huh: did you know that if you do
> caget('STRING-PV-ENDING-IN.$', datatype=str)
> you get an array of strings, each string containing the decimal
> representation of each character in the PV? Very entertaining!
Yup, makes perfect sense when you understand how it all works; dbNameToAddr()
which does the IOC's PV name parsing saw the field modifier and told the CA
server that the PV's native type was an array of characters, but you asked to
be given an array of strings so CA did the standard int => string conversion
on each element before sending you the result.
- Andrew
--
The best FOSS code is written to be read by other humans -- Harald Welte
- References:
- RE: EPICS Python client application survey michael.abbott
- Navigate by Date:
- Prev:
Channel access and ca_element_count michael.abbott
- Next:
Re: state notation code flags Patrick Thomas
- 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:
Channel access and ca_element_count 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
|