Experimental Physics and
Industrial Control System

Allan Honey <[email protected]> · Thu, 18 Apr 2002 10:34:54 -1000 (HST)

My concern is that comms errors, where a glitch causes a character to be
mutated into a CR, will pass through without being detected. Granted the
probability is very low on this happening, but we have had very 'noisy' 
serial links in the past.

Also be aware that a waveform record can be configured for multiple
lines of data (ie. a specified number of command terminators are
expected). You should test that your modification does not adversely
affect this behavior.

Perhaps a more elaborate scheme for specifying the command terminator, 
such that a given site/device can be configured for specific anomolies,
is needed. Maybe a specification something like:

 	"\%2rn" 	(ie. upto 2 CR followed by a aingle LF) 
	"\%*r\n" 	(ie. any number of CR followed by a single LF) 
	"\%*r\%2n" 	(ie. any number of CR followed by upto 2 LF) 

could be implemented. Note in this case getFrame() having to prescan the 
command terminator to keep local information. hmmm I guess setWriteCmt() 
would not have to be changed but formatCmt() would then we let the getFrame() 
routine dynamically interpret the command terminator.

Of course the bizarre case where "\%" is a valid CMT would have to be
handled (eg. "\\%" could mean to not interpret).

AH

> From [email protected] Thu Apr 18 09:15:05 2002
> Date: Thu, 18 Apr 2002 09:14:50 -1000
.php>
> 
> 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
> 
> 
> 

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System