EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

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

Subject: RE: Native field types
From: [email protected] (Jeff Hill)
To: "'Geoff Savage'" <[email protected]>, epics tech-talk <[email protected]>
Date: Wed, 27 Jan 1999 10:40:40 -0700
Geoff,

On Wednesday, January 27, 1999 9:28 AM, Geoff Savage [SMTP:[email protected]] wrote:
> 
> I'm trying to use the R3.13 field types found in dbFldTypes.h with a CA
> client that I am writing.
> What file should I include in my C source file?
> 
> When I include cadef.h the UCHAR, USHORT, and ULONG are undefined.
> 
> Thanks
> 
> Geoff Savage
> 

For backwards compatibility reasons the CA client API and the IOC's function block 
database do not use the same data type system. This is also true when attaching to
"server side tools" which interface with the new C++ based CA server library.
When writing a CA client you should use the data types defined in the original database
access layer - db_access.h (not to be confused with the modern database access API
defined in dbAccess.h). The header file "cadef.h" includes "db_access.h" into your
program. So if the CA data type is specified to be DBR_LONG then you should use
the type "dbr_long_t" which is guaranteed to be the correct size matching DBR_LONG
on all architectures.

After you connect a CA channel to a process variable you are provided with the 
best external CA data type to use with the process variable (the terms "best external
type" and "native type" are interchangeable in EPICS speak). This "best external type"
is available in the CA client API using ca_field_type(CHID), if the channel is connected.
Unfortunately, the unsigned types present in the function block database are not present 
in the CA client API. If the field in the database is an unsigned type then Channel Access 
will map a "best external type" which is a larger integer type that can express all of the values 
in the smaller unsigned type. If a larger integer type is unavailable then an appropriate
floating point type is assigned.

In future revisions of the CA client API we will be adding the unsigned integer types.
However, if these new types are returned from ca_field_type(CHID) then we will break
backwards compatibility for the many existing client side tools. Therefore, these changes
need to be carefully planned.

Jeff




Navigate by Date:
Prev: Native field types Geoff Savage
Next: 99 North American Collaboration Meeting Bob Dalesio
Index: 1994  1995  1996  1997  1998  <19992000  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: Native field types Geoff Savage
Next: 99 North American Collaboration Meeting Bob Dalesio
Index: 1994  1995  1996  1997  1998  <19992000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 10 Aug 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·