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: ai/ao RAWL RAWH
From: csuka@desy.de (Gabor Csuka)
To: tech-talk@aps.anl.gov
Cc: csuka@desy.de (Gabor Csuka)
Date: Thu, 10 Oct 1996 14:37:46 +0100 (MET)
Dear All,

After 10 comments, I try to make mine:

There is one general question - the place of the device 
dependent parameter(s)  part (if any is needed) and the
driver configuration / reconfiguration etc. But this is
a thema for a workshop.  


A record has a common part which is same for each record
and a record specific type. In each part can be a device
dependent part. This moment the existing field is DTYP,
DPVT (in common) and as an example ESLO, ROFF, INP/OUT for ai/ao.
and MASK field for bi/bo.

This is also clear, it is not possible get the all configuration
parameter from the hardware (as the suggestion of Jimm) while
not the all hardwere has this functionality. (e.g. CAN,h1,
profibus moduls has no this functionality.)  From this
it is clean this information can be hardcoded in the device 
support module, or getting as a parameter. From the example
below both of them is used yet. (Alen Braedly has separate
device support, Can, (all of three implementation) H1,
atc. ) useing 'encrypted' INP/OUT specification :


<Bus name>/<Timeout>:<Can Identifier>.<offset> <misc parm>
INP  #C2 V"2-DI0-0..15" M"can" N300 I0 W2 L0 H4095
  

Other VME cards using the PARM field of VME IO adding this
dinamic information.

> parm strings of the form "TERM=0d0a,IX=3,FMT=%lf,TO=300,..." to

so the information is there. The question is: the RAWH and RAWL 
is enough common device specific for adding ai/ao (and getting
nice support for this fields) or keep them 'encrypted' and
hidden. 

Go back to the INP/OUT specification. See the DESY CAN:
 
INP  #C2 V"2-DI0-0..15" M"wm_ai" N300 I0 W2 L0 H4095
       |       |           |       |   |  |  |    |
       |       |           |       |   |  |  |    +-  raw value high
       |       |           |       |   |  |  +------  raw value low
       |       |           |       |   |  +---------  data type and length
       |       |           |       |   +------------  offset/index
       |       |           |       +----------------  CAN ID
       |       |           +------------------------  Can module name 
       |       +------------------------------------  Variable name
       +--------------------------------------------  CAN controller ID

{ general IO point description             }{ ai/ao specific }

this description has (and need) two parts , the general one
and the record type dependent one. Why I keep them in one field ?

If the specific one is INDEPENDENT from the device why 
the device dependent part makes the support for it ? 

This moment we on the way to adding separate support 
in each inteligent 'devise' (useing separate device support
roitine per module, or useing encrypted string and analise
it in devise support at init time ? ) 

My suggestion adding this two field to ao/ai is a way 
to start some generic solution instead of learning 
hundreds of 'encrypted' syntax. 

Regards, 

Gabor Csuka
DESY


Navigate by Date:
Prev: Job Opportunity at Argonne/APS Bill McDowell
Next: R3.13.0beta2 Bill Brown
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: Job Opportunity at Argonne/APS Bill McDowell
Next: R3.13.0beta2 Bill Brown
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 ·