EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  <20212022  2023  2024  Index 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  <20212022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: epicsTypes.h question
From: "Johnson, Andrew N. via Core-talk" <core-talk at aps.anl.gov>
To: "zan.pratnemer at cosylab.com" <zan.pratnemer at cosylab.com>
Cc: EPICS core-talk <core-talk at aps.anl.gov>, Ziga Oven <ziga.oven at cosylab.com>
Date: Tue, 2 Mar 2021 18:46:12 +0000
Hi Zan,

On Mar 2, 2021, at 4:58 AM, zan.pratnemer at cosylab.com wrote:

I am working on expanding s7pls module to support 64 bit integers and I have a question about EPICS types.
In the current device support, epicsTypes.h-->epicsType enumerator values are used for switching between different data types.

Simple example:
switch (priv->dtype)
{
   case epicsInt8T:
   case epicsUInt8T:
   case epicsInt16T:
   case epicsUInt16T:
   case epicsInt32T:
   case epicsUInt32T:
       break;
   default:
       errlogSevPrintf(errlogFatal,
           "s7plcInitRecordLongout %s: illegal data type\n",
           record->name);
       return S_db_badField;
}


But this enumerator does not have values for epicsInt64 and epicsUInt64 although both are in the epicsTypes.h-->epicsAny union
and are defined above in the same file:
typedef long long       epicsInt64;
typedef unsigned long long epicsUInt64;

Is epicsTypes the correct structure to use in this way? If not, what should I use?
Or do int64 types need to be added into the epicsType enumerator?

Thank you,
Žan Matic Pratnemer

Good question.

When I added Int64 type support to the IOC I didn’t extend the epicsType enum because it isn’t used inside the IOC, and it contains the enumerations epicsStringT and epicsOldStringT which correspond to types that aren't used by the IOC code, although some of them might be used outside – I suspect this enum pre-date the “new” dbAccess API, but I wasn’t involved at the time. I hope we will someday deprecate some of the unused definitions in epicsTypes.h and eventually remove them, but nobody particularly enjoys doing housekeeping...

We actually have a few other similar enumerations that we do use, the main ones being dbfType as defined in dbFldTypes.h and menuFtype defined in menuFtype.dbd and provided in the menuFtype.h header file. The DBF_ and DBR_ macros defined in db_access.h are for the data types supported by Channel Access and don’t include unsigned or 64-bit choices, so don’t try to use them.

I recommend switching to the menuFtype enumeration. These values correspond to the field types supported by the waveform record and other array record fields, and do include values for the 64-bit integer types. They are thus directly related to the types that device support normally needs to implement.

HTH,

- Andrew

-- 
Complexity comes for free, simplicity you have to work for.


Navigate by Date:
Prev: [Bug 1913699] Re: vxWorks compilation fails with undeclared function Andrew Johnson via Core-talk
Next: Re: [Merge] ~dirk.zimoch/epics-base:epicsMutexPriorityInheritance into epics-base:7.0 mdavidsaver via Core-talk
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  <20212022  2023  2024 
Navigate by Thread:
Prev: Zero-length array fix impact Timo Korhonen via Core-talk
Next: Re: Announcement: Legacy libnetworking will be removed from RTEMS and will be placed in a separate repository junkes via Core-talk
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  <20212022  2023  2024 
ANJ, 03 Mar 2021 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·