Experimental Physics and
Industrial Control System

Andrew Johnson <[email protected]> · Thu, 30 Aug 2012 12:47:56 -0500

Hi,

On 2012-08-29 Benjamin Franksen wrote:
> > > Here, RAWL and RAWF are the lowest resp. highest possible raw value.
> > > For instance, a 16 bit bipolar ADC might have RAWL=-0x7fff,
> > > RAWF=0x7fff.
> >
> > Did RAWF and RAWL ever exist in a 3.14 release?
> >
> > A quick search through VCS history shows that these fields only existed
> > briefly between 3.14.0-alpha2 and -beta1 (circa 2001).
> >
> > It would be nice to have them, then linear conversions would be
> > unambiguous defined by fields and we could do without special_linconv().
> 
> It's interesting that you ask. When I wrote the above lines I did not
>  suspect that they had ever been actual fields, once. I used them only as a
>  notational device, though I agree that it would be much nicer to just let
>  device support set RAWF and RAWL (as part of init_record); the record
>  support could then calculate ESLO/EOFF from these and EGUF/EGUL -- and the
>  other way around, too, e.g. user changes EOFF or ESLO => record support
>  updates EGUF and EGUL.
> 
> Is this a change that could be made for 3.15 or is it too disruptive?

It should be possible to make that change be backwards-compatible with 
existing device support, in which case this could be added to 3.15, although 
things are already getting a bit complex in this area and there's a major 
gotcha that I discuss below.

Here's how it could be made to work: New device support would not provide a 
dset::special_linconv() routine, instead of would set RAWF and RAWL in the 
dset::record_init() routine.  These fields would default to both zero, so the 
record code in aiRSET::special() can detect a new device support because it 
has dset::special_linconv == NULL and at least one of the RAWF/RAWL fields 
would be non-zero. In this case it would calculate ESLO and EOFF itself from 
EGUF, EGUL, RAWF and RAWL.

However now we must add the complications of extended device support that 
provides dsxt::add_record() and dsxt::del_record() routines. In this case the  
code in dsxt::add_record() would set RAWF and RAWL instead of that being done 
by dset::init_record(), and the dsxt::del_record() routine would reset them 
back to zero again.

The problem is that no record routines get run when dsxt::add_record() is 
executed (i.e when someone writes to the INP/OUT field to change the hardware 
address), so the record doesn't know that the RAWF/RAWL values have changed, 
which should trigger a recalculation of ESLO/EOFF.  We probably wouldn't want 
to do that recalculation every time we process the record because the IOC must 
run on small CPUs that do all their floating-point operations by hand, so we 
minimize such calculations where possible.  That means the dset::add_record() 
code would have to remain responsible for calculating ESLO and EOFF itself (as 
it currently should do when prec->linr == menuConvertLINEAR).

As a result I don't see a huge advantage to adding the RAWF/RAWL fields to the 
current ao and ai records (but I could still be persuaded if someone wants to 
show me that my reasoning is wrong).

I /could/ see enhanced ai and ao record types being written that have a much 
richer interface to their device support, so the device support could call 
routines provided by the record to tell the record about its capabilities and 
set its value instead of just poking random fields directly.  The advantage of 
doing something like this would be that the record code doesn't have to 
continue to support device types from the 1990s, and it might even be possible 
to design a universal interface that works for multiple record types...

- Andrew
-- 
Never interrupt your enemy when he is making a mistake.
-- Napoleon Bonaparte

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System