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: npr@jach.hawaii.edu (Nick Rees)
To: tech-talk@aps.anl.gov
Date: Wed, 9 Oct 1996 10:06:43 -1000 (HST)
> 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.
> 
> For example if a device is a bi-polar 12 bit adc the fields would
> be
> 
> RAWH 2047 RAWL -2048
> 
> If the device is a 14 bit unipolar adc the fields would be:
> 
> RAWH 16383 RAWL 0
> 
> 
> Comments anyone?
> 
> Marty Kraimer

Andrew Johnson and I went through this when developing the CANBus
driver. We are using the INST_IO link type for most of our new drivers
and just treat it as a free format string to contain this, and other
sorts, of information. For example, the Canbus link syntax is like:

<Bus name>/<Timeout>:<Can Identifier>.<offset> <misc parm>

The /<Timeout> is optional.

For ao and ai records, the final parameter specifies the raw output
size.  eg 0xfff or 0x1000 specify a 12-bit unsigned value. -ve numbers
specify a signed value, eg -256 means an 8-bit signed (two's
complement) value. Offset binary is handled by the existing AOFF
field.

For bo and bi records, the final parameter specifies the bit number,
with the offset specifying the message byte number.

With regards to Bill Browns comment, I also implemented a 2534 driver
(to a certain extent as a learning exercise) and one of the things is
that this card is so configurable that Bill's auto detection mechanism
only works in some configurations (and mine wasn't one of them). Hence
I added a syntax in that a hyphen in the parameter field inverts the
bit. I also needed to be able to use the card as an analog input in
which the bits are read in parallel and treated as a binary number.
This implementation used a similar syntax to the canBus driver to deal
with number sizes and offsets.

We also use Jeff's Allen Bradley AbDf1 driver, which has a free format
link syntax. This doesn't support different analog input sizes, but in
many ways it is similar to the CANbus system with word and bit offsets.
Different analog input sizes would be trivial to implement, and as soon
as someone connects anything other than a 12 bit DAC to a PLC there
will suddenly be demand for it, and I feel it would naturally be done
in the same way as the CANbus implementation.

I am happy with all this and it retains the existing structure where
the number of significant bits in the hardware, plus other hardware
dependent quantities (such as alignment) are only known to device
support. The catch is a more complicated link syntax, but nearly every
driver I use has a different syntax and so I long ago accepted that I
would just have to learn the ones I need.

Jim said:


Nick


Navigate by Date:
Prev: Re: Should ai, ao records have RAWH, RAWL? Jim B. Kowalkowski
Next: Re: Should ai, ao records have RAWH, RAWL? Tim Mooney
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: Should ai, ao records have RAWH, RAWL? LUCHINI
Next: Re: Should ai, ao records have RAWH, RAWL? Tim Mooney
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 ·