FUDforum
My FUDforum

Home »  » DeviceMaster » Devicemaster nslink loses characters held by RTS/CTS flow control
Devicemaster nslink loses characters held by RTS/CTS flow control [message #1085] Tue, 20 November 2018 14:17 Go to next message
severach is currently offline  severach
Messages: 14
Registered: December 2016
Location: Michigan
Member
I have an Aten SXP325A parallel to serial converter hooked to a DeviceMaster. The converter is set to hold and buffer characters on RTS low and transmit on RTS high. When I connect to /dev/ttySI, RTS is brought high before the tty is connected to the network port and some characters are lost. See
Test 4 below.

No characters are lost with the converter connected to a USB or onboard serial port or TCP connections to the DeviceMaster. Onboard ports must have RTS/CTS enabled or all characters are lost or mangled.

The Aten SXP325A appears to have a bug where the first character of any print job is changed to ^H or ^L. This looks like a lost character on the screen. It is visible in capture logs.

DeviceMaster RTS 1 port, Bootloader v4.31, SocketServer v11.30

SXP325A is compatible with USB Parallel cable Belkin F5U002 050d:0002
cp testfile.txt /dev/usb/lp0

***

DeviceMaster as TCP Server, connect with telnet or PuTTY and pull data:
Port #:
Baud Rate: 115,200
Flow Control: RTS/CTS
DTR Mode: socketon
RTS Mode: off
TCP Connection Enabled: [x]
Listen: [x]
Network Configuration:
Boot Timeout: 5s

Test 1: No characters are lost when a print job is sent while connected.
Test 2: No characters are lost when a print job is sent to the buffer then connect to get it. DeviceMaster buffers or delays the print output until the socket is open and ready to transmit.

***

DeviceMaster as NSLink server, connect with minicom and pull data:
Port #:
Baud Rate: 115,200
Flow Control: RTS/CTS
DTR Mode: socketon
RTS Mode: off
TCP Connection Enabled: [ ]

minicom -b 115200 -D /dev/ttySI1

Test 3: No characters are lost when a print job is sent while connected.
Test 4: Up to 100 characters are lost when a print job is sent to the buffer then connect to get it. About half the time no characters are lost.

Let's see if RTS/CTS must be set on the port like /dev/ttyS0.

stty -F /dev/ttySI1 9600 crtscts
With the baud set to 9600 characters are mangled and lost.
stty -F /dev/ttySI1 115200 crtscts
With the baud set to 115200, characters are lost. No characters are mangled.

***

DeviceMaster as client, print to xinetd JetDirect compatible network socket
Port #:
Baud Rate: 115,200
Flow Control: RTS/CTS
DTR Mode: on
RTS Mode: off
TCP Connection Enabled: [x]
Listen: [ ]
Connect to IP Address: ...
Target Port: 9100
Connect: [ ] Always
Connect: [x] Data
Disconnect: [x] Idle
Idle Timeout: 10s

Test 5: No characters are lost. DeviceMaster buffers or delays the print output until the socket is open and ready to transmit.

***

Aten SXP325A connected to /dev/ttyS0, connect with minicom and pull data:
stty -F /dev/ttyS0 9600 crtscts # the baud rate is set wrong to show that RTS/CTS delays the data until the baud rate is set by minicom
minicom -b 115200 -D /dev/ttyS0

Test 6: No characters are lost when a print job is sent while connected.
Test 7: No characters are lost when a print job is sent to the buffer then connect to get it.
Re: Devicemaster nslink loses characters held by RTS/CTS flow control [message #1086 is a reply to message #1085] Tue, 20 November 2018 15:07 Go to previous messageGo to next message
Matt is currently offline  Matt
Messages: 18
Registered: November 2018
Location: Minnesota
Member
Hi,

My colleagues and I have been discussing this and we have one possibility to try, but also some clarifying questions.

One idea, kind of a "shot in the dark" but worth seeing what happens, is to test whether the behavior is any different when setting the low_latency flag for /dev/ttySI. To do this you'll need the setserial command installed on your system.

To set the low_latency flag:
setserial /dev/ttySI low_latency


Setting this may increase CPU usage and can sometimes decrease throughput, so if this does not help, you'll want to clear the flag after testing:
setserial /dev/ttySI ^low_latency


I'm not super confident that the latency flag is the cause of this behavior, though. Can you help illustrate the way everything is connected in a bit more detail? I'm assuming that the communication chain, in the situation where you're seeing the issue, goes something like this:

Application --> /dev/ttySI -> NSLink driver -> network -> DeviceMaster RTS -> DB9 serial port -> Aten SXP325A converter -> parallel port -> printer

What makes me wonder if I'm missing something is that, if that's how things are hooked up, I'd expect characters to be lost if RTS is brought high too *late*, rather than too *soon*. Is that correct, or am I misunderstanding?

Also, if you haven't already tried it, it might be revealing to telnet to the DeviceMaster and use the monitor command to observe whether there's anything different shown there vs. in minicom, while running that test #4. (i.e. dm> monitor -ac 1)

Thanks for any additional info -

Matt


Matt Mayfield
www.comtrol.com

Comtrol Corporation
100 Fifth Avenue NW
New Brighton, MN 55112
(763) 957-6000
Re: Devicemaster nslink loses characters held by RTS/CTS flow control [message #1087 is a reply to message #1086] Tue, 20 November 2018 20:39 Go to previous messageGo to next message
severach is currently offline  severach
Messages: 14
Registered: December 2016
Location: Michigan
Member
Low latency doesn't seem to have any effect though tonight I'm losing 300-400 characters every time, low latency on or off. The monitor shows the same characters seen in minicom.

The original configuration is:

Machine -> parallel printer

I want to capture the print data.

Machine -> parallel port -> ??? -> network -> ??? -> printer

To get to the network we add a parallel to serial converter and a serial to network converter.

Machine -> parallel port -> Aten P to S -> DeviceMaster -> network

To maximize availability and speed I picked the Aten SXP325A which runs at 115,200 baud and has a buffer inside.

For testing a computer with a parallel port is printing.

Turns out the Belkin USB Parallel F5U002 Linux driver is mangling the first character. The Belkin F5U002 prints fine in Windows. For Linux I changed to an onboard parallel port and the first character is no longer mangled.
Re: Devicemaster nslink loses characters held by RTS/CTS flow control [message #1093 is a reply to message #1087] Tue, 27 November 2018 09:13 Go to previous messageGo to next message
Matt is currently offline  Matt
Messages: 18
Registered: November 2018
Location: Minnesota
Member
Hi Severach,

OK, thanks for the clarification. So it sounds like the first-character ^H/^L mangling is a separate issue with the Belkin USB->Parallel device, so we can set that piece aside for now and concentrate on the dropping of characters you're seeing. That part is still a bit of a puzzle. I'm working with some of the folks on the hardware team and the rest of the Tech Support team to see if there are some more ideas for this situation.

In the meantime, I have one other thought. I'm looking specifically at your Test 3/4 vs. Test 6/7; am I understanding these situations correctly?

Test 3/4:
Data is sent from the computer's built-in parallel port, through the Aten P->S converter, through a null modem cable into the DeviceMaster. Minicom is monitoring the data coming into the serial port on the DM, via the NSLink driver configured so that the DM appears on /dev/ttySI1. Data loss is observed intermittently, only at the very beginning after opening the port.

Test 6/7:
Data is sent from the computer's built-in parallel port, through the Aten P->S converter, through a null modem cable into the computer's built-in serial port. Minicom is monitoring the data coming into the build-in serial port via the standard /dev/ttyS0. No data loss is observed.

Is this the same null modem cable in both configurations - that is, could it be possible that one null modem cable is linking RTS of one side into CTS of the other, and the other cable is looping back RTS/CTS on each side?

Thanks,

Matt


Matt Mayfield
www.comtrol.com

Comtrol Corporation
100 Fifth Avenue NW
New Brighton, MN 55112
(763) 957-6000
Re: Devicemaster nslink loses characters held by RTS/CTS flow control [message #1095 is a reply to message #1093] Thu, 29 November 2018 04:42 Go to previous messageGo to next message
severach is currently offline  severach
Messages: 14
Registered: December 2016
Location: Michigan
Member
The serial cable between the Aten and the computer or Devicemaster is a DB25M to DB9F straight cable. The DeviceMaster DB9 and computer DB9 have the same pinout so the same cable is used. If RTS were tied to CTS I would expect all characters would be lost.

I have so many test devices that I use a VSCom USB 16 port Serial Adapter FTDI FT4232H to bring them all in. Test 6/7 run on the USB Serial doesn't lose any data either. While I haven't tested them I would expect the RocketPort USB, PCI, and PCIe cards to all not drop characters.

This can be tested with a computer, no Aten P->S needed. Due to much brokenness we'll need to use several tools.

Broke: minicom, PuTTY, and `cat > /dev/tty` silently discard pasted typed cat characters when blocked by CTS.
Broke: minicom drops DTR but not CTS on exit
Broke: PuTTY drop neither DTR nor CTS on exit
Broke: minicom and PuTTY do not show the status of CTS DSR or allow control of RTS DTR
Broke: switch -d crashes lcom
Broke: lcom -fw hw blocks the action of Esc-R RTS. Screen shows the state change but it doesn't.

>Create Testfile, 8 lines, 100 characters per line, including CRLF
Line 1-------^M^J
Line 2-------^M^J
...
>Configure DeviceMaster for Test 3/4
>Connect DeviceMaster to onboard serial /dev/ttyS0, null modem cable
stty -F /dev/ttyS0 115200 crtscts
stty -F /dev/ttySI1 115200 crtscts
lcom -f none -b 115200 /dev/ttyS0
lcom -f none -b 115200 /dev/ttySI1
>lcom-SI1: Esc-R
>> lcom always sets RTS high to start. Observe cts go low in lcom-S0
>lcom-SI1: quit
>lcom-S0: quit

minicom -b 115200 -D /dev/ttyS0
repeat
lcom -f none -b 115200 /dev/ttySI1
>lcom-SI1: Esc-R
>> S0-cts is now set low

>minicom-S0: ^A S ascii Testfile
>> Send screen should be frozen by CTS low
minicom -b 115200 -D /dev/ttySI1
>> Observe data loss as expected.
>minicom-SI1: quit
until tired;
Re: Devicemaster nslink loses characters held by RTS/CTS flow control [message #1096 is a reply to message #1095] Thu, 29 November 2018 10:45 Go to previous messageGo to next message
Matt is currently offline  Matt
Messages: 18
Registered: November 2018
Location: Minnesota
Member
Hi Chris,

I've been trying to reproduce the issue on a Linux system with a DeviceMaster and COM1/ttyS0, but so far haven't found the same results. So I've created a Tech Support case for this issue (29924) and am working on getting some input from our hardware engineers and software developers. If possible, would you please email me (using the Email button below my post here) so we can continue diving into this in detail?

Thanks,

Matt


Matt Mayfield
www.comtrol.com

Comtrol Corporation
100 Fifth Avenue NW
New Brighton, MN 55112
(763) 957-6000
Re: Devicemaster nslink loses characters held by RTS/CTS flow control [message #1099 is a reply to message #1096] Tue, 04 December 2018 10:23 Go to previous message
Matt is currently offline  Matt
Messages: 18
Registered: November 2018
Location: Minnesota
Member
Hi again Chris,

Some of our engineers have done analysis on this situation and were able to replicate what you found. Here's that analysis.

-----
If you examine the sequence of system calls used by minicom, you'll see the following:
     1  openat(AT_FDCWD, "/dev/ttySI0", O_RDWR|O_NOCTTY|O_NONBLOCK) = 3</dev/ttySI0>
     2  fcntl(3</dev/ttySI0>, F_GETFL)  = 0x8802 (flags O_RDWR|O_NONBLOCK|O_LARGEFILE)
     3  fcntl(3</dev/ttySI0>, F_SETFL, O_RDWR|O_LARGEFILE) = 0
     4  ioctl(3</dev/ttySI0>, TCGETS, {c_iflags=0x500, c_oflags=0x5, c_cflags=0xcbd, ...
     5  ioctl(3</dev/ttySI0>, TIOCMGET, [TIOCM_DTR|TIOCM_RTS|TIOCM_CTS|TIOCM_CAR|TIOCM_DSR]) = 0
     6  ioctl(3</dev/ttySI0>, TCGETS, {c_iflags=0x500, c_oflags=0x5, c_cflags=0xcbd, ...
     7  ioctl(3</dev/ttySI0>, SNDCTL_TMR_START or TCSETS, {c_iflags=0x1, c_oflags=0, ....
     8  ioctl(3</dev/ttySI0>, TIOCMGET, [TIOCM_DTR|TIOCM_RTS|TIOCM_CTS|TIOCM_CAR|TIOCM_DSR]) = 0
     9  ioctl(3</dev/ttySI0>, TIOCMSET, [TIOCM_DTR|TIOCM_RTS|TIOCM_CTS|TIOCM_CAR|TIOCM_DSR]) = 0
    10  ioctl(3</dev/ttySI0>, TCGETS, {c_iflags=0x1, c_oflags=0, c_cflags=0x1cb2, ...
    11  ioctl(3</dev/ttySI0>, SNDCTL_TMR_START or TCSETS, {c_iflags=0x1, c_oflags=0, ...
    12  ioctl(3</dev/ttySI0>, TCGETS, {c_iflags=0x1, c_oflags=0, c_cflags=0x80001cb2, ...
    13  ioctl(3</dev/ttySI0>, SNDCTL_TMR_START or TCSETS, {c_iflags=0x1, c_oflags=0, ...
    14  ioctl(3</dev/ttySI0>, TCGETS, {c_iflags=0x1, c_oflags=0, c_cflags=0x80001cb2, ...
    15  ioctl(3</dev/ttySI0>, SNDCTL_TMR_START or TCSETS, {c_iflags=0x1, c_oflags=0, ...
    16  ioctl(3</dev/ttySI0>, TCFLSH, TCIOFLUSH) = 0
    17  stat("/dev/ttySI0", {st_dev=makedev(0, 6), st_ino=9928, st_mode=S_IFCHR|0660, ...
    18  ioctl(3</dev/ttySI0>, TIOCMGET, [TIOCM_DTR|TIOCM_RTS|TIOCM_CTS|TIOCM_CAR|TIOCM_DSR]) = 0
    19  ioctl(3</dev/ttySI0>, TCGETS, {c_iflags=0x1, c_oflags=0, c_cflags=0x80001cb2, ...
    20  select(4, [0</dev/pts/0> 3</dev/ttySI0>], NULL, NULL, {tv_sec=1, tv_usec=0}) = 1 ...
    21  read(3</dev/ttySI0>, "k\252\312\352\nU*\252*UU\253WXYZ[\\]^_`abcdefghij"..., 127) = 51
    ...

The port is opened at line 1. This causes RTS and DTR to go active. This is standard Unix serial port behavior and is determined by the Linux kernel's tty layer, not by the nslink driver module. The port is configured at lines 7, 11, 13, and 15, using a series of TCSETS ioctl() call. Minicom then discards all buffered data at line 16 using a TCFLSH ioctl() call. The first read happens at line 21.
If the attached device starts sending data immediealy when RTS goes active at line 1, then there are three issues:

1. Any data received before the port configuration is complete at line 15 may be garbled due to mismatch of baud, parity, or character-length.
2. Changes to baud, parity or character length that are made while data is being received can result in continued reception of garbled data until there is a gap in rx data sufficient to allow the UART to re-synchronize.
3. Any data received before the TCFLSH ioctl() call at line 16 is executed will be discarded.

If no data loss is expected, then the delay between RTS going active and the device beginning transmission must be longer than the time required by minicom to configure the port and flush buffered data.
With local UARTs, the time required to configure the port and flush buffered data is probably negligible (a few microseconds), and it's likely that no data is lost.
With network-attached UARTs (e.g. DeviceMaster), the time required to open, configure, and flush a serial port is much longer (at least several milliseconds). It can not be assumed that data sent immediately following assertion of RTS cause by port open() will be correctly received.
In order to prevent data loss, the port needs to be open and configured before data is received.
-----

Judging from the engineers' analysis above, I think that explains how your original tests turned out the way they did:

Tests 1/2: avoided the data loss because the TCP socket was already open before the data started arriving
Tests 3/4: as above, the Linux kernel dictates that RTS is always set high immediately as the port is opened, possibly before the application even gets access to the port, so data can be lost if the sending device doesn't wait long enough
Test 5: avoids data loss because using the TCP socket doesn't necessitate RTS going high right away, and/or the socket is already open and ready when RTS is brought high and data starts arriving
Tests 6/7: a locally-attached serial port is orders of magnitude faster at getting ready for data since there's no network latency, so data loss is unlikely (though not guaranteed) even though the same potential data loss issue technically exists here

I hope that's helpful. Thanks - Matt


Matt Mayfield
www.comtrol.com

Comtrol Corporation
100 Fifth Avenue NW
New Brighton, MN 55112
(763) 957-6000
Previous Topic: nslink fails when autoassigned a large major>=256
Next Topic: FAQ- How do I check if the nslink module (driver) is loaded?
Goto Forum:
  


Current Time: Sat Mar 28 18:36:38 CDT 2020

Total time taken to generate the page: 0.00751 seconds