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: | [Fwd: Re: Does DISP work for DB OUT links? Related question] |
From: | Marty Kraimer <[email protected]> |
To: | [email protected] |
Date: | Fri, 29 Aug 2003 06:31:53 -0500 |
--- Begin Message ---Jeff Hill wrote:
Subject: Re: Does DISP work for DB OUT links? Related question From: Marty Kraimer <[email protected]> To: Jeff Hill <[email protected]> Cc: Bob Dalesio <[email protected]>, Andrew Johnson <[email protected]>, "Kay-Uwe Kasemir (Kay-Uwe Kasemir)" <[email protected]>, Marty Kraimer <[email protected]> Date: Thu, 28 Aug 2003 15:16:01 -0500 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 ---