EPICS Controls 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  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  <20022003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: drvAscii - termintor strategy
From: Eric Williams <[email protected]>
To: [email protected]
Date: Fri, 19 Apr 2002 13:54:06 -0700
One possible approach might be to extend the drvAscii %k facility for killing characters, so that the response string could throw away all the carriage returns and just key off of the linefeed to find the end of the line.

I also thought of switching to a regexp parser for the PARM string, but the overhead is probably too high.
--
Eric Williams
Controls Group
Advanced Light Source
Lawrence Berkeley Lab


At 09:14 AM 4/18/2002 -1000, Ian A Smith wrote:
Hi,

we are having problems with the strategy used by drvAscii to find line
terminators.  We are considering changing it locally to solve our particular
problem and wonder if this would impact anybody else if the change were
propagated.

Our particular problem involves a compumotor 6000 controller. Most of the time
it terminates strings with CR LF as requested but for some reason it sometimes
issues CR CR LF. This completely bamboozles drvAscii which has been told to
expect CR LF.


The termination detection of drvAscii resets the string pointer of the prototype
termination string back to zero if it encounters 2nd or 3rd characters that are
not of the expected sequence. I.e. (the spaces aren't real, just for clarity):


prototype string terminator: CR LF

received string:                                    *      T    P   E     5
CR CR LF /0
prototype string terminator pointer:       0     0    0    0     0    0    1
0   1
next expected terminator character       CR CR CR CR CR CR LF CR LF

drvAscii then times out and the string is lost.

The solution seems to be to not reset the terminator string pointer:

prototype string terminator: CR LF

received string:                                    *      T    P   E     5
CR CR LF /0
prototype string terminator pointer:       0     0    0    0     0    0    1
1
next expected terminator character       CR CR CR CR CR CR LF LF

Assuming the extra CR still in the string doesn't cause the subsequent scanf in
drvAscii problems, then the received string should be returned to epics (we
haven't tried it yet).


Hope the examples are clearer than mud!

So, can anyone see any problems with this proposed change, or, a better solution

cheers
--
Ian A Smith     Telephone: (808) 961 3756
Joint Astronomy Centre    Fax:       (808) 961 6516
660 N. A'ohoku Place        (808) 969 6591
University Park     Web: http://www.jach.hawaii.edu
Hilo
Hawaii
96720


Replies:
Re: drvAscii - termintor strategy Peregrine M. McGehee
References:
Re: CA "connection lost" messages Brian McAllister
Help about epics Monitor using CORBA guobao shen
drvAscii - termintor strategy Ian A Smith

Navigate by Date:
Prev: RE: drvAscii - terminator strategy Allan Honey
Next: Re: drvAscii - termintor strategy Peregrine M. McGehee
Index: 1994  1995  1996  1997  1998  1999  2000  2001  <20022003  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: Re: drvAscii - termintor strategy Peregrine M. McGehee
Next: Re: drvAscii - termintor strategy Peregrine M. McGehee
Index: 1994  1995  1996  1997  1998  1999  2000  2001  <20022003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 10 Aug 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·