RS485

Networking with RS485/Modbus

RS485 is used for low-cost networking, and is commonly used in many industrial and agricultural applications. RS485 is a multi drop implementation of RS422. To understand RS485, we first need to look at RS422. (Scamp3e RS485 commands follow on.)

RS422 - Point to Point

Unlike RS232C, which is referenced to local ground, RS422 uses the difference between two lines, known as a twisted pair or a differential pair, to represent the logic level. Thus, RS422 is a balanced transmission, or in other words, it is not referenced to local ground. Any noise or interference will affect both wires of the twisted pair, but the difference between them will be less affected. This is known as common-mode rejection. RS422 can therefore carry data over longer distances and at higher rates with greater noise immunity than RS232C. RS422 can support data transmission over cable lengths of up to 1,200 metres (approximately 4,000 feet).

A basic RS422 link consists of a driver (D) of one embedded system connected to a receiver (R) of another embedded system via a twisted pair. The resistor, Rt, at receiving end of the twisted pair is a termination resistor. It acts to remove signal reflections that may occur during transmission over long distances, and is required. Rt is nominally 100-120 Ω.

The voltage difference between an RS422 twisted pair is between ±4 V to ±12 V between the transmission lines. RS422 is, to a degree, compatible with RS232C. By connecting the negative side of the twisted pair to ground, RS422 effectively becomes an unbalanced transmission. It may then be mated with RS232C. Since the voltage levels of RS422 fall within the acceptable ranges for RS232C, the two standards may be interconnected.

It’s important to note that RS422 only specifies the voltages for the standard, not the physical implementation (pinouts or connectors). That is covered by RS449. Now, no one seems to bother with RS449, mainly because it is unnecessarily complex for most applications. People using RS422 just seem to do their own thing, picking whatever cable and connectors (and pinouts!) they feel are appropriate for their application. Self-expression and RS422 seem to go hand in hand.

Some RS422 interface chips have an optional enable input. When enabled, the chip outputs and drives a transmission onto the twisted pair. When disabled, the chip’s output is high impedance, and the chip appears “invisible.” Because of the ability of the interface chip to “disappear” from the connection, it is possible to have multiple interface chips (and therefore more than two embedded systems) connected to the twisted pair. In this way, it is possible to extend RS422 into a low-cost, robust, simple network. When implemented in this fashion, it becomes RS485.

RS485

RS485 port on Scamp3e

RS485 is a variation on RS422. It is one of the simplest and easiest networks to implement. It allows multiple systems (nodes) to exchange data over a single twisted pair.

RS485 is based on a master-slave architecture. All transactions are initiated by the master, and a slave will only transmit when specifically instructed to do so.

There are many different protocols that run over RS485, and often people will do their own thing and create their protocol specific to the application at hand. RS485 may be implemented as half duplex, where a single twisted pair serves for both transmission and reception, or full duplex where separate twisted pairs are used for each direction. Full duplex RS485 is sometimes known as four-wire mode. Half-duplex RS485 is by far the more common implementation.

For a typical RS485 transceiver, the UART Tx from the microcontroller is connected to Data In (DI), and Rx is connected to Receiver Out (RO). Data Enable (DE) and Receiver Enable (~RE) are controlled by GPIO of the microcontroller, and allows the microcontroller to assume control of the bus under software control. On the network side, the transceiver has two signal lines, A and B. To connect RS485 devices together, A connects to A and B connects to B on each device.

Typical RS485 Transceiver

Now, you’ll notice that DE is high active, and ~RE is low active. This is not by chance. A node on the network won’t be receiving traffic if it’s transmitting, and conversely, won’t be transmitting if it is receiving. Therefore, only one of the transmitter or receiver should be active at any one time. If the transmitter’s on, the receiver should be off, and vice versa. The control for the transmitter is therefore the logical opposite of the control for the receiver. By having DE high active and ~RE low active, a single control line may be used for both. The microcontroller normally has DE/~RE low so that it is listening to network traffic. When it wishes to transmit, it sends DE/~RE high. Upon completion of transmission, it returns DE/~RE low, and resumes listening.

