Marty writes:
------- start of forwarded message (RFC 934 encapsulation) -------
> Item 1.
> We have noticed the following behavior in the MBBO record when we have
> a constant DOL field.
...
> The net effect is that VAL never has the value of DOL if DOL is a
> constant.
>
I think that this is the exact same problem pointed out by William Lupton a
short time ago. There were a few E-mail messages (not many) that gave
contradictory recommendations about what to do.
This is a small part of the problem of what to do about outputs when an ioc
reboots. Here are some possibilities:
1) It an output device provides the ability to read the current value
of the output, then the initial VAL of the record should be set to the
ENG value associated with the raw value read from the device.
THIS is the method used by most epics supplied device support.
2) If 1) is not possible do not write anything to the device until the record
is processed the first time. Note that this may not always be easy.
Normally an output device has many signals (ao have multiple channels,
bo has may bits) that are all written simultaneously. These signals
are shared by multiple records. When one record requests a write ALL the
signals are written.
3) Accept initial value from user. In above message a CONSTANT link value
was used to attempt this. One problem currently is that we cant distinguish
between the user actually specifyiing a constant link value and the user
not specifying any value for a link.
Note that the message above shows that the record/device support did this
UNLESS 1) was possible.
Can we even define a valid set of things to do? let me give an example.
If a true warm reboot ios being attempted, i.e. the system is operational
and running just fine, always do 1).
If the system is being cold started do 3)
How do we distinguish between these in an automatic mannor? We cant expect
a human to make these decisions on a record by record basis when a system
is booted.
>
> Item 2.
> Bob Dalesio mentioned that a field known as "IVAL" used to exist on
> the MBBO record. The purpose of this field was to allow puts that were
> not of type DBR_ENUM into the VAL field thus circumventing the
> complaints from put_enum_string(). This is a useful feature if you
> have no state strings and associated values defined (SDEF=0).
>
This was available in gtacs but never if epics. I dont remember the details
but it was somthing almost impossible to save in going to extensible
record/device/driver support, whicjh was the main feature epics provided that
gtacs did not.
Again I maintain that the main problem is using mbbi,mbbo records for holding
arbitrary integers.
Marty Kraimer
------- end -------
- Navigate by Date:
- Prev:
error handling Jeff Hill
- Next:
Re: GCC for EPICS Unix code? William Lupton
- 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:
MBBO record support Peregrine McGehee
- Next:
EPICS status codes proposal William Lupton
- 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
|