Compare RS232 vs Ethernet from programmer's perspective?

Factual Questions
1

Scientific and technical programming on PCs often involves talking to instruments and machines that have RS232 interfaces. Most typically, the external device has some kind of format or script language, and gives and takes ASCII messages. For example, a stepper motor control might take an instruction like A200:V12.5:D22.2:GO:T10:TPM, which sets acceleration and velocity and a target distance, then performes a movement, then waits ten seconds, and then transfers the position of the motor back. It would return a string like *TPM22.2 to indicate that the motor had moved as instructed. You have to be able to manipulate strings and you have to set for example COM1 to 9600,8,N,1. The interface actually passes bytes one-at-a-time with perhaps some handshaking, and it isn’t too hard to graph what sending “a” would look like on an oscilloscope if you want.

Now many devices are also adding Ethernet interfaces. I’ve got Cat5e cable strung around my house and have hubs and switches laying about and have used Web-based data acquisition and other hardware with Web-page interfacing and configurations, but I have pretty little idea what Ethernet works like on a level like what I describe above. I think it’s packet data, which I imagine looks sort of like little files, with header and redundancy information. I think it can use TCP/IP to break big things up and reassemble them at the other end and manage reordering and requesting parts be resent and whatnot. But I think it can use things other than TCP/IP too. I’m really pretty vague on the whole thing.

Can anybody enlighten me? What does it look like to send “D22.5:GO” to a device by Ethernet? Do you send it to a 255.255.255.255-like address?

2

Ahh, SDMB is converting some of my text to little pictures again. I don’t know how many times I’ve turned that off. Besides, the whole point of “emoticons” was that you could use punctuation to make what looked like little sideways faces - turning them into real little pictures kind of ruins the appeal, doesn’t it? Anyway, I am not sending small round bluegreen people over RX, TX and ground.

3

I’ve written that sort of software. The simplest thing to do is to use UDP to communicate with the device. I’ve never been a fan of using ASCII command strings, although some engineers insist on doing everything with ASCII text. I’ll use C structs to define the packet formats for commands and responses. All data is in binary format. This avoids wasting lots of CPU cycles on conversions. For some systems, you can skip UDP and just use raw Ethernet packets. A lot of this is going to depend on whether or not you are designing all the software. If someone hands you someone else’s device controller, you are stuck with its interface and I/O conventions. Sometimes, like with IEEE-488 devices, you have to use a vendor supplied library to communicate with the device. I’m prejudiced by having written a lot of software for systems that didn’t have spare CPU cycles or memory to waste on non-essential work, or any operating system to speak of, except possibly a real-time executive for support of multiple tasks. Ethernet is much simpler than screwing around with RS-232 IMHO. You have 1500 bytes (minus overhead) to work with. Although it’s non-deterministic and delivery isn’t guaranteed, in practice it is very fast and reliable. You can write your own protocols for things like device discovery and auto-configuration.

4

Well, there’s Ethernet-IP (Industrial Protocol) that has both a deterministic I/O layer as well as a non-deterministic data layer. It’s alleged that either (a) conventional Ethernet can route over Ethernet-IP switching gear, or (b) Ethernet-IP can router over conventional Ethernet switching gear, or (c) both of these – I’ don’t quite remember (we’re just now starting to migrate to Ethernet-IP as our industrial controls architecture, so I don’t know all of the specifics quite yet.).

5

First of all “Ethernet” and "RS-232 are physical media descriptions, not a protocols.
There is no reason why the same protocols can’t run over either medium (although in practice, they won’t).
Secondly. a lot depends on the particular interface. As mentioned above, UDP is probably your best bet - it is the simplest commonly used protocol which runs over Ethernet.
To talk to a device which understands UDP, you craft a packet which has the units IP address, a port (so that different types UDP commands can be differentiated), and the data, and send it off. The packet is not guaranteed to reach it’s destination, so you might want the far end to respond back with an ACK packet.
UDP isn’t as simple as standard serial protocols, but it seems to be the way the world is going…

6

No, Ethernet is most definitely a protocol, with its own addressing scheme, error correction and collision detection. The physical media that it can run on includes copper twisted pair of several varieties (10BASE-T, 100BASE-TX), coax cable (10BASE-2/thin-net), and fiber optic.

UDP runs over IP, and IP can run over Ethernet.

