EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

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

Subject: Re: Forcing a record to be processed
From: Ralph Lange <[email protected]>
To: [email protected]
Cc: tech-talk <[email protected]>, "Fuess, Stu" <[email protected]>, "Kersten, Susanne" <[email protected]>, "Krzywdzinski, Stan" <[email protected]>, "Lee, Bill" <[email protected]>, "Savage, Geoff" <[email protected]>, "Sirotenko, Vladimir" <[email protected]>, "Sumowidago, Suharyo" <[email protected]>
Date: Wed, 29 Sep 2004 16:39:40 +0200
I have seen a couple of examples using a different approach to achieve
that kind of behavior:

I suppose both records are using the same device support (which is
likely as they are referencing the same hardware register), so the
device support has (or at least might have) an idea which records are
linking to a certain hardware register.

In the input variant (easier case) the input record's SCAN is
permanently set to "I/O Intr", and device support processes the input
record when it recognises a write access from the corresponding output
record. If the output record is the only record that writes to the
hardware register, why would you want to scan the corresponding input
record periodically?

The output case is a bit trickier. For an output that writes to hardware
that has other means of being written to (e.g. a PLC with a local
control), you probably want the output record to be updated either by a
CA or database put to the record or by the new value that was received
locally from the "other" master. But even if your output record in that
case has SCAN set to "Passive" - if your device support is capable of
detecting an externally updated value, it may fake a second pass
asynchronous record processing that gets the new output value up to the
record. Our OPC-Gateway device support is using this technique to update
output records when the corresponding value in the PLC changes.

But this topic has numerous related issues and side effects. Have a look
at the "Bidirectional device support" thread on tech-talk that started
mid-April this year to get an impression.

Cheers,
Ralph


>>>>> "Fritz" == J Frederick Bartlett <[email protected]> writes:

  >   The "Record Reference Manual" states that the FLNK record field has the
  > following behavior:

  > 	"This field is a database link. If FLNK is specified, processing this
  > record
  > 	 will force a processing of the scan passive forward link record"

  >   I have an input record for which the SCAN field is set to a periodic
  > interval; however, I need to force processing of this record when the
  > corresponding output record -- both records reference the same hardware
  > register -- is processed. This is necessary to provide a timely update of
  > the input record's value so that subsequently processed records, which
  > reference this input record, obtain the current register value.

  >   One means to achieve this behavior, which I am currently using, employs a
  > "dfanout" record to write to the output register and to the VAL field of the
  > input record. Another method would be to make the SCAN field of this input
  > record "Passive" and to have a dummy record with its SCAN field set to the
  > periodic interval and its FLNK field directed to the input record.

  >   Is there a better way to do all of this? What is the reason for
  > restricting the forward link action only to records that have their SCAN
  > field set to "Passive".

  > 											Fritz

References:
Forcing a record to be processed J. Frederick Bartlett

Navigate by Date:
Prev: RE: PPC compiler splits up ints & shorts? Lawrence T. Hoff
Next: Re [18] Rebekah Leary
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  <20042005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Forcing a record to be processed J. Frederick Bartlett
Next: PPC compiler splits up ints & shorts? Laznovsky, Michael
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  <20042005  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 ·