g+
g+ Communities
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  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014 
<== Date ==> <== Thread ==>

Subject: Re: XOFF Problem with tyGSOctal
From: "Bjorklund, Eric A" <bjorklund@lanl.gov>
To: EPICS tech-talk <tech-talk@aps.anl.gov>
Date: Thu, 28 Jun 2012 00:19:34 +0000
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.



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

Navigate by Date:
Prev: EPICS Collaboration Meeting Fall 2012, First Announcement 이은희
Next: epicsAtExit Szalata, Zenon M.
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014 
Navigate by Thread:
Prev: Re: XOFF Problem with tyGSOctal Eric Norum
Next: Re: XOFF Problem with tyGSOctal Eric Norum
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014 
ANJ, 18 Nov 2013 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· EPICSv4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·