For most devices, you won’t need to do anywhere near that level of work. If the device already has a serial connection, chances are it provides the same console-based interface via a simple telnet-like protocol running on the onboard Ethernet. You should be easily able to adapt whatever code you’re using to talk to the serial port to talk over telnet instead, assuming you have properly maintained separation of concerns. :slight_smile:

7

Well, suppose I want to send the byte E6x, or the ASCII string “RESET;;;”, or the contents of a file (not the file itself, just the contents), or suppose I want to listen for incoming bytes for the next ten seconds. I know how to try it “manually”, that is, with a program like RealTerm or Hyperterminal, and in a few different languages I know how to configure a PC serial port for handshaking and rate and whatnot and then do these simple tasks.

How would I do it over Ethernet?

For example, if I know the IP address of a device, and maybe know what port number it wants to hear my message through, is there something like Realterm or Hyperterminal that lets me try it quickly?

Or how about programatically? I guess if I looked through C# I’d find something that does this, too - anybody know what? I’ve only written a handful of C# programs and so far they aren’t hardware or systems oriented. I’d probably use a more familiar environment to try this the first time, like SAS or LabVIEW or FORTH, if they support this kind of thing; I haven’t looked into that yet either. I’m sort of poking around trying to get a mental picture of how it generally works at the moment. I’m not a programmer, I’m a scientist who programs.

And, no, I’m generally not building the device hardware or determining its communications or operating protocols, I’m buying an instrument or controller or datalogger or DAQ module and reading its manual and writing software on the PC that operates and reads it. Almost every one of these things I have done so far uses ASCII. Some ask questions and await a response, so they’re really oriented around people using a terminal emulator. Others require complicated strings with mnemonics and punctuation and numeric data, but still plain text. I’ve only worked with one device that uses binary transmissions, and it’s only sending a byte or 2 or 3 or 4, and the bits are flags with predefined meanings, so it’s also pretty easy to work with.

8

Yes, Telnet. Just point that thing at the IP and port number and see what happens. This is the first step in most all IP-based programming. Putty is a popular telnet/SSH client for Windows. If you’re on a MacOS or other Unix-type machine just open a terminal window and use the commandline telnet.

9

I use nc (netcat) under OS X to send UDP.

10

I’m surprised no one has yet directed you to the RFCs. See RFCs by category for an organized jumping off place; Ethernet is under Media, while IP, UDP, and TCP are listed under Internet Protocol.

Not that you really want to sift through them to find your answers, but they’re good to have bookmarked for reference purposes.

11

Others have answered the first question: Telnet is an interactive TCP client.

For the second question: To write a TCP client program, you use sockets. The system socket libraries let you connect to a specified host:port using either TCP or UDP and then send and receive data before closing the socket. Many languages provide simpler higher-level interfaces that abstract away some of the tedious details, which can be useful for simpler applications. Typically to connect to a TCP server you might do a sequence something like this (Python syntax):


import socket
# create an Internet-domain stream (i.e., TCP) socket; UDP is SOCK_DGRAM
sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
# connect the socket to server.name:12345
sock.connect(("server.name",12345))
# send data to the server
sock.sendall(data)
# receive up to bufsz bytes of data from the server
data = sock.recv(bufsz)
# ...
# close the socket
sock.close()

which is to say: Connect the socket to the server; write data to the server (and/or read data from the server); and close the socket. A similar but slightly more complicated sequence of commands can be used to write the server end.

Googling tells me that C# has sockets, but I’ve never used C# so you’ll have to look up the details.

12

It seems to me that you’re looking for the gist of the difference between the two types of programming, not necessarily a discussion of the exact APIs used. Here is my stab at it:

  1. on an RS-232 connection, you’ve got two endpoints and each one opens up the connection and starts sending bytes. There are some details about the signaling (rate, bits, parity) that both sides tend to have agreed upon ahead of time, but other than that, you think of it as a direct pipe of bytes.

  2. oversimplifying greatly, the basic working of a UDP client-server connection goes something like, “I would like to receve data on port 1234” (the port number a fairly arbitrary detail of the communications, which allows multiple applications to use the network interface at once by picking different ports), and the other side says, “I would like to send <this data> to address 2.3.4.5 on port 1234”. It can be, and often is, that simple, but there are additional considerations like how the devices know each other’s addresses (in my example, they’re hardcoded, but in the real world there are many ways of doing this, such as having a discovery protocol that involves sending out broadcast messages and waiting for responses like, “hey, I’m a robotic gun turret and I’m at address 2.3.4.5! Connect to port 1234 to make me shoot people!”), and how you make sure you’re talking to the right person (since, obviously, on a network, there is potentially more than one device on “the other end”, unlike with RS-232).

