Experimental Physics and
Industrial Control System

Benjamin Franksen <[email protected]> · Tue, 21 Aug 2001 15:24:59 +0200

Andrew Johnson wrote:
> 
> 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.

Ok, if this is the rule I take it all back and we can do it the way you
proposed for 3.13.

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

I know that and considered it, see below. I accept your objections,
though. What we are going to do, then, is set up the following rule:

"If an analog device support provides no special_linconv, field LINR may
be set to LINEAR. In this case, configuration values for ESLO and EOFF
are guaranteed not to be changed by record support nor by device
support's init_record. They are then used for linear conversion
unaltered, except for possible updates from outside agents via dbPut."

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

I say this only so you understand the difference: I only wanted to make
the combination non-existence of special_linconv *and* LINR=LINEAR
illegal. This is why the check cannot be made at init time, since LINR
can be changed at any time. It would mean that with such a device
support, setting LINR=LINEAR would not be a legal option anymore. This
would be fine because we had the SLOPE conversion as a replacement then.

I no longer insist on this solution, but it would still be a good thing
if we could somehow detect such situations, maybe with a special command
line tool rather than an eror message at init time.

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

I thought if device support returns 2 this means that *no* conversion
takes place, not even SLOPE. From what you said it appears you want to
allow record support to apply SLOPE conversion even if device support
returns 2, correct?

If we did that, Raw Soft support would no longer be needed for linear
conversion since the normal Soft support would achieve the same, even
better, since we could use double as input value type instead of long.

That'd be ok with me, although I have the feeling that this is a rather
more drastic change to the analog records. "Return 2" would change its
semantic from "no conversion, please, I've done that" to "I have done
some conversion and put the stuff in VAL, not RVAL, but go on converting
if you really want to".

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

Yes. A total rethink could untangle the thing better than all the
proposals brought forward up to now. For example, the "return 2" logic
as discussed above has the general disadvantage that users have no way
to tell except to look at the device support sources. A better solution
would provide the information as a parameter to the device entry in the
dbd file.

> How did we get to change places on this issue?  

I have asked myself the same question!

> You were upset at me for
> objecting to change a few days ago, and now you're taking the conservative
> (small-C) position!  

You are right about the "conservative position" but misunderstood that I
was upset about your objections to changes. I thought I made it clear
that I appreciate your warnings about compatibility and possible
dead-ends. I was upset when you told me that you planned to re-implement
dbStatic in C++. Because it appeared to me that it could be easily
extended, instead of re-writing it from scratch, so this would be a
waste of effort and cause unnecessary delay. Besides I hate C++. Maybe I
was wrong and you have really good reasons for this, although I still
have problems imagining how any C++ implementation of dbStatic could be
better than the current one. I could have asked, though, before
critisizing, so that's what I am doing now.

> I suspect that nobody else really cares enough to
> have bothered to read this far into this debate.

Probably. I am a little weary of it, too. There is always so many things
to consider and none of the solutions so far are what we *really* want.

Ben
-- 
Berliner Elektronenspeicherring-Gesellschaft für Synchrotronstrahlung
(BESSY) GmbH, Control System Group
Albert-Einstein-Straße 15, 12489 Berlin, +4930 6392 8462, www.bessy.de

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System