Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  <20032004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  <20032004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019 
<== Date ==> <== Thread ==>

Subject: [Fwd: Re: Does DISP work for DB OUT links? Related question]
From: Marty Kraimer <mrk@aps.anl.gov>
To: tech-talk@aps.anl.gov
Date: Fri, 29 Aug 2003 06:31:53 -0500
--- Begin Message ---
Subject: Re: Does DISP work for DB OUT links? Related question
From: Marty Kraimer <mrk@aps.anl.gov>
To: Jeff Hill <johill@lanl.gov>
Cc: Bob Dalesio <ldalesio@lanl.gov>, Andrew Johnson <anj@aps.anl.gov>, "Kay-Uwe Kasemir (Kay-Uwe Kasemir)" <Kasemir@lanl.gov>, Marty Kraimer <mrk@aps.anl.gov>
Date: Thu, 28 Aug 2003 15:16:01 -0500
Jeff Hill wrote:
Marty,


I see no easy solution and perhaps no solution without significent
runtime overhead.


Here are two possible fixes:

Fix 1:
One possibility would be to trigger the VAL field monitor as a side effect of initiating asynchronous record
processing instead of completing record processing. In some ways that would make sense because the record (not the
device) is being monitored, and the record changes state long before the device does. There is no way to know
exactly when the device changes state. There could be a long delay from when the device state change occurs to when
the record knows about it. I guess that the big concern might be that a client might take action based on the state
of the monitored state of VAL field when the device hadn't changed state yet - so perhaps this isn't such a great
idea.


Assume a bo record has value 0 and a 1 is written to it. Also assume 0 means no alarm and 1 means major alarm. Then the following occurs if a client monitors value, alarm severity, and time stamp


A monitor goes off when asyn starts. The alarm severity is no alarm. The time stamp is the last time the record was processed

When asyn completion occurs anoothe monitor is returned to the client. The alarm severity is major. The time stamp is the current time.

Not very nice.

Fix 2:
There is a new field called AVAL (for asynchronous value) which is initialized at the start of processing to what
is in the VAL field. When processing completes the AVAL field is used to determine if monitors will be sent instead
of VAL.

Fix two results in some storage overhead for what some might consider an insignificant glitch. However, it's those
small glitches which really confuse and frustrate people. For instance, I would be very frustrated if I was
archiving the state of a start trigger and never saw it change state. The asynchronous modes of operation are very
common now with increasing use of PLCs...


Fix 2 may be a solution. Must be checked carefully for EVERY record type. Note that aoRecord has something like this because it has to honor the orac (Output Rate of Change). It uses the name OVAL (Old Value) instead of AVAL.


Marty



--- End Message ---

Replies:
Re: [Fwd: Re: Does DISP work for DB OUT links? Related question] Marty Kraimer

Navigate by Date:
Prev: Re: Changes to records during asynch processing Marty Kraimer
Next: Re: Changes to records during asynch processing Benjamin Franksen
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  <20032004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019 
Navigate by Thread:
Prev: Warning: message 19rjRN-0005cS-PQ delayed 48 hours Mail Delivery System
Next: Re: [Fwd: Re: Does DISP work for DB OUT links? Related question] Marty Kraimer
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  <20032004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019 
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 ·