Experimental Physics and Industrial Control System
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
<2002>
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- 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
<2002>
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024