Normally, all systems connected to the RS485 network have their receivers enabled and listen to the traffic. Only when a system wishes to transmit does it enable its driver. There are a number of formal protocols that use RS485 as a transmission medium, and twice as many home-spun protocols as well. The most common protocol is Modbus. The Modbus page on Wikipedia provides a good overview.

The main challenge you need to avoid is the possibility of two nodes on the network transmitting at the same time. The simplest technique is to designate one node as a master node, and the others as slaves. Only the master may initiate a transmission on the network, and a slave may only respond directly to the master, once that master has finished.

The number of nodes possible on the network is limited by the driving capability of the interface chips. Normally, this limit is 32 nodes per network, but some chips can support up to 512 nodes.

Scamp2e UART2

On the Scamp2e only, UART2 is shared between the RS485 interface and the main connector. It is mapped to the RS485 interface by default. The word u2>ser maps UART2 to the main connector. Similarly, the word u2>485 maps UART2 back to the RS485 interface, and sets the baud rate to 9600 bps. Note this only applies to the Scamp2e and only to UART2. UART1 is always available on the Scamp2e main connector.

RS485 Commands

The Scamp2e and Scamp3e have onboard RS485 transceivers. On the Scamp3e, RS485 is connected to the PIC24's UART3 (U3) module. On the Scamp2e, UART2 is shared between RS485 and the serial port U2.

The baud rate at start up is 9600 bps. Changing the baud rate is accomplished by the word rs485baud and its use is similar to the other UARTs. For example, to set the RS485 baud rate to 1200 bps:

1200. baud rs485baud !

At start up, the RS485 transceiver is in receive mode. To enable transmission (and stop receiving), use the word talk. Upon completion of data transmission, the word listen disables the transmitter and places the Scamp into receiver mode again. It's important to return to receiver mode so that the Scamp isn't driving the RS485 bus, since only one device can drive the bus at a time.

The word tx485 is used to send a byte/char over the RS485 network once the Scamp is in transmit mode. To send the byte $41:

talk $41 tx485 listen

As an example, to send a carriage return and line feed pair over RS485:

: nl ( -- , send a cr/lf over RS485)
  talk
  $d tx485 $a tx485
  listen
;

The word rx485? checks if a byte has been received over the RS485 network, and returns a boolean to the stack:

rx485?

The word rx485 waits until a byte has been received, and places that byte on the stack.

rx485

Note there is no timeout for rx485 so use rx485? to verify that a char has been received.

Snooping the RS485 Bus

Sometimes it can be useful to monitor traffic over RS485 to diagnose problems. The following word will print out ASCII traffic on the RS485 bus.

: snoop
listen
cr
begin
rx485? if
rx485 emit
then
key? until
;

Here is the same thing, but this time it prints out the bytes in hex:

: hexsnoop
hex
listen
cr
begin
rx485? if
rx485 u.
then
key? until
;

RS485 Terminal

As another RS485 example, here is a simple (and crude) chat program between two Scamp3e computers over RS485, or you can use it to interact with other RS485 devices for debugging. Run chat on both, type ctrl-c to abort.

: chat
begin
\ has something come in over RS485?
rx485? if
rx485 emit
then

\ local user typing
key? if
key \ get the typed char
dup 3 = if drop exit then
bold
dup emit \ print it out locally in bold
plain
talk tx485 listen \ send it over RS485
then
again
;

This word can also be used to interactively debug another RS485 device, allowing you to interactively type RS485/Modbus commands and see the response.

Mapping the Console to RS485

As with the other UARTs, the console can be remapped to the RS485 network:

