Experimental Physics and
Industrial Control System

Andrew Johnson <[email protected]> · Mon, 20 Aug 2001 17:47:13 -0500

Benjamin Franksen wrote:
> 
> Andrew Johnson wrote:
> >
> > Can anyone find an app that this would actually break?  Most people on
> > discovering that Raw Soft was broken will have switched to using a Calc
> > record instead (which makes a lot more sense IMHO).  I asked Don Dohan to
> > run an oracle search on all the APS databases to find how many ai/ao
> > records we have here where DTYP="Raw Soft Channel", and the answer came
> > back a few, but only for doing breakpoint table conversions.
> 
> I was thinking about "normal" device supports, not Raw Soft.

... and then you proceed to give an example using an abnormal broken
device support, which I don't accept as a valid objection.  We don't
promise not to change things at all in minor releases of base, but we do
try to ensure that we don't affect people who are not breaking the rules. 
It is a rule that analog I/O support should provide a special_linconv()
routine (or do its own read conversions, see below) if the EGU conversions
are to work properly.

> So, the least we have to provide is some diagnostics, an error message,
> so that these errors can be corrected. But if we remove special_linconv
> from Raw Soft and allow it to be used with LINR=LINEAR we cannot at the
> same time report an error!

Giving a NULL pdset->special_linconv() pointer is not an error, else it
would be checked for in the record support's init_record() routine [as is
done for pdset->read_ai()] rather than in its special() routine.  A
pdset->read_ai() routine may return the value 2 indicating that it has
already done a conversion to floating-point and placed that result in the
VAL field.  Similarly the pdset->write_ao() routine is allowed to read the
VAL field instead of RVAL if it wishes (and should return 2 from the
pdset->init_record() routine so back-conversion of the readback value is
not done).  Therefor we couldn't add such check code anyway.

Hmm, that does remind me though that the release notes for 3.14 need to
make it plain to anyone who has written a support layer that returns 2
from their read_ai() function that they need to add the handling of the
new SLOPE conversion to that routine though.  AFAIK only one support layer
does that, the old AllenBradley IXE support (which does have a
special_linconv() routine but ignores changes to the LINR field after
iocInit), although it's concievable that there might be others.  Nobody
else has screamed about this though, so I doubt it.

> Let us not go on providing any more half-hearted kludges like that.

I don't think this in itself is a kludge, but this whole area of
conversions is really ripe for a total rethink (which really needs a whole
new analog record type, but if we're doing that we ought to look at a new
record API first...).  Marty is on his way to China right now and won't be
back for 2 weeks, but he did accept the idea of doing this (and also said
that the whole conversion area needs rewriting).

How did we get to change places on this issue?  You were upset at me for
objecting to change a few days ago, and now you're taking the conservative
(small-C) position!  I suspect that nobody else really cares enough to
have bothered to read this far into this debate.

- Andrew
-- 
The world is such a cheerful place when viewed from upside-down
It makes a rise of every fall, a smile of every frown

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System