Experimental Physics and
Industrial Control System

Benjamin Franksen <[email protected]> · Mon, 20 Aug 2001 23:12:15 +0200

Andrew Johnson wrote:
> 
> Benjamin Franksen wrote:
> >
> > Andrew Johnson wrote:
> > >
> > > 3. Changed a*Record.c in both init_record() so that EOFF is only set to
> > > EGUL if LINR=LINEAR and a pdset->special_linconv() routine exists
> >
> > Problem: Must do that also if LINR=LINEAR but pdset->special_linconv()
> > does not exist. There might be device supports without special_linconv
> > and applications that nevertheless rely on EOFF being set if
> > LINR=LINEAR. Compatibility wouldn't be complete without retaining this
> > behavior.
> 
> The absense of a pdset->special_linconv() routine is how I was
> distinguishing Raw Soft support from devices that already have a useful
> definition of it, and hence make Raw Soft support useful in 3.13.  Without
> including this in the test the behaviour of Raw Soft support will change
> between 3.13 and 3.14 because the 3.13 apps will have to put the offset in
> EGUL, but in 3.14 they should move to EOFF (and probably switch to
> LINR=SLOPE, but my change allows them not to have to do that).  In fact
> without this, we might just as well drop the idea of making EOFF
> modifyable at all for 3.13 and just have people set EGUL and ESLO.  I'm
> not too keen on that though, as it will definitely require a change when
> such apps upgrade to 3.14.  By making Raw Soft Channel useful, we're going
> to increase the number of applications that actually do use it, so there
> will proabbly be more conversion work needed overall in going from 3.13 to
> 3.14 than there will be now in adding my change.

> [...]

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

The crash scenario (meaning wrong values and nobody knows why) would
involve some device support without special_linconv and a database where
EGUL is set and and LINR=LINEAR. I realize that this sounds theoretical
and could rightly be viewed as a conceptual error. The problem is that
"finding an app that this would actually break" is actually not so easy.
Problems like these are hard to find. We have a lot of database designs
out there, nobody knows anything about, except they do the things they
are supposed to do. Developer not too bright in the first place, perhaps
gone from the facility long ago and nobody ever touched the thing. Would
you want to check all the device supports in use at your site, see if
they do not contain a special_linconv, then check all the records in all
the databases with corresponding DTYP if they have LINR=LINEAR and also
EGUL set?

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!

Let us not go on providing any more half-hearted kludges like that. I
agree that making Raw Soft support useful for linear conversion is not
possible without sacrificing compatibility. But then let us not squeeze
it into 3.13. I'd rather have *none* of these new features in 3.13 and
instead a clean break in 3.14, with a new choice for conversion and an
error reported if LINR=LINEAR and non-existence of special_linconv
collide. In the meantime let people use a calc record like they always
had to. IMHO, at least, this is the right thing to do.

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