Modbus over RS232 and RS485 kicked off networking in automation. Before then, all we had was I/O lines between sensors and actuators and a Programmable Controller. And before that, the I/O lines were run to the wall, where the coils and relays were hanging between power strips.
But if you’re an automation professional under the age of 30, it’s likely you have no idea what that last paragraph is all about. You’ve also missed the whole era of RS232 and RS485 communications. You’ve missed DB25 plugs, DB9s, gender changers (only cables changed gender then, not people), fighting wire termination problems on RS485, trying to figure out what baud rate, parity, and number of data bits a device was using. Not knowing which pin was which on an RS485 connection. Burning EPROMS to test a new software revision. Ahhhhhh, those were the good old days…
(Give me a minute to sigh and nostalgically remember them.)
What you may not know is that RS232 and RS485 were very popular, and the reason was simple: cost. Every microprocessor in the old days had something called a UART (Universal Asynchronous Receive Transmit). This was a part of the micro that would shift out or shift in some series of bits presented to it. The UART translated bytes into bits and bits into bytes. It was the only communications microprocessors had for many years.
The UART typically delivered those bits at 5-volt levels: 0 volts for a binary “0” and 5 volts for a binary “1”. RS232 and RS485 were electrical standards for moving data across a wire. Driver components on a circuit board would transform those logic bit levels into the bit levels of RS232 and RS485 and provide enough current to get a bit from one end of the wire to the other.
RS232 in the ‘60s
RS232 actually stands for Recommended Standard number 232. RS232 transports bits by driving a voltage potential across two wires, the transmit wire and a ground wire. A receiver senses the potential and records either a one or a zero. There are some synchronizing ones and zeros and some standard bit times that allow both the sending and receiving station to synchronize the transmission and reception.
An important characteristic of RS232 is that it is a single sender, single receiver system. It is electrically not possible for the RS232 electronics to drive a signal to multiple destinations. Master/Slave protocols didn’t use RS232. Modbus, for example, uses a Master to send to multiple Slave receivers; RS232 is only used very rarely as a Modbus transport layer since only one Slave could be supported.
RS485 in the ‘70s
RS485 was a successor to RS232. It works in a similar fashion regarding the synchronizing bits that synchronize the transfer of bits from a sending station to a receiving station. There are, however, two defining characteristics that make RS485 different from RS232. The first is the ability to drive multiple destinations. RS485 transmitters have the ability to electrically signal up to 32 destination devices. That makes RS485 the preferred way to serially transport Modbus messages.
The other defining characteristic of RS485 is enhanced noise immunity. RS485 does not use the electrical common as the reference for its electrical signal. Instead, RS485 uses a pair of wires and drives a signal by setting a voltage potential across the pair. By doing that, any environmental electrical noise affects both wires equally and the potential across the two wires isn’t changed. This is a vast improvement over RS232, and it made possible Modbus communication from a single Master to many Modbus Slave devices.
Rs485 is what made Modbus what it was. There wouldn’t have been much use for a Modbus Master that could only talk to one Modbus Slave over RS232. When RS485 came along, there were suddenly a lot of new possibilities in metering, data collection, and all sorts of other applications.
Unfortunately the inventors of these technologies have been lost to history. RS232 dates from the 1960s and RS485 from the 1970s. Do they know how pervasive it became? Do they know the impact it had worldwide? And how these technologies set standards for CAN, Ethernet, and everything else that came later? Let’s hope so.