Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  <19961997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  Index 1994  1995  <19961997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017 
<== Date ==> <== Thread ==>

Subject: Re: Should ai, ao records have RAWH, RAWL?
From: mooney@aps.anl.gov (Tim Mooney)
To: tech-talk@aps.anl.gov, mrk@aps.anl.gov
Date: Wed, 9 Oct 1996 16:28:07 -0500
> From mrk@aps.anl.gov Wed Oct  9 09:43 CDT 1996
> ...
> Last week during a visit at DESY, Gabor Csuka
> suggested that the ai and ao records should have two additional
> fields RAWH and RAWL. The reason is that often it is possible
> to create common device support for a set of modules that differ
> only in the number of bits and/or polarity.
> 
> I expressed concern that this opens door to an unlimited
> set of configuration fields. After discussion I had to agree
> that these two fields  are generic enough that perhaps
> we should add them. They would not impact any existing support
> but future support could use them.
> ...
> Comments anyone?
> 
> Marty Kraimer

I don't like it.

It doesn't help enough to justify the additional device dependence it
introduces into the records.  (It would be irrelevant for most serial
and GPIB devices, for example.)  Also, it's so easy to use the link's
'parm' string for this kind of thing.

> From wlupton@hapuna.keck.hawaii.edu Wed Oct  9 13:27 CDT 1996
> Is there any mileage in defining some conventions on use of the PARM field
> (would have to be bus-specific I suspect) to accomplish such things? Such
> information could be thought of as a sort of DTYP sub-addressing, so what
> now requires a different DTYP could in the future require the same DTYP
> but a different PARM.

I think this is a great idea.  We were forced into this kind of thing
doing conversions to/from strings and Ai, Ao, Li, Lo, Bi records.
(This was in Hideos-based serial device support, but the need is
general.)  With our new device support, all of these records can use
parm strings of the form "TERM=0d0a,IX=3,FMT=%lf,TO=300,..." to
specify, in this example, that the serial task should look for a \r\n
terminator, timeout after 300 ms, ignore the first three bytes of the
returned string, and convert the remainder from string to the val field
using sscanf(s, "%lf", &ai->val).

Now we have one device-support module that supports all kinds of serial
devices, we didn't have to wait for a new release of EPICS to make it
work, and we won't have to wait for yet another release to extend it.
However, in 3.12, the vmeio parm string is only 32 bytes long--not long
enough to use all of the possible parameters at once.  Irk!  (Can't
wait to port all this to 3.13, which appears to have no restriction on
the length of the parm string.  Yay!!!)

Tim


Navigate by Date:
Prev: Re: Should ai, ao records have RAWH, RAWL? Nick Rees
Next: Job Opportunity at Argonne/APS Bill McDowell
Index: 1994  1995  <19961997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017 
Navigate by Thread:
Prev: Re: Should ai, ao records have RAWH, RAWL? Nick Rees
Next: Re: Should ai, ao records have RAWH, RAWL? John R. Winans
Index: 1994  1995  <19961997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017 
ANJ, 10 Aug 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·