Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019 
<== Date ==> <== Thread ==>

Subject: Re: XOFF Problem with tyGSOctal
From: Dirk Zimoch <dirk.zimoch@psi.ch>
To: "Bjorklund, Eric A" <bjorklund@lanl.gov>, EPICS <tech-talk@aps.anl.gov>
Date: Thu, 28 Jun 2012 13:44:17 +0200
Hi Eric,

Maybe the implementation of tyGSOctalStartup() is wrong?

I can see in the implementation of tyITx() that it fails if the device had received an XOFF before. It fails too if there are no more bytes to write in the output buffer. A failure simply says: no bytes to output.

This can be used in the interrupt handler. The "ready to transmit next byte" interrupt calls tyITx() to get the next byte to output. If it returns ERROR, it should disable this interrupt until the next time the driver dependent txStartup function is called. Thus when there is nothing to output (buffer empty or XOFF), tyITx() should not be called again.

The txStartup function is called by tyTxStartup (from the generic ty driver framework), which is called whenever transmission should be enabled. That is at initialization, when the application wants to write, when a byte is received and echo is enabled, and when flow control says "continue sending", e.g. XOFF.

The implementation of the serial device I have (TIP866) enables interrupts in that case in its txStartup function, eventually gets the "ready to transmit" interrupt, polls tyITx() for the next byte, receives an error (and stays silent), and finally disables the interrupt again.

vxWorks should probably optimize this by not calling txStartup as long as XOFF is active. This would save some wasted interrupt time. But this is probably hopeless. Thus I compared your driver with the one I have.

It seems that tyGSOctalStartup wants to fix this performance issue by checking for available output first before enabling interrupts. Without access to the internals of the generic ty driver framework, calling tyITx() seems the only way to do the check. But tyITx removes a bytes from the output buffer on success. Thus it must do what is normally done in the interrupt handler: put the byte into the transmit register. However ERROR return of tyITx() is completely legal and is handled correctly (i.e. do nothing). I do not see any good reason for the error message.

Thus my advise is: simply remove the logMsg call from tyGSOctalStartup.

Best regards,
Dirk



Bjorklund, Eric A wrote:
Hi Dirk & Eric,

Thanks for your replies.  Sorry it has take so long to get back to you.

(Original Post) Bjorklund, Eric A wrote:
For the first time in our experience, we have a serial device (Kepco power supply) that insists on sending XOFF/XON sequences.  We are using streamDevice and a Greenspring Octal IP module to talk to it.  StreamDevice and Asyn appear to have no problems with the XOFF/XON characters, however the tyGSOctalStartup routine in tyGSOctal.c puts out a continuous stream of
"tyITX ERROR, sr=0c" errors.  The cause of these errors turns out to be
that the tyITx() routine (a vxWorks function) returns ERROR if it is called to start a transmission and the transmitter is XOFF'd.
This causes the tyGSOctalStartup routine to log an error -- perhaps because it thinks someone is trying to send a zero-length buffer (no characters left to transmit is the other reason tyITx() will return ERROR).
The easiest way to fix the problem was just to remove the error message (see attached patch file -- which only comments out the offending code in case that turns out to be a bad idea).  As far as we can tell, there are no ill effects from this.  We seem to be talking to the power supply just fine.
Anybody see a reason why we should leave the error report in tyGSOctalStartup() ?




On Jun 25, 2012, at 7:07 AM, Dirk Zimoch wrote:
XON/XOFF should be resolved on a lower level than StreamDevice and even asyn. In asyn versions >= 4.17 you can control XOFF/XON behavior on the OS driver level:

asynSetOption ("port", 0, "ixon", "Y")

Now, the device should not forward XON to asyn/StreamDevice but instead block the write function until the device is free again (I hope).

Dirk

I agree that XON/XOFF should be resolved on a lower level than StreamDevice and Asyn.  The routines I was writing about (tyGSOctalStartup() and tyITx()) are indeed OS-level routines (the later being an interrupt-level routine).  We are using asynSetOption ("port", 0, "ixon", "Y"), and in fact, the empirical evidence so far seems to indicate that everything from StreamDevice to Asyn to the the OS driver is working perfectly -- except for the constant barrage of error messages whenever tyITx() returns ERROR to tyGSOctalStartup() because transmission is XOFF'd.

So, the point of the post is to inquire of all the tyGSOctal gurus out there (if there be any left):
1.  Can we get rid of that error message in tyGSOctalStartup() ?
2.  Is there something I'm missing about XON/XOFF handling in tyGSOctal that will bite me later?



On Jun 25, 2012, at 9:20 AM, Eric Norum wrote:
While ASYN/termios does support it, XOFF/XON is a notoriously unreliable flow control mechanism.
Is there really no way to disable this behaviour from the power supply?   Could you run at a slower serial line speed and avoid the handshaking?

Agreed.  In fact, I strongly suspect that the reason no one else has reported this problem is because most people have avoided using XON/XOFF in their protocol.

Looking through the manual, however, our options seem to be:

a) XON/XOFF
b) Wait for a prompt from the device before sending data (kind of like XON/XOFF, but without the XOFF)
c) Let the device echo back each character to the sender and restart the command if there was an error.

Option a) certainly seemed to be the lesser of three evils.

-Eric Bj.



References:
XOFF Problem with tyGSOctal Bjorklund, Eric A
Re: XOFF Problem with tyGSOctal Dirk Zimoch

Navigate by Date:
Prev: Re: LabVIEW EPICS connection Steve Kinder
Next: Re: LabVIEW EPICS connection Paul Sichta
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019 
Navigate by Thread:
Prev: Re: XOFF Problem with tyGSOctal Eric Norum
Next: epics.nsls2.bnl.gov down Michael Davidsaver
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019 
ANJ, 18 Nov 2013 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·