Argonne National Laboratory

Experimental Physics and
Industrial Control System

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

Subject: drvAscii
From: Allan Honey <ahoney@hapuna.keck.hawaii.edu>
To: tech-talk@aps.anl.gov
Cc: ahoney@polihua.keck.hawaii.edu
Date: Mon, 15 Jul 2002 10:54:03 -1000 (HST)
Aloha

I am finally getting around to modifications of drvAscii. 

One change is to allow one to specify the octal and hexidecimal escape
sequences so that one can embed non-ASCII bytes into prompts and
respones (to/fro remotely connected devices). This is to allow use 
of drvAscii with devices that use some for of a minimal protocol.

My intent is to parse the sequences as standard C formats. My concern
is that some site(s) may currently use a device which uses those 
sequences in it's command stream.  With the modifications it will 
require that those sequences be modified with an additional '\'. 
That is, if a device currently has commands of the form '\034' or
'\x469' or '\789' then those commands, within drvAscii record parm
field specifications, would need to have a '\' prepended.

Will this be a problem for anyone? If so please speak up.



Other modifications will be: 
	- to fix minor bugs that people have discovered over the years; 
	
	- (hopefully) correct the "%c" prompt behavior which is
	  not currently what one would expect (sprintf into "%c"
	  is done via a char pointer, which is incorrect)
	  
	- provide a way to allow analog rval processing to be 
	  bypassed on a record-by-record or link-specific basis (note 
	  that one must currently use the 'slope' record to affect all 
	  analog values on a given link); 
	  
	- allow "%e" format strings; 
	  
	- correct for loss of synchronization which may occur if a 
	  response is lost or mangled (i.e. attempt to resynch auto-
	  matically for the flurries of 'semTake failed' messages that 
	  occur during miscomms); 
	  
	- allow one to specify an input and/or output framing routine 
	  which can handle more complex protocols or checksums. 

In regards to the user-defined framing routines, be aware that drvAscii
still inherently uses sprintf and sscanf so the streams that the 
drvAscii functions process must not have embedded NUL characters, or 
whitespace other than as expected per the parm field specifications.

All modifications, other than the '\' escape sequence handling described
above, will not affect existing drvAscii database records that use the
current baseline driver as taken from the Keck ftp site.

If anyone has any other potential mods please yell back.

Allan


Navigate by Date:
Prev: RE: Cross compiler source and patch file for gcc-2.7.2 on Linux dht
Next: making sense of peculiar ifShow report Matthieu Bec
Index: 1994  1995  1996  1997  1998  1999  2000  2001  <20022003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017 
Navigate by Thread:
Prev: epics 3.14.0Base1 build problem Peter Kurpis
Next: drvAscii Allan Honey
Index: 1994  1995  1996  1997  1998  1999  2000  2001  <20022003  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 ·