Strange!! But true Ethernet is not Protocol!!!

Ethernet is not a protocol

Carl’s pet peeve number three*: Ethernet is not a protocol.

IMS Research found that the number one industrial Ethernet protocol is “Ethernet TCP/IP.” [“Double Your Pleasure, Double Your PROFINET”]

VDC found the leading industrial Ethernet protocol is “Ethernet.”

Ethernet is not a protocol!  I ranted about this before, way back in 2006: “Why Use Industrial Ethernet?”  So today I’ve counted to ten and will move from rant mode to education mode.

Networking is characterized in the ISO/OSI reference model.  Its seven layers define the functions of various aspects of networks. Wikipedia has a complete explanation: OSI Model.  The Internet Model collapses the layers to four.


Layers 1 and 2 are defined by IEEE802.3 which we know as “Ethernet.”  To overstate this: Ethernet is just the Physical layer and the Data Link layer.  By itself Ethernet does nothing; it’s just the “pipe.”  What comes down the pipe?  Whatever IP sends down the pipe (when TCP/IP is used).  IP is at layer 3.  IP sends the message it received up to layer 4, TCP.  So what do TCP and IP do?  Just send the message on to where they’re told.  Up at the top of the stack is the application layer, at layer 7.  The application layer is where the protocol resides.  Only the application layer actually does more than send the message along its way.  (What happened to layers 5 and 6?  They are neither needed nor used.)

Now, IP and TCP are not the only choices for layers 3 and 4, respectively.  You can substitute UDP at layer 4 for example.  Or you can skip them altogether like Address Resolution Protocol (ARP) does; it goes straight from layer 2 to an application.

PROFINET takes a lesson from ARP.  It skips TCP and IP for real-time messages.  TCP and IP (aka “the stack”) is implemented in software.  Rather than let PROFINET real-time messages languish in the stack, we skip it.  This improves speed and determinism.  (See the Industrial Ethernet Book article for details: “Technical Article: Performance metrics for Industrial Ethernet”.)

So, when users respond to IMS and VDC and say their Industrial Ethernet protocol is “Ethernet,” what do they mean?  I would not accept this answer if I were a market research company!  So what do they mean?  Do they mean web server? A real Industrial Ethernet protocol?  A Proprietary protocol?  “I have no blooming idea what a protocol is?”

What do you think they mean?

–Carl Henning

*Number one: Wireless is not monolithic: “Wireless or Wireless
Number two: Why can’t Control Engineers and IT get along?  (Although there is certainly improvement in this relationship from five years ago.)



Some communication standards just emerge. Not because they are pushed by a large group of vendors or a special standards organisation. These standards—like the Modbus interface—emerge because they are good, simple to implement and are therefore adapted by many manufacturers. Because of this, Modbusbecame the first widely accepted fieldbus standard.

Modbus has its roots in the late seventies of the previous century. It is 1979 when PLC manufacturer Modicon—now a brand of Schneider Electric’s Telemecanique—published the Modbus communication interface for a multidrop network based on a master/client architecture. Communication between the Modbus nodes was achieved with messages. It was an open standard that described the messaging structure. The physical layer of the Modbus interface was free to choose. The original Modbus interface ran on RS-232, but most later Modbus implementations used RS-485 because it allowed longer distances, higher speeds and the possibility of a true multi-drop network. In a short time hunderds of vendors implemented the Modbus messaging system in their devices and Modbus became the de facto standard for industrial communication networks.

MODBUS is an application layer messaging protocol that provides client/server communication between devices connected on different types of buses or networks.

MODBUS is a request – replay protocol offering services specified by function codes. It can be implemented on different physical supports and networks such as: RS232, RS485 or Ethernet.

MODBUS/TCP is a communication protocol designed to allow equipment such as Programmable Logic Controllers, computers, operator panels, motors, sensors, and other types of physical input/output devices to communicate over a network.

