WC32 serial port communication with PC
- Thread starter CAI_Support
- Start date
CAI_Support
Senior Member
You can setvar, if that helps.
CAI_Support
Senior Member
The testing is down by having Windows or Linux PC install the proper driver over the TCP based RS232, then use terminal software to connect to WC32 RS232 port, Whatever connected on the WC32 RS232 port would act like connected locally on the computer virtual RS232 port. You can read and write to it same way as you do it over local RS232 port.
I use FreeBSD on my machines, and use nc (netcat).
This has however raised an interesting question and I'd like to ask everyone using the serial ports on the WC32 if you've experienced any issues with them?
I built a whole bunch of cell monitors for both my lead-acid and lithium ferrophosphate battery banks, to continuously monitor the voltage and temperature of each cell.
In the past, I did this with a Lantronix ETS8P.
Every 30 seconds, each chain sends a series of data about each cell, and the pack as a whole. There's a moderate amount of data from each transmission, and it's all at 4800 baud.
Here's a typical report - one of these comes from each bank, every 30 seconds:
20:15:03=> *V01 1.993
20:15:04=> T01 0.0
20:15:04=> V02 2.060
20:15:05=> T02 0.0
20:15:05=> V03 2.044
20:15:06=> T03 0.0
20:15:07=> A01 6.097 2.032 .100
20:15:07=> #V04 2.104
20:15:07=> T04 0.0
20:15:08=> V05 2.104
20:15:08=> T05 0.0
20:15:08=> V06 2.117
20:15:08=> T06 0.0
20:15:08=> A04 12.422 2.070 .100
20:15:09=> V07 2.019
20:15:09=> T07 0.0
20:15:09=> V08 2.080
20:15:09=> T08 0.0
20:15:09=> V09 2.034
20:15:09=> T09 0.0
20:15:10=> A07 18.555 2.061 .100
20:15:10=> V10 2.084
20:15:10=> T10 0.0
20:15:10=> V11 2.061
20:15:10=> T11 0.0
20:15:10=> V12 2.069
20:15:11=> T12 0.0
20:15:11=> A10 24.769 2.064 .100
20:15:11=> V13 2.051
20:15:11=> T13 0.0
20:15:11=> V14 2.101
20:15:12=> T14 0.0
20:15:12=> V15 2.085
20:15:12=> T15 0.0
20:15:12=> A13 31.006 2.067 .100
20:15:12=> V16 2.102
20:15:13=> T16 0.0
20:15:13=> V17 1.910
20:15:13=> T17 0.0
20:15:13=> V18 2.091
20:15:13=> T18 0.0
20:15:14=> A16 37.109 2.061 .100
20:15:14=> V19 2.075
20:15:14=> T19 30.1
20:15:14=> V20 2.071
20:15:14=> T20 29.7
20:15:14=> V21 2.098
20:15:15=> T21 29.5
20:15:15=> A19 43.353 2.064 .100
20:15:15=> V22 1.974
20:15:15=> T22 0.0
20:15:15=> V23 2.056
20:15:16=> T23 0.0
20:15:16=> V24 1.970
20:15:16=> T24 0.0
20:15:18=> Y01 49.353 24 2.056 2.156 1.956
20:15:18=> !Y04 49.353 24 2.056 2.156 1.956
20:15:19=> Y07 49.353 24 2.056 2.156 1.956
20:15:19=> Y10 49.353 24 2.056 2.156 1.956
20:15:20=> Y13 49.353 24 2.056 2.156 1.956
20:15:20=> Y16 49.353 24 2.056 2.156 1.956
20:15:20=> E17 1910 2156
20:15:21=> Y19 49.353 24 2.056 2.156 1.956
20:15:21=> @
Over the last 2 years, I've had 11 incomplete reports - probably when I've been making changes to the network, or monitoring code. That's about 1 incomplete report in every 200,000. Good enough.
Late last week, I decided to replace one of my old WC8 boards (with expansion 4-channel ADC, and a bunch of amplifiers and stuff), with a WC32 - because I've reduced my RS232 needs there down to just two channels, and can completely remove one of the terminal servers by better utilising a WC32.
Since then, I see one incomplete report every 10 minutes - regular as clockwork.
03-Apr-2016 01:32:36 Short data file! 19
03-Apr-2016 01:43:24 Short data file! 22
03-Apr-2016 01:54:12 Short data file! 22
03-Apr-2016 02:02:41 Short data file! 22
03-Apr-2016 02:05:00 Short data file! 22
03-Apr-2016 02:13:29 Short data file! 23
03-Apr-2016 02:24:17 Short data file! 23
03-Apr-2016 02:35:05 Short data file! 23
03-Apr-2016 02:07:32 Short data file! 21
03-Apr-2016 02:18:20 Short data file! 20
03-Apr-2016 02:29:09 Short data file! 20
03-Apr-2016 02:37:39 Short data file! 22
03-Apr-2016 02:39:58 Short data file! 22
03-Apr-2016 02:48:28 Short data file! 23
03-Apr-2016 02:50:47 Short data file! 23
03-Apr-2016 02:59:16 Short data file! 23
03-Apr-2016 03:01:35 Short data file! 23
There's no network connectivity loss. It's *EXACTLY* the same code that was running with the ETS8P (all I changed was the IP address the netcat connects to), and the other channel (that's still on the ETS8P) isn't missing any data... so it's definately the WC32 serial that's doing it.
Looking in the log, it appears that there is simply a break in transmission for approx 2 seconds, where nothing is received. The connection doesn't drop to the server, there is simply no data sent from the WC32. It isn't a loose wire. The DHCP logs indicate it isn't a network renegotiation, nothing else on the same switch is affected... anyone got any bright ideas? It's going to be a deal-breaker if the UART-to-TCP doesn't work reliably!
This has however raised an interesting question and I'd like to ask everyone using the serial ports on the WC32 if you've experienced any issues with them?
I built a whole bunch of cell monitors for both my lead-acid and lithium ferrophosphate battery banks, to continuously monitor the voltage and temperature of each cell.
In the past, I did this with a Lantronix ETS8P.
Every 30 seconds, each chain sends a series of data about each cell, and the pack as a whole. There's a moderate amount of data from each transmission, and it's all at 4800 baud.
Here's a typical report - one of these comes from each bank, every 30 seconds:
20:15:03=> *V01 1.993
20:15:04=> T01 0.0
20:15:04=> V02 2.060
20:15:05=> T02 0.0
20:15:05=> V03 2.044
20:15:06=> T03 0.0
20:15:07=> A01 6.097 2.032 .100
20:15:07=> #V04 2.104
20:15:07=> T04 0.0
20:15:08=> V05 2.104
20:15:08=> T05 0.0
20:15:08=> V06 2.117
20:15:08=> T06 0.0
20:15:08=> A04 12.422 2.070 .100
20:15:09=> V07 2.019
20:15:09=> T07 0.0
20:15:09=> V08 2.080
20:15:09=> T08 0.0
20:15:09=> V09 2.034
20:15:09=> T09 0.0
20:15:10=> A07 18.555 2.061 .100
20:15:10=> V10 2.084
20:15:10=> T10 0.0
20:15:10=> V11 2.061
20:15:10=> T11 0.0
20:15:10=> V12 2.069
20:15:11=> T12 0.0
20:15:11=> A10 24.769 2.064 .100
20:15:11=> V13 2.051
20:15:11=> T13 0.0
20:15:11=> V14 2.101
20:15:12=> T14 0.0
20:15:12=> V15 2.085
20:15:12=> T15 0.0
20:15:12=> A13 31.006 2.067 .100
20:15:12=> V16 2.102
20:15:13=> T16 0.0
20:15:13=> V17 1.910
20:15:13=> T17 0.0
20:15:13=> V18 2.091
20:15:13=> T18 0.0
20:15:14=> A16 37.109 2.061 .100
20:15:14=> V19 2.075
20:15:14=> T19 30.1
20:15:14=> V20 2.071
20:15:14=> T20 29.7
20:15:14=> V21 2.098
20:15:15=> T21 29.5
20:15:15=> A19 43.353 2.064 .100
20:15:15=> V22 1.974
20:15:15=> T22 0.0
20:15:15=> V23 2.056
20:15:16=> T23 0.0
20:15:16=> V24 1.970
20:15:16=> T24 0.0
20:15:18=> Y01 49.353 24 2.056 2.156 1.956
20:15:18=> !Y04 49.353 24 2.056 2.156 1.956
20:15:19=> Y07 49.353 24 2.056 2.156 1.956
20:15:19=> Y10 49.353 24 2.056 2.156 1.956
20:15:20=> Y13 49.353 24 2.056 2.156 1.956
20:15:20=> Y16 49.353 24 2.056 2.156 1.956
20:15:20=> E17 1910 2156
20:15:21=> Y19 49.353 24 2.056 2.156 1.956
20:15:21=> @
Over the last 2 years, I've had 11 incomplete reports - probably when I've been making changes to the network, or monitoring code. That's about 1 incomplete report in every 200,000. Good enough.
Late last week, I decided to replace one of my old WC8 boards (with expansion 4-channel ADC, and a bunch of amplifiers and stuff), with a WC32 - because I've reduced my RS232 needs there down to just two channels, and can completely remove one of the terminal servers by better utilising a WC32.
Since then, I see one incomplete report every 10 minutes - regular as clockwork.
03-Apr-2016 01:32:36 Short data file! 19
03-Apr-2016 01:43:24 Short data file! 22
03-Apr-2016 01:54:12 Short data file! 22
03-Apr-2016 02:02:41 Short data file! 22
03-Apr-2016 02:05:00 Short data file! 22
03-Apr-2016 02:13:29 Short data file! 23
03-Apr-2016 02:24:17 Short data file! 23
03-Apr-2016 02:35:05 Short data file! 23
03-Apr-2016 02:07:32 Short data file! 21
03-Apr-2016 02:18:20 Short data file! 20
03-Apr-2016 02:29:09 Short data file! 20
03-Apr-2016 02:37:39 Short data file! 22
03-Apr-2016 02:39:58 Short data file! 22
03-Apr-2016 02:48:28 Short data file! 23
03-Apr-2016 02:50:47 Short data file! 23
03-Apr-2016 02:59:16 Short data file! 23
03-Apr-2016 03:01:35 Short data file! 23
There's no network connectivity loss. It's *EXACTLY* the same code that was running with the ETS8P (all I changed was the IP address the netcat connects to), and the other channel (that's still on the ETS8P) isn't missing any data... so it's definately the WC32 serial that's doing it.
Looking in the log, it appears that there is simply a break in transmission for approx 2 seconds, where nothing is received. The connection doesn't drop to the server, there is simply no data sent from the WC32. It isn't a loose wire. The DHCP logs indicate it isn't a network renegotiation, nothing else on the same switch is affected... anyone got any bright ideas? It's going to be a deal-breaker if the UART-to-TCP doesn't work reliably!
CAI_Support
Senior Member
Ross,
Are you using a tty0tty on your BSD system? Did you do tcpdump to see where the problem is? Does the communication stop before reaching to the tty0tty driver?
Are you using a tty0tty on your BSD system? Did you do tcpdump to see where the problem is? Does the communication stop before reaching to the tty0tty driver?
CAI_Support said:
There's no need, netcat directly connects the socket to stdio and faithfully copies the contents of any and all packets.
I've been using it for years with other terminal servers without incident, even copying terabytes of data across the internet between SANs - without ever so much as a checksum mismatch.
CAI_Support said:
tcpdump seems to show data is just "missing"....
ok, I caught one....
Here's a section of the logged data from the file:
16:54:33=> *V01 3.342
16:54:33=> T01 28.3
16:54:33=> V02 3.345
16:54:33=> T02 28.1
16:54:34=> V03 3.396
16:54:34=> T03 27.8
16:54:36=> A0.352
16:54:36=> T08 0.0
16:54:36=> A07 26.888 3.361 .100
16:54:37=> V09 3.365
16:54:37=> T09 0.0
16:54:37=> V10 3.363
And here's the packets as monitored at the switch where the WC32 connects (timestamps in milliseconds, IP source and destination obfuscated)
16:54:28.651678 a.b.c.d w.x.y.z *.....
16:54:33.238823 a.b.c.d w.x.y.z V.....
16:54:33.288792 a.b.c.d w.x.y.z 01 3..
16:54:33.338777 a.b.c.d w.x.y.z .342..
16:54:33.388772 a.b.c.d w.x.y.z ..T...
16:54:33.488749 a.b.c.d w.x.y.z 01 2..
16:54:33.538739 a.b.c.d w.x.y.z 8.3...
16:54:33.588721 a.b.c.d w.x.y.z V.....
16:54:33.638716 a.b.c.d w.x.y.z 02 3..
16:54:33.688701 a.b.c.d w.x.y.z .345..
16:54:33.738704 a.b.c.d w.x.y.z ..T...
16:54:33.788717 a.b.c.d w.x.y.z 02 2..
16:54:33.839355 a.b.c.d w.x.y.z 8.1...
16:54:33.888907 a.b.c.d w.x.y.z V.....
16:54:33.938662 a.b.c.d w.x.y.z 03 3..
16:54:33.988649 a.b.c.d w.x.y.z .396..
16:54:34.038652 a.b.c.d w.x.y.z ..T...
16:54:34.138611 a.b.c.d w.x.y.z 03 2..
16:54:34.188605 a.b.c.d w.x.y.z 7.8...
16:54:34.238593 a.b.c.d w.x.y.z A.....
16:54:36.638141 a.b.c.d w.x.y.z 0.....
16:54:36.638287 a.b.c.d w.x.y.z .352..T08 0.0..A07 26.88
16:54:36.688125 a.b.c.d w.x.y.z 8 3...
16:54:36.738120 a.b.c.d w.x.y.z 361 ..
16:54:36.788095 a.b.c.d w.x.y.z .100..
16:54:36.838111 a.b.c.d w.x.y.z ......
16:54:36.951548 a.b.c.d w.x.y.z V0....
16:54:37.001076 a.b.c.d w.x.y.z 9 3...
16:54:37.001259 a.b.c.d w.x.y.z 365...
16:54:37.051966 a.b.c.d w.x.y.z ......
16:54:37.102051 a.b.c.d w.x.y.z T0....
16:54:37.152196 a.b.c.d w.x.y.z 9 0...
Interesting to note that the second packet back has much more data, as if chars are coming in the UART, being assembled into the ethernet frame but simply not being sent.
(I'm presuming you wait a certain number of milliseconds before sending a ethernet frame, to keep the latency low, or sending a larger frame if more bytes are received in the meantime?)
Also interestingly, I've now moved both RS232 channels to the WC32 board to see if it makes it better or worse. The fault is evident on both channels, and the approx 10 minutes interval seems to still be consistent - although at the moment it looks like the 10 minutes may not align across both channels! Like it's some 10-minute event thing per UART?
CAI_Support
Senior Member
Hi Ross,
There is a need for that. Without that emulated tty ports, you will not get the actual tty behaviors.
Please refer to
There is a need for that. Without that emulated tty ports, you will not get the actual tty behaviors.
Please refer to
Code:
http://www.cainetworks.com/products/webcontrol/wc32-tcp-bridge.pdfCAI_Support said:
Thanks, Wayne... but no, I don't actually need that. My program does not "try to" talk to a serial port, so there's no reason to emulate one just for the sake of making a serial port bridge.
The fact it operates at all, for "most" of the time, is clear evidence that the underlying infrastructure is doing what it needs to.
nc does, in all significant regards, exactly the same thing as tty0tty except that it connects the raw tcp to a stream instead of a virtual uart, which is all I need (if it was a real serial port, I would simply cat it to the same stream for my code to read anyway).
Interestingly (but a bit early to tell), I've disabled the PLC program (added a "start: goto start" at the front!), and I've now had 20 minutes without missed data.
ok, it hasn't stopped it completely, but it's reduced it....
05-Apr-2016 08:58:09 a.b.c.d:4500 Short data file! 20 (expecting 24)
05-Apr-2016 09:02:25 a.b.c.d:5000 Short data file! 11 (expecting 16)
05-Apr-2016 09:24:11 a.b.c.d:5000 Short data file! 11 (expecting 16)
05-Apr-2016 09:41:45 a.b.c.d:4500 Short data file! 20 (expecting 24)
05-Apr-2016 09:45:59 a.b.c.d:5000 Short data file! 12 (expecting 16)
So serial0 (port 4500) made 40 minutes without error, serial1 only made 20, but both are an improvement on the constant 10-minutes.
05-Apr-2016 08:58:09 a.b.c.d:4500 Short data file! 20 (expecting 24)
05-Apr-2016 09:02:25 a.b.c.d:5000 Short data file! 11 (expecting 16)
05-Apr-2016 09:24:11 a.b.c.d:5000 Short data file! 11 (expecting 16)
05-Apr-2016 09:41:45 a.b.c.d:4500 Short data file! 20 (expecting 24)
05-Apr-2016 09:45:59 a.b.c.d:5000 Short data file! 12 (expecting 16)
So serial0 (port 4500) made 40 minutes without error, serial1 only made 20, but both are an improvement on the constant 10-minutes.
CAI_Support
Senior Member
Since TCP layer had no problem, it might be able to tune the tty emulator to find out why the date wrong. Since tty0tty driver has complete source code and debug mode, it might help to find out why. tty port has different behavior from TCP port, TCP port has timeout and connection stages, tty port are not supposedly seeing them.
CAI_Support said:
The dates are not wrong, and are not sent over the serial.
The dates and times are added at the server by the code that receives the (un-timestamped) raw data from the WC32.
The gaps in the data is what is missing.
The TCP session does not drop, which makes it "look like" buffer overrun on the WC32. How big is the serial buffer?
I was wondering if "something" was blocking - waiting for an email to send, or a webset/webget to execute etc. Hence disabling the PLC code to see if it made a difference.
It seems to have made a small difference, in that both channels are frequently going 20 minutes now without dropping data.
A suggestion for a future version, perhaps...
It would be nice if the serial-to-TCP could be configured to send after
( a ) x milliseconds without a character received
and/or
( b ) a CR/LF
This would let it be much more efficient in use, send full lines where line-buffering is appropriate, but still be useful for single-character transmissions with only a modest latency for the rest of the time (eg, send buffer with CR/LF all the time, but ALSO send the buffer after a definable time - like 100ms).
It would be nice if the serial-to-TCP could be configured to send after
( a ) x milliseconds without a character received
and/or
( b ) a CR/LF
This would let it be much more efficient in use, send full lines where line-buffering is appropriate, but still be useful for single-character transmissions with only a modest latency for the rest of the time (eg, send buffer with CR/LF all the time, but ALSO send the buffer after a definable time - like 100ms).
CAI_Support
Senior Member
Hi Ross,
I will look into this, since I am not this code developer, I will have to look the code to understand then tell more details. However, I have participated in the testing this function back a few years ago. That testing using a serial console connected to WC32 serial port, then on another PC running windows and com0com driver, then have PC terminal software configured talk to the com0com driver. When typing on serial console connected to the WC32, it displayed on PC terminal software, then type anything on PC terminal software, it displayed on serial console.
Someone else did the Linux testing at that time using tty0tty driver on Linux. It did not test on BSD, but I assume BSD is not much different from Linux.
WC32 is not short of RAM. I will need to go into code details to be able to tell more.
Thanks.
I will look into this, since I am not this code developer, I will have to look the code to understand then tell more details. However, I have participated in the testing this function back a few years ago. That testing using a serial console connected to WC32 serial port, then on another PC running windows and com0com driver, then have PC terminal software configured talk to the com0com driver. When typing on serial console connected to the WC32, it displayed on PC terminal software, then type anything on PC terminal software, it displayed on serial console.
Someone else did the Linux testing at that time using tty0tty driver on Linux. It did not test on BSD, but I assume BSD is not much different from Linux.
WC32 is not short of RAM. I will need to go into code details to be able to tell more.
Thanks.
ok, I've just programmed up a simple pic to spit out a string of "0123456789" followed by a CR/LF, and a monitoring program to catch the data and indicate when a line that ISN'T exactly that, is received. It's sending about 80 chars/sec which should be a trivial task to keep up with...
There's definitely SOMETHING going on here, it's NOT related to the tty driver or lack thereof, it's cyclical and seems to be from within the WC32 itself. (This test was on a different WC32 just to eliminate the hardware, and is connected directly to the monitoring system. Firmware version 04.02.11)
15:30:40 0123456789
15:30:40 0123456789
15:30:42 0123456780123456789
243 lines, 2 seconds break, 35 seconds since last error
15:35:00 0123456789
15:35:00 0123456789
15:35:02 0123456780123456789
2151 lines, 2 seconds break, 260 seconds since last error
15:37:11 0123456789
15:37:11 0123456789
15:37:13 0123456789123456789
182 lines, 2 seconds break, 27 seconds since last error
15:39:22 0123456789
15:39:22 0123456789
15:39:24 0156789
953 lines, 2 seconds break, 131 seconds since last error
15:43:42 0123456789
15:43:42 0123456789
15:43:44 0123456780123456789
1908 lines, 2 seconds break, 260 seconds since last error
(Interesting, that's virtually exactly 953*2 lines and 131*2 seconds)
15:45:53 0123456789
15:45:53 0123456789
15:45:55 0156789
953 lines, 2 seconds break, 131 seconds since last error
15:48:04 0123456789
15:48:04 0123456789
15:48:06 0123459
953 lines, 2 seconds break, 131 seconds since last error
15:50:15 0123456789
15:50:15 0123456789
15:50:17 0123456780123456789
953 lines, 2 seconds break, 131 seconds since last error
15:54:35 0123456789
15:54:35 0123456789
15:54:38 0123489
1908 lines, 3 seconds break, 261 seconds since last error
15:56:46 0123456789
15:56:49 0123456789
15:56:49 0456789
954 lines, 0 seconds break, 131 seconds since last error
15:58:57 0123456789
15:59:00 0123456789
15:59:00 0156789
953 lines, 0 seconds break, 131 seconds since last error
There's definitely SOMETHING going on here, it's NOT related to the tty driver or lack thereof, it's cyclical and seems to be from within the WC32 itself. (This test was on a different WC32 just to eliminate the hardware, and is connected directly to the monitoring system. Firmware version 04.02.11)
15:30:40 0123456789
15:30:40 0123456789
15:30:42 0123456780123456789
243 lines, 2 seconds break, 35 seconds since last error
15:35:00 0123456789
15:35:00 0123456789
15:35:02 0123456780123456789
2151 lines, 2 seconds break, 260 seconds since last error
15:37:11 0123456789
15:37:11 0123456789
15:37:13 0123456789123456789
182 lines, 2 seconds break, 27 seconds since last error
15:39:22 0123456789
15:39:22 0123456789
15:39:24 0156789
953 lines, 2 seconds break, 131 seconds since last error
15:43:42 0123456789
15:43:42 0123456789
15:43:44 0123456780123456789
1908 lines, 2 seconds break, 260 seconds since last error
(Interesting, that's virtually exactly 953*2 lines and 131*2 seconds)
15:45:53 0123456789
15:45:53 0123456789
15:45:55 0156789
953 lines, 2 seconds break, 131 seconds since last error
15:48:04 0123456789
15:48:04 0123456789
15:48:06 0123459
953 lines, 2 seconds break, 131 seconds since last error
15:50:15 0123456789
15:50:15 0123456789
15:50:17 0123456780123456789
953 lines, 2 seconds break, 131 seconds since last error
15:54:35 0123456789
15:54:35 0123456789
15:54:38 0123489
1908 lines, 3 seconds break, 261 seconds since last error
15:56:46 0123456789
15:56:49 0123456789
15:56:49 0456789
954 lines, 0 seconds break, 131 seconds since last error
15:58:57 0123456789
15:59:00 0123456789
15:59:00 0156789
953 lines, 0 seconds break, 131 seconds since last error
