Experimental Physics and Industrial Control System
|
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
<2021>
2022
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
<2021>
2022
2023
2024
|
ANJ, 03 Mar 2021 |
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·
·
Search
·
EPICS V4
·
IRMIS
·
Talk
·
Bugs
·
Documents
·
Links
·
Licensing
·
|