The master of system sends telegrams to a specific slave unit (uni-casting dialog) or to all the units (broadcasting dialog) that are linked in the network, and after that he wait for the response of them. The response is processed generating a new action.

In the table and figure present the levels of protocol in accordance with the general form of OSI layers.


OSI Model




MODBUS Application Protocol










Link MODBUS Serial Protocol


Physical EIA/TIA-232 or EIA/TIA-485

 The layers of MODBUS protocol (EPA architecture)

The standard protocol define some abbreviations:

ADU Application Data Unit
HDLC High level Data Link Control
MAC Medium Access Control
PDU Protocol Data Unit

In the case of MODBUS protocol the application data unit is build by the client that initiate a transaction to the server. The server will process the request and will response with a new telegram at the client.

MODBUS frame Application Data Unit

MODBUS frame Application Data Unit that includes Protocol Data Unit

The transmission mode defines the bit contents of the message bytes transmitted along the network, and how the message information is to be packed into the message stream and decoded. MODBUS serial communication and MODBUS TCP/IP are compared to the 7 layers of the OSI model.



The code functions accepted by MODBUS are represented by a byte, which accept one of the values 1 to 255 (the codes between 128 to 255 are reserved for exceptions). The code functions specify for the server the action that it must perform. 

Sub-function codes are added to some function codes to define multiple actions. The data field of messages sent from a client to server contains additional information that the server uses to take the action corresponding to function code.

This can include items like discrete and register addresses, the quantity of items to be handled, and the count of actual data bytes in the field and so on. Some function can be transmitted without operands.

For a normal response, the server simply echoes the original function code. If the telegram is properly received the server will return to client the response with data requested. If the telegram is received with error the server will return an error message that will generate the resend of initial telegram (we name this a exception code). If the error are maintained an uncovered error will by generated in order to indicate the status of the link.



modbus protocolSend RequestRequest

transmission modbus

           Perform the action requested

Receive the response  

 Typical dialog between client and server for MODBUS protol

  • To send request means to transmit the function code and the data corresponding for it.
  • The response will include the function code and the data requested.

Three categories of MODBUS function codes are defined:

  • Public function Codes
  • User-defined function Codes
  • Reserved function Codes

The first category include well-defined public function codes, unique defined for all the users of protocol. These functions are documented in the MODBUS IETF RFC and are verified by the MODBUS organization.

The user-defined codes, assure the flexibility of protocol that accept that the producer can add new functions without the approval of These codes not present the guaranty that they are unique. In this case the producers must initiate a new RFC in order to publish the specification of them.

Related to the reserved functions, these are functions used by companies for legacy products and not represent public functions interest.

Table 5.4 Address of functions


Which are the dedication of domain address

111 to 127

Public Function Codes

100 to 110

User-defined Function Codes

73 to 99

Public Function Codes

66 to 72

User-defined Function Codes

1 to 65

Public Function Codes

Standard MODBUS networks employ one of two types of transmission modes:

  • ASCII Mode
  • RTU Mode.

The mode of transmission is usually selected along with other serial port communication parameters (baud rate, parity, etc.) as part of the device configuration.

 ASCII Transmission Mode

In the ASCII Transmission Mode (American Standard Code for Information Interchange), each character byte in a message is sent as 2 ASCII characters. This mode allows time intervals of up to a second between characters during transmission without generating errors.

RTU (Remote Terminal Unit) Transmission Mode

In RTU (Remote Terminal Unit) Mode, each 8-bit message byte contains two 4-bit hexadecimal characters, and the message is transmitted in a continuous stream. The greater effective character density increases throughput over ASCII mode at the same baud rate.

RTU transmission mode

 RTU transmission mode

 Details related to the modbus serial implementation

In the serial implementation, the ASDU with the PDU are transmitted through a serial line that can be RS232 line (short distance), if the line link two elements, or RS485 line (long distance) if the link between the elements is a bus.

