Experimental Physics and
Industrial Control System

Andrew Johnson <[email protected]> · Mon, 13 Aug 2001 14:31:19 -0500

I want to revisit the discussion about the proposed RAWF,RAWL additions to
ai/ao records - I was on vacation when this occurred, and I'm not happy
with what I understand the proposal to be.

The original problem raised by Benjamin Franksen was:
> Main problem is that raw soft support does not (and cannot) set EOFF and
> ESLO. Cannot, because maximum and minimum raw values are not known.

Russell Redman added this:
> I too would like to be able to configure the maximum and minimum raw values
> for Raw Soft Support in ai/ao records.  I deal with all of my hardware
> remotely, over CAN bus and serial connections, so I must do the conversions
> into raw values without the benefit of device support.  At the moment I am
> using AOFF and ASLO, but it would be much cleaner if I could specify the
> ranges [EGUL, EGUF] and [RAWL, RAWF], letting the Raw Soft Support calculate
> EOFF and ESLO.

For CANbus I/O (assuming you're using my driver) you can specify the raw
CAN data format for use with AO and AI records in the parameter part of
the hardware address - see section 3 of the devCan documentation at
http://www.aps.anl.gov/asd/people/anj/ipac/devCan.html  I don't really
understand how you're using raw soft support in conjunction with CANbus
I/O, but I accept that there may be other reasons for this.

My objections to adding the RAWF and RAWL fields are the effect on other
device support.  One of the advantages of EPICS' generalization of all
ADCs to an aiRecord is that to change to different hardware, you only have
to change the Device Type and hardware address.  The device support knows
about the ADC/DAC format and sets ROFF, EOFF and ESLO accordingly.  All
existing field-bus device support for ai/ao that doesn't know how wide the
relevent ADC/DAC is has the ability to set the raw data width somewhere in
the hardware link address.  Logically the same approach ought to apply to
the raw soft support, but this can't easily happen until link support
becomes available, at which point the raw range can become part of the
link address (I am working on link support, when I can fit it in!).

If we add RAWF and RAWL, some device supports for configurable hardware or
field busses may start to use these fields, and we're then in the position
where you have to remember to set these fields (or delete them) as well as
changing the address.  We would no longer have a generic record type,
because newer device supports may look at these fields but older ones
won't.

I agree that we might want to look again at the whole ADC/DAC to
Engineering conversion area sometime, but personally I think that adding
RAWF and RAWL to ao/ai is not a good solution - it makes raw soft support
more useful, but is architecturally wrong IMHO.  You might be better off
using a subroutine or calc record, which is what tends to get used at
other sites, or maybe create a conversion record type to do this kind of
processing for you.

- 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