Experimental Physics and
Industrial Control System

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

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.

In talking to Ned just now though I've realized a slight disadvantage of
this - RVAL is a LONG, so all pre-conversion values will get truncated
into an integer on their way through the device support.  There is no way
to avoid this unless we copy all the conversion code into the
devA*RawSoft.c files, which is getting very yucky.  If it's a problem, use
a calc record...

> > 4. Change the special() routines to only do the following if LINR=LINEAR
> > and a special_linconv() routine exists:
> >    a) Save EOFF and ESLO values for checks below
> >    b) Set EOFF=EGUL and call pdset->special_linconv()
> >    c) Call db_post_events(EOFF) if the EOFF value was changed
> >    d) Call db_post_events(ESLO) if the ESLO value was changed
> 
> See above (Set EOFF=EGUL also if pdset->special_linconv() does not
> exist).
> 
> This should not be changed before 3.14.

Disagree, and see above argument.  If LINR != LINEAR then the EOFF value
is not currently used at all.  Nobody is likely to be monitoring the ESLO
and EOFF fields because they haven't posted monitors anyway up to now (if
anybody was then their application is currently broken and this might fix
it).  By making the change I described I'm allowing Raw Soft support to be
useful for linear conversions in 3.13, in a way that will be compatible
after a 3.14 upgrade.  If I remove the conditionality on special_linconv()
then we're guaranteeing that the app will need changing for 3.14.  I think
this is more useful than maintaining totally strict compatibility (which
is impossible anyway if you're going to make any changes).  Unless someone
comes up with at least one example of an application that my 3.13 change
will break I see no reason not to make it, as it provides additional
facilities.

> Don't forget to extend menuLinr.dbd too.

Actually we noticed that menuLinr is never actually used, so I've removed
it completely from both 3.13 and 3.14.

> I've been thinking about the most harmless position of the new choice
> SLOPE, before or after LINEAR. After LINEAR would be best for
> applications that assume LINEAR==1. On the other hand, applications that
> assume breaktable names start after LINEAR would be better off if we
> place it before LINEAR. Since the latter assumption is better style than
> the first, I'd vote to put SLOPE before LINEAR.

I think that's getting pretty theoretical, but it seems a reasonable
argument so I've moved SLOPE as you suggest.  This should at least bring
to light (i.e. break) any apps that aren't using the generated header
files properly.  Warnings about such changes have been given before, so I
don't think we need to make any extra special effort about this other than
inclusion of a suitable warning in the release notes. I don't think the
Raw Soft Channel device support is really documented anywhere at the
moment (recRef manual?), but if it is then this documentation needs
updating.

- 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