Re: RAWF, RAWL

[Benjamin Franksen <franksen@mail.bessy.de>]

Andrew Johnson wrote:
> 
> Benjamin Franksen wrote:
> >
> > (1) Assume (and demand!) that device supports check the LINR field to
> > see if it is LINEAR before they set ESLO and EOFF. I believe most of
> > them do. Add the check to the remaining ones.
> 
> There are 10 ai/ao device supports in base 3.13.4 which set eslo; none of
> them check the linr field.  How many external drivers will have been
> derived from these and follow the same pattern?

I admit that I haven't looked too carefully at existing device supports.

> > (2) Forget the idea that device support sets EGUL and EGUF (instead of
> > ESLO and EOFF) if LINR==LINEAR_MANUAL. Call dset->special_linconv() only
> > in case LINR==LINEAR.
> 
> More sensible, but do we actually need a manual setting other than to
> solve the problem with raw soft support?  IMHO we shouldn't try to fix
> that at all right now, given that it'll be trivial once link support is
> available.

Interestingly, whenever I talked about this with colleagues, I received
the impression that *being able* to set ESLO and EOFF directly instead
of letting device support do it, would be appreciated as a matter of
*more convenience and tranparency* in a number of cases, regardless of
whether device support is able to do so or not. I won't put this against
architectural considerations.(*)

I want to mention just one situation that was pointed out to me, where
specifying ESLO is a lot more natural than any EGU limits, namely motor
position readbacks. Here, the obvious value known to the engineer is the
number of steps per unit of distance traveled (or the inverse of that
value), and any EGUF and EGUL values are quite counter-intuitive if not
to say abstruse.

I am convinced that there are a number of not-so-very-special situations
out there, where a similar reasoning applies. At BESSY I am now and then
involved in the continuing efforts to integrate more of the beamline
control stuff into a an EPICS based (and therefore machine control
dominated) framework. I have more than once run into the uncomfortable
situation where I have to explain to control system engineers why our
beloved and praised EPICS does not allow them to simply set the
conversion factor and - the hell - be done with it.

There are a lot more analog signals than those simple ADC or DAC values
for which the EGUF and EGUL approach is indeed the more appropriate one.

> I do like the idea that the LINR menu be dynamic based on the available
> breakpoint tables and the addition of dbd-specified custom conversion
> subroutines, but note that CA currently has a protocol limit of 16 state
> strings for each enum.

I know that too well. I am reminded of it each time I forget and try to
monitor a record's STAT field with MEDM.

> However I'm in the process of completely rewriting
> dbStaticLib in C++ for the link support implementation (planned for the
> 3.15 release, whenever that happens), although it will retain its C API as
> well.  Your YAPFAC proposal might be appropriate for the 3.15 release, but
> your effort will be wasted and have to be duplicated if you work on it any
> sooner.
> 
> PS: I hate damping down flames of enthusiasm, but I have the long-term
> future of the EPICS architecture in mind.

I will not repeat my private answer to that here.

I love object oriented software architecture, the more so when based on
a sound object oriented language, but I ask myself if the decision to
use C++ inside the EPICS core was really a wise one. I know that a
colleague you know very well by now, has done exactly one thing during
the last two or so weeks when he worked at BESSY again: Try to make
adjustments to 3.14 so that it compiles under HP-UX 11.0.

The only hope is that the problems with widely differing, incompatible
and incomplete C++ compilers [not to speak of the so called "language
standard" (every year Mr Stroustrupp adds more features as he finds that
he forgot to build them into the language the last time) or the even
more ridiculously named "standard library"] will diminish in the future.
Unfortunately, the experience gathered so far over the last decade does
not really support that hope.

Ben

(*) Especially not if these considerations apparently lead to a
"complete re-write in C++" of a perfectly functional (and easily
extendable) module.
-- 
Berliner Elektronenspeicherring-Gesellschaft für Synchrotronstrahlung
(BESSY) GmbH, Control System Group
Albert-Einstein-Straße 15, 12489 Berlin, +4930 6392 8462, www.bessy.de