In addition, with UDP, it’s “that simple” but it’s not, because you don’t really know whether the other end received your packet, and if they didn’t you have to send it again, and they might have received it in the wrong order, etc. TCP is a protocol which addresses these issues, and changes the semantics slightly: the end that says “I’d like to listen for data on port 1234” gets notified of an incoming “connection” and has to accept it, and once it does, it’s treated like a data pipe that’s 1:1. Underneath, the TCP subsystem is worrying about packets making it to their destination, retransmitting when necessary, buffering them to make sure they arrive in the correct order and all that, and the application will get an error if, for example, a packet failed to get sent.

13

In the programming languages I use, there are add-on products that take care of the low level stuff and give you a series of function calls that you can use. You call a function to initialize a communication process with the IP, port, etc., send strings, receive strings, open and send a file, and so on. In windows, they even include the code to trap for events such as TCP Packet received, error handling and so on.

So it really turns out not to be too much different between RS232 and Ethernet. Last year I converted some code I had that talked to an RFID scanner to track trucks through a loading process at a sand & gravel pit. We added a second RFID reader to pick up another scale. The second reader was from the same manufacturer as the older one, and supported essentially the same command set on Ethernet that the other did on serial. I didn’t have to modify the logic that much.

The biggest difference was in the error handling. With the serial communication functions I had, each time you call the function to send data, you immediately get back a return code that tells you if the send was successful, or and error cod if not. Likewise, to receive data, you call one of the receive functions and again immediately get a return code indicating success or failure.

With the Ethernet functions, it’s much more event driven. You have event handling routines for each possible (or at least expected) event. You call the send function, and if there is an error, the error event trigger and you handle it there. Receiving data is similar, you don’t do anything until the event indicating you received data fires, then you call the function to get that data and use it.

All this depends very much on your task, and how low level you want to get. But for talking to standard devices like scales, sensors, processing equipment, etc, where the communication is likely to be fairly “high” level (string and binary data, commands with parameters, etc.) your best bet is to get an Ethernet function library compatible with your programming language.

In some cases, you may even be able to use a telnet program (ProComm Plus is my all purpose serial and telnet terminal emulator) and just use the built in scripting program to send and receive a simple series of commands or act as a console for manual interaction or configuration.

14

Great info, thanks.

>Yes, Telnet. Just point that thing at the IP and port number and see what happens. This is the first step in most all IP-based programming. Putty is a popular telnet/SSH client for Windows.

Ah! Perfect. Now I know the first thing about replacing RS232 with Ethernet.
>I’m surprised no one has yet directed you to the RFCs.

Well, thanks! I’ll go look.
>To write a TCP client program, you use sockets.

So that’s what sockets are for. Or at least one thing they’re for. I think I’ve noticed stuff about them in several of my tools, but didn’t know they’d figure in this. Thanks for the python example. If you haven’t tried C#, well, in small doses it looks so much like Java they’re hard to tell apart, except things like libraries are often different.
>It seems to me that you’re looking for the gist…
Yes, exactly!
>1) on an RS-232 connection, you’ve got…
OK, we’re on the same page here.
>2) oversimplifying greatly, the basic working of a UDP client-server connection goes something like…
I follow this, sounds good, sounds interesting.
>In addition, with UDP, it’s “that simple” but it’s not, because you don’t really know…
Yes, I see that. So, I read somewhere about the seven layers of networking, the copper physical layer, a layer of packets, a layer that manages putting things into packets and getting a cogent and correct structure out of them again (with requests to resend some as needed), and so on. Sounds like this is it.

>All this depends very much on your task, and how low level you want to get.

Yes, it certainly does. I have done RS232 on PCs by reading and writing to chip registers, and by using built in functions in programming languages and by calling routines that do it. I’ve also used serial communications at the TTL level without the RS232 high voltage line drivers, and dabbled with shift registers and memories to create a serial byte stream. But I appreciate that what is done with Ethernet is going to work better for me if I call on existing functions or libraries.

Thanks, all, this is exactly the kind of thing I was hoping to hear! Perfect!