> [...] read the global variable at record initialization time [...]
> Comments?
Sure:
As low level inputs should IMHO always reflect the status of the
underlying devices (or structures) as close as possible, I see no
problem reading the variable value at init time.
Nevertheless, the variable support is so generic that you could think of
a situation where you don't want the record to read that variable until
a certain point, which may be well after record initialization. (Maybe
the first processing being triggered by the underlying task after it
wrote the variable for the first time.)
The PINI field could handle these two cases cases for input records.
For an output, I can think of three reasonable choices that may be
controlled without having to introduce another field in OUT:
1. PINI = NO, DOL = don't care
If DOL is constant, set VAL to it, but don't do anything else . The
underlying application takes care of all initialisation issues. When
the value is set from the database or CA, write the variable.
2. PINI = YES, DOL is set (constant or link)
Write the constant (OMSL being supervisory) or DOL-fetched (OMSL
being closed_loop) value to the variable.
3. PINI = YES, DOL is not set
Read back the variable value at startup. (I.e. the application set it
to some meaningful value before record initialisation.)
The only problem could be that the default value for DOL changed between
some betaSomething revisions of 3.13.0 and older versions cannot distinct
between DOL not being set and being set to CONSTANT 0.
Some of the database configuration tools (i.e. CapFast) do not handle
the new situation correctly. Users may have problems as they might not
be able to _not_ set a DOL field. (CapFast drawings tend to set all
record fields even if the values are default. The CapFast conversion
tool configuration has to be changed to reflect the dbStatic changes.
Still there might be a difference between setting a record field to the
empty string and not setting it at all.)
What do you think?
Ralph
- References:
- VxWorks global variable device support William Lupton
- Navigate by Date:
- Prev:
January Notes for non-us individuals. Leo R. Dalesio
- Next:
cd2400 or z85230 serial driver ioctl options Porter, Rodney
- 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:
VxWorks global variable device support William Lupton
- Next:
Re: VxWorks global variable device support 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
|