In ASCII mode, the word size is 7 bits, while in RTU mode; the word size is 8 bits. Thus, every 8 bits of an RTU message is effectively 11 bits when accounting for the start, stop, and parity bits of the data frame. The structure of the data frame depends on the transmission mode (ASCII or RTU).

The MODBUS data link layer comprises two separate sub layers:

  1. Master / slave protocol
  2. Transmission mode (RTU vs ASCII modes)

The state diagrams of a master and a slave that are independent of transmission modes used describe the reception and the sending of a frame are described in figure placed bellow.

State Diagram for Master MODBUS

 State Diagram for Master MODBUS

In the case of Master MODBUS, the steady state of system is idle state. In this case no pending requests are active.  A request can only be sent in “Idle” state. After sending a request, the Master leaves the “Idle” state, and cannot send a second request at the same time.

When a unicast request is sent to a slave, the master goes into “Waiting for reply” state, and a “Response Time-out” is started (value of the Response time-out is application dependant). It prevents the Master from staying indefinitely in “Waiting for reply” state.
When a reply is received, the Master checks the reply before starting the data processing.

The checking may result in an error, for example a reply from an unexpected slave, or an error in the received frame. In case of a reply received from an unexpected slave, the Response time-out is kept running. In case of an error detected on the frame, a retry may be performed (this kind of error is named “covered error”).

If no reply is received, the Response time-out expires, and an error is generated. Then the Master goes into “Idle” state, enabling a retry of the request. The maximum number of retries depends on the master set-up (these kind of error are named „uncovered errors“).
When a “broadcast request” is sent on the serial bus, no response is returned from the slaves.

Nevertheless the Master respects a delay in order to allow any slave to process the current request before sending a new one. This delay is called “Turnaround delay”. Therefore the master goes into “Waiting Turnaround delay” state before going back in “idle” state and before being able to send another request.

In “unicast requests” the Response time out must be set long enough for any slave to process the request and return the response, in broadcast the Turnaround delay must be long enough for any slave to process only the request and be able to receive a new one. Therefore the Turnaround delay should be shorter than the Response time-out. Typically the Response time-out is from 1s to several second at 9600 bps; and the Turnaround delay is from 100 ms to 200ms.
Frame error consists of:

  1. Parity checking applied to each character;
  2. Redundancy checking applied to the entire frame.

The state diagram is intentionally very simple. It does not take into account access to the line, message framing, or retry following transmission error, etc.

State Diagram for Slave MODBUS

 State Diagram for Slave MODBUS

The slave element is in idle stage until he doesn’t receive any request. This is the initial state after power-up. When a request is received, the slave checks the packet before performing the action requested in the packet.

Different errors may occur: format error in the request, invalid action. In case of error, a reply must be sent to the master. Once the required action has been completed, a unicast message requires that a reply must be formatted and sent to the master. If the slave detects an error in the received frame, no respond is returned to the master. MODBUS diagnostics counters are defined and should be managed by any slave in order to provide diagnostic information.

In figure 5.7 we show an example for control a coil element included in the network:

MODBUS Write Single Coil

Animation 5.8 MODBUS Write Single Coil

MODBUS is used to monitor and program devices; to communicate intelligent devices with sensors and instruments; to monitor field devices using PCs and HMIs; MODBUS is also an ideal protocol for RTU applications where wireless communication is required.

Finally we give in the figure 5.4 the structure of a program written on PC that implements the main functions of MODBUS protocol from client side.
In order to assure an efficient implementation of code for

each request is dedicated a class, derivate from base class CModebus that manage all the information transferred through MODBUS protocol. This class implement the MODBUS application layer.

The CMBTransport and CMBAsciiTransport are the classes that treat the link layer, respectively assure the implementation of transmission mode: RTU or ASCII. The CRS232Port class is used for the implementation of communication at the level of serial port from PC.

Structure of classes and derivative of them that implement MODBUS protocol, implemented on PC

 Structure of classes and derivative of them that implement MODBUS protocol, implemented on PC