Experimental Physics and Industrial Control System
|
--- Begin Message ---
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
<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:
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
<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 |
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·
·
Search
·
EPICS V4
·
IRMIS
·
Talk
·
Bugs
·
Documents
·
Links
·
Licensing
·
|