Experimental Physics and
Industrial Control System

"Redman, Russell O." <[email protected]> · Mon, 13 Aug 2001 18:47:20 -0700

I take it all back (or most of it anyways)!  I apologize for leading Marty
and Benjamin on what seems to have been a wild goose chase!  I was using an
obsolete version of the ipac drivers and
<long-explanation-of-why-I-did-not-read-the-documentation deleted>.  For my
immediate needs, the CAN address parameter for the ao/ai device drivers does
what I need in almost all cases.  I will update my version of the ipac and
canDev drivers, rewrite my EPICS database to use the CAN address parameter
to set EOFF and ESLO properly and sit quietly in the corner.

Or pretty nearly quietly.  There are still two cases where I see a real
utility in being able to specify RAWL and RAWF.  

Andrew's canDev drivers assume that the range [RAWL, RAWF] always has the
form [0, N] if the parameter is greater than zero, or [-N/2, N/2 - 1] if the
parameter is less than zero.  At least one of my records is setting a
frequency that must lie within a range [FMIN, FMAX] and is sent over the CAN
bus as a binary integer.  It would obviously be nice to set EGUL = FMIN and
EGUF = FMAX, but the binary integer is not 0 at FMIN.  There are easy
work-arounds, but they are all a bit ugly and require the logic to be
explained in the documentation.  To handle these messy cases, it would be
nice to be able to set both ends of the range independently. 

The other place I can still see a possible use for RAWL and RAWF is in
simulation records linked to the control records in the database.  It would
be ideal (from my perspective) for the simulation records to read raw values
from the control output records and to write raw values back to the control
input records, but to use physically meaningful values internally.  This, of
course, is exactly what EOFF and ESLO were designed to do, except that
simulation records necessarily do not use device drivers to set EOFF and
ESLO.  An easy work-around is to set the AOFF and ASLO fields manually in
the simulation records, but that gets us back to the maintenance problems I
raised in the earlier discussion.

I am lucky that I have only one generic bus (CAN) to deal with.  I have not
looked at the other bus types (GPIB, etc.) to see if they make similar use
of a parameter in the device address to set EOFF and ESLO for remote
devices.

Marty, is it worth the bother to back out of the changes you made to add
RAWL and RAWF?  Or are there enough special cases, and sufficient utility in
simulation records to justify retaining RAWL and RAWF?

Cheers,
Russell O. Redman

-----Original Message-----
From: Andrew Johnson [mailto:[email protected]]
Sent: Monday, August 13, 2001 12:31 PM
To: EPICS tech-talk
Subject: RAWF, RAWL

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