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: Re: AO Record: New Drive Limit Mode?
From: Korhonen Timo <[email protected]>
To: [email protected]
Date: Wed, 10 Apr 2002 10:21:59 +0200
Hi,

I just happened to be struggling with this kind of problem a while ago.
I have to catch erroneus inputs before they are propagated down to the
hardware. Let me just report the experience. This may be a bit exotic but nevertheless a real world example that is now in daily operation:

I am driving two outputs (gap and so called "shift" of an insertion device), that are calculated from user inputs (desired photon energy,
polarization mode & degree, harmonic). The range of acceptable values for the energy depend on the operating mode of the device (polarization, harmonic) and pre-calculating them would be extremely clumsy. In this case trying to catch the errors in the GUI would not be a good solution, even if it could be implemented somehow (in theory one could run a calculation to search for the max and min values every time the mode of operation is changed, and from the results to set the drive limits. However, I prefer a solid low-level solution to such cumbersome and error-prone approaches.)
Another reason why I like to have the protection in the low level rather
than in the GUI is that these values can be driven from other sources like a scan record, where the checks are not readily available.

A particularly nasty thing (which now is fixed) was that the calculation
result for some inputs can be NAN, and that was happily propagated through all the chain, down to the motors which could kill the whole IOC - a sysreset or cycling the power was necessary to restart it.

(Jim Thomas wrote:)

To provide another voice on Andrew's side, tough, they're all broken.  The
AO record already protects itself against garbage input.  IMHO the GUI
should not be inserting junk into the system.  That's an input editing
function, for which the GUI already has the necessary information.


In my case, AO did not catch this (NAN) error, but passed it straight through! (the input was not coming from a GUI.)

What I finally did, and seems to be running fine, was a solution using the IVOA in the calcout, sending a "Reject-alarm" to the user and reject the value - the invalid value is not sent out.
In fact, with this combination I could implement both the options in
Kay's original posting (although I had to play with the alarm states
a bit - "Invalid" versus limit checks, like in what Andrew wrote.)

Based on this experience, I would rather support Andrew's view of
re-thinking the use of IVOA rather than implementing something for
AO only. After all IVOA is already available in "Many" record types and
it is (IMHO) better to have a general solution rather than to force
the use of a particular record type (AO) if a user wants to have
a validity check.
But if there are good reasons to implement DRLM, then why not.

Still one comment: users have complained about the fact that the value
goes to the min or max limit if the input is out of range. So, having
the option to reject the input is desirable, but how to implement it is
another question.

Timo



--
Timo Korhonen PSI (Paul Scherrer Institut), SLS
CH-5232 Villigen PSI
tel + 41- 56 3103262 fax + 41 - 56 310 3151
e-mail: [email protected]

Replies:
Re: AO Record: New Drive Limit Mode? Bob Dalesio
References:
AO Record: New Drive Limit Mode? Kay-Uwe Kasemir
Re: AO Record: New Drive Limit Mode? Kay-Uwe Kasemir
Re: AO Record: New Drive Limit Mode? Andrew Johnson
Navigate by Date:
Prev: Re: ca_test bus error on solaris-sparc-gnu + fix Andrew Johnson
Next: Re: waveform record question Pedro Gigoux
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: Re: AO Record: New Drive Limit Mode? Andrew Johnson
Next: Re: AO Record: New Drive Limit Mode? Bob Dalesio
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, 10 Aug 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·