Experimental Physics and
Industrial Control System

[email protected] (William Lupton) · Wed, 2 Feb 2000 15:01:04 -1000

Ralph,

------------------------------------------------------------------------
Re how to control initialization of output records:
>  > ...I feel that there _should_ be explicit control over whether
>  > output records read the VxWorks variable at initialization
>  > time. Also, I think that this is necessary in order to achieve
>  > backwards compatibility.
>
>I don't think anyone ever set an output record to PINI=YES without
>setting DOL, right? So ... if one uses a tool from the olden days (that
>always puts something into DOL), everything will still work the same.
>
>The only way to mess up things is using an editor or a new db generation
>tool, not setting the DOL field and continue believing that this means a
>CONSTANT 0. (Which isn't true anymore, anyway.) This would make the
>record read the variable unintentionally.
>
>Do you actually think someone might run into this?

I don't think I'd read your initial message carefully enough. I thought
that you were saying that there would be a backwards-compatibility problem
with Capfast (where an unassigned DOL is going to show up as a constant
zero), hence my remark.

Now I've looked at your message (and some of EPICS code) more carefully, and
I realize that you have thought about this a lot and were making some quite
subtle points. You say:

>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.)

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?)

What if the programmer wants PINI = NO and wants the variable to be read
back at init time? This seems reasonable to me: it means that after
database initialization the record will correctly show the value which
is currently in use.

It really does seem to me that, in order to preserve backwards
compatibility and to permit the case of the previous paragraph, we need
some explicit means of specifying that the variable should be read at
init time, and that it should not be read in your case (3) because of
the remote chance of my (a) or (b) occurring.

------------------------------------------------------------------------
Re the new support for direct addresses:
>  > The result is that you can now use VxWorks global variable device
>  > support for direct access to device registers if you so desire.
>
>Which (if the addresses are mapped to VME address space) - *sigh* - pops
>up the topic of semaphore guarding again ... can you promise that all
>kinds of VME accesses on all architectures using all the possible VME IO
>cards are non-interruptable?
>
>You should at least include a warning message in the doc (24pt bold red).

The support for de-referencing has always made such problems possible. The
new support for direct addresses just avoids the need to create a global
pointer. For example, old:

short *pReg = ( short * ) 0xfcff1002;
INP = @*pReg

new:

INP = @0xfcff1002

I agree that the docs should discuss all the locking issues (and, speaking
as a person of color-impaired vision, approve of using several text
attributes to draw attention to the issues).

William

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System