EPICS Home EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

Format page
for printing


Search Tech-talk
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  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 
<== Date ==> <== Thread ==>
Subject: bugs in gateway and gdd
From: Dirk Zimoch <[email protected]>
To: Ken Evans <[email protected]>, Jeff Hill <[email protected]>
Cc: TECHTALK <[email protected]>
Date: Wed, 03 Aug 2005 19:27:08 +0200
Hi all,

since quite a long time I have problems with enums though the CA gateway. They did not update their value correctly even though time and status are OK.

I found that the problem occurs only when an alh is also connected to the enum through the gateway.

Diagnostic:

If an alh is connected, all data is handled differently. A different gdd type is used (dbr_stsack_string instead of value). In gateVcData::setEventData(), the gateway copies the incoming value to an already existing dbr_stsack_string container. See debug output:

[Aug 03 16:53:03] gateVcData::setEventData DZ-mbbo1
(1) ***********************************************************
dd (incoming)             at=16[value] pt=5[aitEnum16]
----------dump This=0x8074000---------
 dimension=0 app-type=16 Scalar
 prim-type=aitEnum16(aitEnumEnum16) value=1  ref-count=1
 total-bytes=44, data-size=2, element-count=1
 LocalDataFormat
--------------------------------------

(4) ***********************************************************
event_data(after)         at=35[dbr_stsack_string] pt=12[aitContainer]
----------dumping container:
----------dump This=0x80de9d0---------
 dimension=1 app-type=35 Container
 prim-type=aitContainer(aitEnumContainer) ref-count=1
 total-bytes=188, data-size=136, element-count=3
 destructor=0x8075f08
 (0) 0x80dea80 first=0 count=3
 Managed Flat LocalDataFormat
 total in container = 3
----------dump This=0x80de9fc---------
 dimension=0 app-type=19 Scalar
 prim-type=aitUint16(aitEnumUint16) value=1  ref-count=1
 total-bytes=44, data-size=2, element-count=1
 LocalDataFormat NoReferencing
--------------------------------------
----------dump This=0x80dea28---------
 dimension=0 app-type=20 Scalar
 prim-type=aitUint16(aitEnumUint16) value=2  ref-count=1
 total-bytes=44, data-size=2, element-count=1
 LocalDataFormat NoReferencing
--------------------------------------
----------dump This=0x80dea54---------
 dimension=0 app-type=16 Scalar
 prim-type=aitString(aitEnumString)
this=0x80dea54 string=0x80e9420<OFF>, length=3, buf length=4, type=Allocated
 ref-count=1
 total-bytes=48, data-size=12, element-count=1
 LocalDataFormat NoReferencing
--------------------------------------

Here, the input value (1 in this case) is NOT converted to the correct string (still OFF instead of ON). The string keeps its value from connection time.

Bugs:

gddApplicationTypeTable::smartCopy() does not work correctly then copying application type "value" to "dbr_stsack_string" if the value is an enum. In this copy, gdd::set() is called, which in turn (through aitConvertFromNet() and a conversion table) calls aitConvertStringEnum16() but the enum string table is never passed. Thus, it is not possible to use smartCopy() to copy enum to string.

Additionally, without the enum string table or when the number is out of bounds, aitConvertStringEnum16() writes the string representation of the number to a local string buffer but never copies that buffer to the destination string. This is clearly a bug in gdd. aitConvertFixedStringEnum16(), however, does it correctly.

The enum string table is stored externally gateVcData::pv_data. In my opinion, it should be stored in the gdd if the gdd is an aitEnum16.

Now, gateVcData::setEventData() must handle conversions enums to container (or string) separately, passing the enum string table to the conversion function. But it doesn't. This is a bug in the gateway.

Is this conversion to a string really necessary? It does not happen if no alarm handler is connected. An other side effect of the conversion is that DOUBLE values are rounded to only 6 significant digits if an alh is watching them. I think, data should be stored in its native type wherever possible.

I will report more when I have solved the problem.

So far my advice: Don't connect alh to the same gateway as your "normal" clients.

Dirk

--
Dr. Dirk Zimoch
Swiss Light Source
Paul Scherrer Institut
Computing and Controls
phone +41 56 310 5182
fax   +41 56 310 4413
Replies:
RE: bugs in gateway and gdd Kenneth Evans, Jr.
Re: bugs in gateway and gdd Ralph Lange
Navigate by Date:
Prev: Re: 3.14.7 - build on solaris - error Zoltan Kakucs
Next: RE: bugs in gateway and gdd Kenneth Evans, Jr.
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: device supports for EVG200, VME-EVR-200, VME-EVR-RF-200, GUN-TX, GUN-RC 黄松
Next: RE: bugs in gateway and gdd Kenneth Evans, Jr.
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 
ANJ, 02 Sep 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·