: rs485 \ redirects to RS485
['] tx485 'emit !
  ['] rx485 'key !
  ['] rx485? 'key? !
;

: console \ maps back to console
['] txu 'emit !
  ['] rxu 'key !
['] rxu? 'key? !
;

If we create a word to print out a string, we can send it over RS485:

: greet
." hello world"
;

rs485 talk greet listen console

As always, it's important to return control to the console.

Controlling a Node over RS485

The following shows how one Scamp3e can control another over RS485. The word node is run on the remote Scamp3e, and master is run on the master Scamp3e. When the user types a 'b' (ASCII code 98) on the master, the remote Scamp3e blinks its LED. If the user types an 'r' (ASCII code 114), the remote Scamp3e changes the LED array randomly.

\ run this on remote Scamp
: node
begin
rx485? if
rx485 dup
#98 = if \ 'b'
blink
then
#114 = if \ 'r'
random leds
then
then
key? until
;

\ run this on master Scamp
: master
begin
rxu? \ user input
if
rxu
talk tx485 listen
then
again
;

MODBUS

Modbus is a communication protocol widely used in industrial automation and control systems to facilitate communication between devices and equipment, such as programmable logic controllers (PLCs), sensors, and other hardware components. It was originally developed by Modicon (now Schneider Electric) in 1979 and has since become one of the most popular protocols in industrial settings due to its simplicity, robustness, and versatility.

Modbus operates over various communication mediums, including serial communication (RS232 and RS485) and Ethernet-based communication (TCP/IP). It follows a master-slave architecture, where one device (the master) initiates communication with one or more devices (the slaves). The master device sends requests to read or write data to specific memory registers within the slave devices.

There are two main variants of the Modbus protocol:

Modbus RTU (Remote Terminal Unit): This variant uses binary encoding over serial communication (RS232 or RS485). It is characterized by its compact data representation, making it suitable for environments with limited bandwidth or noise-prone conditions.

Modbus ASCII: Similar to Modbus RTU, this variant also operates over serial communication. However, it uses ASCII characters for data encoding, which can make it more human-readable but less efficient compared to RTU.

Modbus commands, also known as Modbus function codes, are used to perform specific operations in a Modbus communication network. Here is a list of commonly used Modbus commands along with their function codes:

Modbus Functions:

Read Coil Status (Function Code: 0x01)
- Reads the status of discrete output coils (binary data) from a slave device.
Read Input Status (Function Code: 0x02)
- Reads the status of discrete input contacts (binary data) from a slave device.
Read Holding Registers (Function Code: 0x03)
- Reads the values of holding registers (16-bit data) from a slave device.
Read Input Registers (Function Code: 0x04)
- Reads the values of input registers (16-bit data) from a slave device.
Force Single Coil (Function Code: 0x05)
- Writes a single bit value to a discrete output coil in a slave device.
Preset Single Register (Function Code: 0x06)
- Writes a single 16-bit value to a holding register in a slave device.
Force Multiple Coils (Function Code: 0x0F)
- Writes multiple bit values to a range of discrete output coils in a slave device.
Preset Multiple Registers (Function Code: 0x10)
- Writes multiple 16-bit values to a range of holding registers in a slave device.
Report Slave ID (Function Code: 0x11)
- Requests a slave device to report its identification and status.
Read File Record (Function Code: 0x14)
- Reads data from a file record in a slave device.
Write File Record (Function Code: 0x15)
- Writes data to a file record in a slave device.
Encapsulated Interface Transport (Function Code: 0x2B)
- Used in Modbus TCP/IP to encapsulate other Modbus requests.

These are some of the core Modbus commands. Each command serves a specific purpose in reading or writing data from or to slave devices. The function codes are used in Modbus requests to specify the type of operation that needs to be performed. Keep in mind that the exact command set might vary depending on the specific Modbus variant you are using (RTU, ASCII, or TCP/IP) and any extensions or customizations implemented by different manufacturers or applications.

Modbus is widely supported by various industrial devices and software tools. It's known for its simplicity, making it relatively easy to implement and troubleshoot. However, due to its lack of built-in security features, it's important to implement additional security measures, such as using virtual private networks (VPNs) or secure communication protocols, when using Modbus over public networks.

Modbus.org is the official website for Modbus, maintained by the Modbus Organization. It offers a wealth of resources including documentation, specifications, tutorials, and links to various tools and libraries for implementing Modbus communication. You can find detailed information about different Modbus variants, application examples, and more.

Simply Modbus is a website that provides information and resources for learning about Modbus. It offers tutorials, guides, and software tools for testing and implementing Modbus communication.