Experimental Physics and Industrial Control System
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
<2012>
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- 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
<2012>
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024