I am using a Rocketport 16 card. One of the devices connected is an RS422
multidrop line. The connection is via RS232-RS422 converter. We use RTS to
enable and disable the transmitter in the converter, so that we don’t drag
down the line when it isn’t our turn to transmit.
There is a very puzzling problem: if I telnet into a PC, there is a good
chance that the RTS control will stop working when the telnet session is
terminated. The software continues to try to turn RTS off and on, but it
stops having any effect; RTS just stays on. Needless to say, this screws up
the multidrop line. Not being able to use telnet is a royal pain in the
neck.
I have checked interrupts and I/O allocations, and there seem to be no
conflicts. We are using TCP/IP at the socket API level with no trouble;
telnet seems to be the only application that gives us any trouble.
It baffles me as to how telnet could have this effect, since it and the
Rocketport driver seem to share nothing. However, it occurred to me that
telnet might use pty’s, and the Rocketport driver talks to Dev, so Dev might
be a common failure point.
We are using QNX 4.24. I am wondering if upgrading to the newest version of
Dev, Dev.pty, or both might fix the problem. I plan on giving it a try, but
any comments or suggestions would be appreciated.
When you say you telnet into the PC, are you implying that you telnet in and
then do things to the serial port? Or you telnet in over the serial port
(i.e. using PPP)?
Note that some programs change the settings for the port, and although
programs should restore the port when finished, some may not. Use something
like “stty < /dev/ser1” before, during, and after running your tests to see
if the settings for the port have been modified.
-Paul
Kevin Miller <kevin.miller@transcore.com> wrote in message
news:8qu11a$1t4$1@inn.qnx.com…
I am using a Rocketport 16 card. One of the devices connected is an RS422
multidrop line. The connection is via RS232-RS422 converter. We use RTS to
enable and disable the transmitter in the converter, so that we don’t drag
down the line when it isn’t our turn to transmit.
There is a very puzzling problem: if I telnet into a PC, there is a good
chance that the RTS control will stop working when the telnet session is
terminated. The software continues to try to turn RTS off and on, but it
stops having any effect; RTS just stays on. Needless to say, this screws
up
the multidrop line. Not being able to use telnet is a royal pain in the
neck.
I have checked interrupts and I/O allocations, and there seem to be no
conflicts. We are using TCP/IP at the socket API level with no trouble;
telnet seems to be the only application that gives us any trouble.
It baffles me as to how telnet could have this effect, since it and the
Rocketport driver seem to share nothing. However, it occurred to me that
telnet might use pty’s, and the Rocketport driver talks to Dev, so Dev
might
be a common failure point.
We are using QNX 4.24. I am wondering if upgrading to the newest version
of
Dev, Dev.pty, or both might fix the problem. I plan on giving it a try,
but
any comments or suggestions would be appreciated.
No, if I use the TCP/IP telnet client. I have actually reduced the RTS
program to a simple loop. It just uses ioctl to turn RTS off and on, and
sleeps for 1 second in between. I can start this running, then telnet in
from another box, and then terminate the telnet session. About half the
time, RTS gets stuck on, as evidenced by a breakout box. The ioctl program
continues to run, happily unaware that it isn’t doing anything anymore.
“Paul Russell” <paul@jenosys.com> wrote in message
news:8r31fb$os1$1@inn.qnx.com…
When you say you telnet into the PC, are you implying that you telnet in
and
then do things to the serial port? Or you telnet in over the serial port
(i.e. using PPP)?
Note that some programs change the settings for the port, and although
programs should restore the port when finished, some may not. Use
something
like “stty < /dev/ser1” before, during, and after running your tests to
see
if the settings for the port have been modified.
-Paul
Kevin Miller <> kevin.miller@transcore.com> > wrote in message
news:8qu11a$1t4$> 1@inn.qnx.com> …
I am using a Rocketport 16 card. One of the devices connected is an
RS422
multidrop line. The connection is via RS232-RS422 converter. We use RTS
to
enable and disable the transmitter in the converter, so that we don’t
drag
down the line when it isn’t our turn to transmit.
There is a very puzzling problem: if I telnet into a PC, there is a good
chance that the RTS control will stop working when the telnet session is
terminated. The software continues to try to turn RTS off and on, but it
stops having any effect; RTS just stays on. Needless to say, this screws
up
the multidrop line. Not being able to use telnet is a royal pain in the
neck.
I have checked interrupts and I/O allocations, and there seem to be no
conflicts. We are using TCP/IP at the socket API level with no trouble;
telnet seems to be the only application that gives us any trouble.
It baffles me as to how telnet could have this effect, since it and the
Rocketport driver seem to share nothing. However, it occurred to me that
telnet might use pty’s, and the Rocketport driver talks to Dev, so Dev
might
be a common failure point.
We are using QNX 4.24. I am wondering if upgrading to the newest version
of
Dev, Dev.pty, or both might fix the problem. I plan on giving it a try,
but
any comments or suggestions would be appreciated.