>
> > I don't like to have to process the output records and cause
> any resulting
> > processing just to get the current value of an output record
> after a reboot,
> > so it would be great to add the selectable readback to all
> output records
> > or add something like RINI (read at initialization) to read but
> not process.
>
> While we are on the subject (which has diverged somewhat from the original
> one), I have often had the similar problem caused by rebooting fieldbus
> modules but not the IOC. In this case I have occasionally wanted my output
> record to readback the new value (post-reboot) from the fieldbus module,
> rather than set it to the last EPICS value. Hence I have always felt there
> was a better way of handling this re-initialization of output records.
>
> I have also found the treatment of all these things a bit inconsistent -
> especially as the code resides in device, rather than record, support (and
> so is developed by a greater number of programmers). One thought I had was
> to support a read routine in device support of output records, and then
> move a bit of the logic back into the record. We could also support a
> callback when the output hardware re-inialises. I admit that this is
> difficult to make backwards compatible.
>
The current version of the DF1 serial protocol driver for Allen Bradley PLCs
constantly scans the output values in the PLC, and if they are changed by
some action outside the control of the IOC, then the output record is forced
to update itself, and its CA clients, via faked asynchronous record
processing
completion. I agree that it would be preferable to include a read routine in
the output record's device support entry table together with a standard
mechanism
for signaling to output records that it is a good time to reread the
current state of the hardware.
This would provides the following benefits:
1) iocInit no longer blocks for devices that are not responding on a slow
field bus
to time out, and therefore output channels will remain in UDF alarm state
after iocInit
completes until the device responds for the first time.
2) CA clients track changes in hardware output changing outside the IOC's
control
a) changes occur from the vendor's local control panel
b) device is powered up
c) communication with the device is restored
Jeff
- Replies:
- support for output records Leo R. Dalesio
- References:
- Re: VxWorks global variable device support Nick Rees
- Navigate by Date:
- Prev:
Re: VxWorks global variable device support William Lupton
- Next:
Re: VxWorks global variable device support Tim Mooney
- 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:
Re: VxWorks global variable device support Nick Rees
- Next:
support for output records Leo R. Dalesio
- 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
|