I can only verify that I have the same/similar problem, but communicating
with Adam I/O system. And according to its spec, it never sends BREAK, but
the receiver will die within 1-10 hours...
My workaround is exactly as yours. close and open the port again, if I get a
Receive Timeout.
For awhile I was suspecting that another program was opening the port,
because if I did;
cat /dev/ttyS0
it would behave in the same manner. However, I never manage to locate any
references to the /dev/ttyS0, so I dropped this suspicioun. Could it possibly
be some Plug'n'Play daemon or something?
Niclas
Gerald Emig wrote:
> Hello,
>
> Perhaps someone knows more about the following problem and can
> give me some hints:
>
> My application implements a connection to several Simatic S5
> plcs over their programming device interface. This works with a
> 20mA TTY Interface, so I use a RS232 to 20mA converter.
>
> The program runs very good under SuSE-Linux 5.3, Kernel 2.0.35.
> The I ported it to SuSE-Linux 6.3, Kernel 2.2.10.
>
> Now on the new system:
> Under normal circumstances the program works very well. But at a
> high system load it stops; sending a request to the plc
> and waiting for the reply leads to a timeout.
> With a serial analyzer I can see both the request from the linux
> box and the reply from the plc, so the data from plc disappear
> in the serial receiver of the linux box...
>
> I have of course checked my computer's hardware in respect of
> interrupt lines and so on; the behaviour is the same if I remove
> all unnecessary cards from my PC. It even occurs on all my 3 PC
> when I boot SuSE 6.2...
>
> I have found the following:
> The lost of input data (the locking of the receiver) always
> occurs after the plc sent a BREAK to the PC. After this the
> receiver is dead!
>
> Background: the plc interface protocol has rather strong timing
> conditions; each data block you receive from plc you must
> acknowledge "at once"; if not the plc complains and sends a
> BREAK.
> With a medium system load linux is fast enough to send ACK, but
> on higher loads (e.g. extract a very big tgz-file) it doesn't.
> So the program schould repeat the request sometimes later, but
> this fails because the receiver is locked.
>
>
> My (so I think poor) WORKAROUND is the following:
> When I have send a STX to start communication I observe the port
> for incoming data within 2 seconds. If there are data, good.
> IF NOT I suppose the receiver is locked and
> do:
> close the port
> open the port
> The next try to start communication then always succeeds.
>
> Is there anyone who already had this problem ? Is there any way
> to avoid the locking of the receiver without reopen the port and
> without changing the "linux/drivers/char/serial.c" which I
> suppose causes the problem ?
>
-
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to [EMAIL PROTECTED]
