EPICS Home

Experimental Physics and Industrial Control System


 
1994  1995  1996  1997  1998  1999  2000  2001  <20022003  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  <20022003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: EPICS Base 3.13.6 Caveat
From: [email protected]
To: EPICS Tech-Talk <[email protected]>
Date: Tue, 28 May 2002 09:02:20 +0200
This is a warning about a change in base's behaviour that may cause
unwanted side effects.

Affected version: 3.13.6


Likely symptom:

Strange different behaviour of databases with calc and/or calcout
records that have CA input links, i.e. either with .CPP attribute or
residing on a different IOC. The effect is most likely to appear when
rebooting the IOC.


Analysis:

3.13.6 introduced a certain change in dbCaGetLink() (see Release Notes):
"dbCaGetLink must return -1 when setting sevr to INVALID"

The effect occurs when the calc/calcout is reading CA input links that
are INVALID either because the CA link hasn't connected or it isn't
granted read access by the source IOC.
The old behaviour of calc/calcout was to proceed reading the links,
perform the calculation (using the old value or 0 at boot time), set the
record to LINK/INVALID and process its OUT/FLNK.
In 3.13.6 the record stops at the first input link that doesn't get
data, and does _NOT_ perform the calculation before setting its alarm
state and processing the outputs / forward links.

Subsequent records that used to get a calculation result now get the old
value or 0 at boot time.

(In our case a calc with .CPP inputs was generating a command word using
XOR in its expression to take care of inverse command bits. In 3.13.6
after a reboot the first processing often occured before all inputs had
been connected - the subsequent record was always writing a 0 to the
hardware which switched off the connected power supply.)


Fix:

The new behaviour of base is correct.

To fix the databases, make sure that subsequent records get their values
by links with the .MS attribute set and use IVOV/IVOA to prevent from
writing unwanted values to the hardware.


Whoa.

Ralph

Replies:
Re: EPICS Base 3.13.6 Caveat Tim Mooney

Navigate by Date:
Prev: Re: error in caput ("caputting negative numbers") Brian McAllister
Next: Re: EPICS Base 3.13.6 Caveat Tim Mooney
Index: 1994  1995  1996  1997  1998  1999  2000  2001  <20022003  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 Support for RAMdisk Jane Richards
Next: Re: EPICS Base 3.13.6 Caveat Tim Mooney
Index: 1994  1995  1996  1997  1998  1999  2000  2001  <20022003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024