EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

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

Subject: Re: VxWorks global variable device support
From: Benjamin Franksen <[email protected]>
To: [email protected]
Date: Thu, 03 Feb 2000 14:08:21 +0100
William Lupton wrote:
> 
> Ralph,
> 
> ------------------------------------------------------------------------
> Re how to control initialization of output records:
[...]
> >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.)
> 
> So, the variable value is read back at startup only in the last case. So
> this could happen inadvertently if:
> 
> a) there is a tool out there which defaults DOL to "not set" rather than to
>    "constant zero" (we agree that Capfast is not such a tool; maybe there
>    are no such tools)
> 
> b) someone has previously created a database with DOL set to an empty or
>    blank string (which will be interpreted as "not set") and has _intended_
>    that to be the initial value written (this would probably be unintentional
>    for anything other than a stringout?)

As regards (a), there is definitely a tool out there, it's called DCT.
At least in the newest version it does not initialize DOL to anything if
you don't explicitly specify so. I'd say that defaulting DOL (or any
other link field) to "not set" is the correct behavior since 3.13, at
least that's what the release notes suggest.

So, IMHO, case (a) is the rule rather than the exeption. Case (b) should
be regarded as an error in the database design, at least for databases
that are supposed to be 3.13 compatible (see, again, release notes for
R3.13).

I want to add a remark on Capfast: Neither the program itself nor the
conversion tools have any defaults for record fields. It's the symbols
(*.sym) and the edb.def that determine which fields are set by default
and to which value. The old behavior was to initialize all link fields
to something like "0.000000000" (lots of "0"s, never understood why).

To make Capfast compatible with 3.13, I went through the work of
adapting the symbols and the edb.def for R3.13.1 (or whatever release
number actually introduced differentiating between "0" and "" for
links). The changes (i.e. throwing out any defaults with a zero value)
can be done automatically with little perl script.

Ben
-- 
The Notorious Neb Nesknarf


References:
Re: VxWorks global variable device support William Lupton

Navigate by Date:
Prev: Re: Python/CA Noboru Yamamoto
Next: Re: VxWorks global variable device support Ralph . Lange
Index: 1994  1995  1996  1997  1998  1999  <20002001  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 William Lupton
Next: Re: VxWorks global variable device support Ralph . Lange
Index: 1994  1995  1996  1997  1998  1999  <20002001  2002  2003  2004  2005  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 ·