Experimental Physics and
Industrial Control System

Allan Honey <[email protected]> · Fri, 19 Apr 2002 08:54:33 -1000 (HST)

Note that Ian Smith uncovered a bug in the handling of the read command
terminator. He and Nick Rees have a proposed solution.

However, Rodney does present a case for more flexible input parsing.
What he desires to do is outside of the original intent of drvAscii,
albeit, I agree that modifications to handle his needs would be useful.

Thinking out loud here:

Perhaps drvAscii should be modified so that one can pass an application
specific input parser. This would need some thought as it may be a different 
routine for each link that is opened. 

The input parser that is passed to drvSerial is getFrame(). This is done 
within drvAsciiOpenLink(), which in turn calls drvSerialCreateLink(). 

One method would be to create another 'special' record (analogous 
to connect, slope, writeCmt, timeout, readCmt) whose drvAscii write
routine could lookup the specified input parser (ascii string in the
record's PARM field) in the symbol table and then call drvSerialCreateLink().
However, there is no current mechanism, within drvSerial, for changing 
an input parser, once it has been set. Both drvSerialLinkClose() and
drvSerialLinkOpen() are local functions, so a new drvSerial function would
be needed. Be aware that changing the input parser on-the-fly would affect 
any current input stream.

With Rodney's proposed layer between drvAscii and drvSerial, one would
need to associate serial links with input parsers, prior to iocInit, and
then change the drvAscii call from drvSerialCreateLink() to a new function.
This new function would find the correct parser and then call 
drvSerialCreateLink(). This may be less invassive then my 'special' record.

AH

> From [email protected] Fri Apr 19 05:56:22 2002
> From: "Porter, Rodney" <[email protected]>
> 
> 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
> 

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System