Experimental Physics and
Industrial Control System

Would it make sense to add a selectable, programmable layer between drvAscii and drvSerial, i.e. drvTerminator to handle this terminator problem, drvModbus, drvBisynch, etc. 

If this driver processes the input/output from/to drvSerial and could be specified independently for each serial connection in drvAscii, it would give a solution to this problem that would allow for added capability and have no impact on other users. 

I have been thinking along these lines to handle a eurotherm 900 controller which uses a Bisynch protocol which has a checksum as part of the terminator, but haven't wanted to hack drvAscii and loose compatibility and I seem to have no shortage of projects to keep me busy.

Rodney Porter
IPNS, Bldg. 360, Rm. C-209
Argonne National Laboratory
9700 South Cass Avenue
Argonne, IL  60439 

-----Original Message-----
From: Ian A Smith [mailto:[email protected]]
Sent: Thursday, April 18, 2002 2:15 PM
To: [email protected]
Subject: drvAscii - termintor strategy

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

Navigate by Date:

Prev: Re: strange behaviour of dbLoadtemplate Luedeke Andreas WSLA/209

Next: RE: drvAscii - terminator strategy 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 

Navigate by Thread:

Prev: Re: drvAscii - termintor strategy Peregrine M. McGehee

Next: RE: drvAscii - terminator strategy 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