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: Eric Norum <eric@norum.ca>
To: "Bjorklund, Eric A" <bjorklund@lanl.gov>
Cc: EPICS tech-talk <tech-talk@aps.anl.gov>
Date: Mon, 25 Jun 2012 08:20:19 -0700
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?

On Jun 25, 2012, at 6:07 AM, Dirk Zimoch wrote:

> 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() ?
>> Thanks,
>> -Eric Bj
> 
> Eric,
> 
> 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
> 
> 

-- 
Eric Norum
eric@norum.ca






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

Navigate by Date:
Prev: RE: Large waveform PV through CA Gateway Chen, Xihui
Next: FW: Large waveform PV through CA Gateway Hill, Jeff
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 Dirk Zimoch
Next: Re: XOFF Problem with tyGSOctal Bjorklund, Eric A
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 ·