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
<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:
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
<2004>
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|