Modbus Protocol

What is Modbus?

Modbus

Mod­bus is a com­mu­ni­ca­tions pro­to­col based on master/slave (RTU) or client/server (TCP/IP) archi­tec­tures that can oper­ate on the 1st, 2nd, 7th lev­el of the OSI Model.

Orig­i­nal­ly designed in 1979 by Mod­i­con for its range of PLCs, it is now a de fac­to stan­dard com­mu­ni­ca­tions pro­to­col in the indus­try, becom­ing the most wide­ly avail­able pro­to­col for the con­nec­tion of indus­tri­al elec­tron­ic devices.

  • Mod­bus allows to con­trol a net­work of devices, for exam­ple a meter read­ing sys­tem, and com­mu­ni­cate the mea­sures to a computer.

  • One lev­el high­er in the archi­tec­ture, Mod­bus is also some­times used to con­nect SCADA (super­vi­so­ry con­trol and data acqui­si­tion) sys­tems with RTUs (remote ter­mi­nal units).

  • To suit this vari­ety of appli­ca­tions, sev­er­al Mod­bus pro­to­col ver­sions are avail­able for ser­i­al and Eth­er­net media.

jump to RTU vs TCP jump to How it works jump to Ports

Why is Modbus so widespread?

  • Because it was designed for indus­tri­al applications,
  • it is easy to imple­ment and requires lit­tle development,
  • It han­dles blocks of data with­out restric­tions,
  • and it is pub­lic and free of charge.

What are common limitations with Modbus ?

  • Since Mod­bus is a master/slave based pro­to­col, it is not pos­si­ble for a field device to report changes by itself (with the excep­tion of Mod­bus over Eth­er­net net­works). Thus the mas­ter node must rou­tine­ly poll each field device and look for the data changes itself. This delays the net­work and con­sumes band­width, which can be a prob­lem in appli­ca­tions where band­width is expen­sive, such as a low bit rate radio link.
  • Since Mod­bus was designed for the com­mu­ni­ca­tion with PLCs in the late 1970s, the num­ber of data types is lim­it­ed to those under­stood by PLCs at that time.
  • The Mod­bus pro­to­col can only address a max­i­mum of 254 devices on a data link, lim­it­ing the num­ber of devices that can con­nect to a mas­ter sta­tion (again with the excep­tion of Eth­er­net TCP/IP).
  • There is no stan­dard way for a node to find the descrip­tion of a data object, for exam­ple, to deter­mine if a reg­is­ter val­ue rep­re­sents a volt­age in a cer­tain range.
  • Mod­bus trans­mis­sions must be con­tigu­ous, which requires remote com­mu­ni­ca­tion devices to be able to store data to avoid gaps in trans­mis­sion.
  • Mod­bus does not pro­vide pro­tec­tion against unau­tho­rized com­mands or data interception.

Modbus Variants/Versions

Mod­bus RTU
This ver­sion is used for ser­i­al com­mu­ni­ca­tion (e.g. over RS-232, RS-422 or RS-485 ser­i­al ports) and thus the most com­mon one. The pro­to­col uses a com­pact bina­ry rep­re­sen­ta­tion of the data and tails the mes­sages with a cyclic redun­dan­cy check­sum (CRC) to check for errors and ensure data reli­a­bil­i­ty. A Mod­bus RTU mes­sage must be trans­mit­ted con­tin­u­ous­ly and are seper­at­ed by inac­tive (silent) periods.

Mod­bus ASCII 
The Mod­bus ASCII for­mat is uti­lized for ser­i­al com­mu­ni­ca­tion and makes use of ASCII char­ac­ters for the com­mu­ni­ca­tion pro­to­col. The ASCII for­mat relies on lon­gi­tu­di­nal redun­dan­cy check (LRC) check­sum for error checking.

Mod­bus TCP/IP or Mod­bus TCP
This Mod­bus vari­ant is used for com­mu­ni­ca­tions over TCP/IP net­works and does not require a check­sum cal­cu­la­tion, as low­er lay­ers already pro­vide it.

Mod­bus over TCP/IP or Mod­bus over TCP or Mod­bus RTU/IP — This vari­ant encap­su­lates Mod­bus RTU for its use in TCP/IP/Ethernet networks.

Mod­bus over UDP — In rar­er cas­es Mod­bus RTU is used over UDP on IP net­works to save the over­head required for TCP. 

Modbus TCP/IP vs Modbus RTU over TCP vs Modbus RTU

Mod­bus RTU is meant for ser­i­al com­mu­ni­ca­tions (RS232 or RS485 are the most com­mon). Mes­sages begin with a Slave ID (one byte) and end with a CRC (two bytes). Mod­bus RTU over TCP refers to tak­ing the RTU mes­sage is encap­su­lat­ed for Ether­net com­mu­ni­ca­tion with­out actu­al­ly chang­ing the mes­sage itself. The Mod­bus RTU mes­sage is usu­al­ly sent through a ser­i­al port con­nec­tor and then con­vert­ed by an Ethernet/ mod­bus gateway.

In the Mod­bus TCP stan­dard a 6 byte MBAP head­er is added to the mes­sage and the two byte CRC is removed. Alter­na­tive­ly, there are also gate­ways that con­vert Mod­bus RTU into a Mod­bus TCP mes­sages by chang­ing the mes­sage bytes.

The biggest advan­tage of Mod­bus TCP/IP over Mod­bus RTU is that you can use more than one polling device, unlike Mod­bus RTU which only allows for a sin­gle mas­ter device. Any addi­tion­al mas­ters would destroy the net­work com­mu­ni­ca­tions. With Eth­er­net, you also to deal with less ter­mi­na­tion and con­fig­u­ra­tion issues.

Nowa­days, the ver­sa­til­i­ty, speed and scal­a­bil­i­ty of Eth­er­net net­works are usu­al­ly pre­ferred over ser­i­al, but some still pre­fer the sim­plic­i­ty, wiring and cost effi­cien­cy of Mod­bus RTUDepend­ing on the avail­able ports, slaves/servers usu­al­ly oper­ate with one or the oth­er protocol.

Modbus RTU vs Modbus ASCII

The two modes includ­ed in the stan­dard define how the mes­sage bytes are trans­mit­ted, and how the data is wrapped into the mes­sage and unwrapped again. It is not pos­si­ble to use both trans­mis­sion modes on one net­work. The trans­mis­sion mode can be select­ed togeth­er with oth­er para­me­ters of the ser­i­al com­mu­ni­ca­tion port, although there are some devices that do not allow to choose, as they have a fixed trans­mis­sion mode, such as some PLCs and fre­quen­cy invert­ers using Mod­bus RTU by default.

Modbus vs DNP3

Mod­bus is an appli­ca­tion lay­er pro­to­col, where­as DNP3 con­sists of both an appli­ca­tion and data link lay­er. Anoth­er dif­fer­ence is that DNP3 also sup­ports unso­licit­ed mes­sag­ing. This means that RTUs can send updates when a change of sta­tus hap­pens, with­out wait­ing to be polled by the master.

Both pro­to­cols can be used over var­i­ous media, such as RS-232, RS-485, and TCP/IP.
While Mod­bus has a spe­cif­ic vari­ant for TCP/IP com­munca­tion, DNP3 needs to be wrapped with­in TCP/IP.

Since you can send more data in small­er pack­ets and unlike Mod­bus, it is an event-dri­ven pro­to­col, mean­ing that net­work devices are able to trans­mit unso­licit­ed respons­es and con­ti­nu­ity is not required, using DNP3 can save lots of band­width. Fur­ther­more, DNP3 is high­ly stan­dard­ized and pro­vides high com­pat­i­bil­i­ty and inter­op­er­abil­i­ty between devices from many dif­fer­ent vendors.

Still, some pre­fer Mod­bus for its sim­plic­i­ty and the high num­ber of devices that sup­port the pro­to­col. So, both Mod­bus and DNP3 can be imple­ment­ed in func­tion­al and effi­cient SCADA sys­tems, mak­ing it strong­ly depen­dent on the project network.

How it Works

Each device on the Mod­bus net­work has a unique address. Any device can send Mod­bus com­mands, but usu­al­ly only a mas­ter device is allowed to do so. Every Mod­bus com­mand con­tains the address of the device to which the com­mand is being sent. With the excep­tion of the spe­cial “broad­cast” mode, all devices in a Mod­bus net­work receive the frame but only the recip­i­ent exe­cutes it. Every mes­sage fur­ther includes redun­dant infor­ma­tion to ensure data integri­ty on recep­tion. Basic Mod­bus com­mands can be used to con­trol RTUs, in order to mod­i­fy the val­ue of one of its reg­is­ters or to request the val­ues of these reg­is­ters.

The Mod­bus pro­to­col is sup­port­ed by a large num­ber of modems, some of which have been specif­i­cal­ly designed for this pro­to­col. There are imple­men­ta­tions for wired, wire­less, SMS or GPRS con­nec­tion. Most of the prob­lems encoun­tered with Mod­bus are relat­ed to laten­cy and synchronization.

Modbus over Ethernet vs RS-232 vs RS-485

It is impor­tant not to con­fuse com­mu­ni­ca­tion pro­to­cols with stan­dards for elec­tri­cal char­ac­ter­is­tics of the phys­i­cal com­mu­ni­ca­tion media. Some pro­to­cols require a spe­cif­ic phys­i­cal stan­dard as in the case of IEC 61850 requir­ing Eth­er­net. Usu­al­ly in these cas­es, the phys­i­cal stan­dard goes hand in hand with the pro­to­col and can­not be changed. Dif­fer­ent com­mu­ni­ca­tion media are used depend­ing on project needs. The stan­dards’ main dif­fer­ences are the com­mu­ni­ca­tion speeds, the max­i­mum num­ber of con­nect­ed devices and the phys­i­cal dis­tance between con­nect­ed nodes.

MODBUS, on the oth­er hand, does not spec­i­fy the phys­i­cal lay­er, and can thus be used with sev­er­al phys­i­cal lay­er standards:

RS-232
The RS-232 (Rec­om­mend­ed Stan­dard 232) or also known EIA-232 (Elec­tron­ic Indus­tries Alliance-232) stan­dard is used only in point-to-point com­mu­ni­ca­tions, i.e. it only sup­ports com­mu­ni­ca­tions between two devices, which in the case of the Mod­bus pro­to­col would be a mas­ter and a slave device. The max­i­mum speed of RS-232 is around 115Kbp/s with a max­i­mum dis­tance between net­work devices of about 30m.

RS-422, or also TIA/EIA-422, was intend­ed to replace the old­er RS-232C stan­dard with a stan­dard that used dif­fer­en­tial sig­nalling to pro­vide high­er speeds, longer cable lengths and less noise. At short dis­tances, data trans­mis­sion rates can reach up to 10 Mbit/s. At low­er rates, data can be send through cables with a length of up to 1,500 meters.

RS-485
The RS-485 (Rec­om­men­dad Stan­dard-485) or EIA-485 (Elec­tron­ic Indus­tries Alliance-485) stan­dard is one of the most wide­ly used stan­dards for ser­i­al com­mu­ni­ca­tion with Mod­bus. The main dif­fer­ence with RS-232 is that it allows more than two devices on the net­work, enabling to have sev­er­al Mod­bus slaves. It achieves rates of up to 12Mbps and in rar­er cas­es up to 50Mbps, while the max­i­mum dis­tance with­in the net­work is 1200m, and the max­i­mum num­ber of devices on the net­work is 32.

Eth­er­net
Depend­ing on the vari­a­tion used, tran­simis­sion speeds with Eth­er­net range from 100Mbps and up to 10Gbps, while max­i­mum dis­tance can vary from 100m to 200m depend­ing on project con­di­tions and the type of cable used. In some cas­es, it is pos­si­ble to use fiber optic net­works, which enable longer dis­tances and high­er com­mu­ni­ca­tion rates, as well as wire­less communication.

Any ques­tions about this?
Ask us!

    I have read and accept the Pri­va­cy Pol­i­cy*

    Communication Protocols

    IEC 60870–5 is a pro­to­col stan­dard for tele­con­trol, telepro­tec­tion, and oth­er telecom­mu­ni­ca­tion func­tions for elec­tric pow­er systems.

    IEC 60870–5‑104 (short IEC104) is a com­pan­ion stan­dard defin­ing how to extend the IEC 60870–5‑101 pro­to­col to gain net­work access using stan­dard trans­port profiles.

    DLMS/COSEM (or IEC 62056) is the main glob­al stan­dard for smart ener­gy meter­ing, con­trol and man­age­ment. It includes spec­i­fi­ca­tions for media-spe­cif­ic com­mu­ni­ca­tion pro­files, an object-ori­ent­ed data mod­el and an appli­ca­tion lay­er protocol.

    Mod­bus is a com­mu­ni­ca­tions pro­to­col based on master/slave (RTU) or client/server (TCP/IP) archi­tec­tures that can oper­ate on the 1st, 2nd, 7th lev­el of the OSI Model.

    Orig­i­nal­ly designed in 1979 by Mod­i­con for its range of PLCs, it is now a de fac­to stan­dard com­mu­ni­ca­tions pro­to­col in the indus­try, becom­ming the most wide­ly avail­able pro­to­col for the con­nec­tion of indus­tri­al elec­tron­ic devices.

    Dis­trib­uted Net­work Pro­to­col 3 (DNP3) is a set of com­mu­ni­ca­tions pro­to­cols used between com­po­nents for automa­tion sys­tems in elec­tric, indus­tri­al and water sectors.

    It is a key pro­to­col in SCADA sys­tems, where it is pri­mar­i­ly used for com­mu­ni­ca­tions between a mas­ter sta­tion and RTUs or IEDs.

    ICCP (Inter-Con­trol Cen­ter Com­mu­ni­ca­tions Pro­to­col) is a stan­dard pro­to­col for com­mu­ni­ca­tions between con­trol cen­ters, which is part of the IEC 60870–6 stan­dard under the name of TASE.2 Tele­con­trol Appli­ca­tion Ser­vice Ele­ment 2.

    It is being used around the world to exchange data over wide area net­works (WANs) between grid oper­a­tors, util­i­ties, vir­tu­al pow­er plants, region­al con­trol cen­ters and oth­er generators.

    PROFIBUS (Process Field Bus) is an open stan­dard for field­bus com­mu­ni­ca­tions in indus­tri­al automa­tion sys­tems that was first pro­mot­ed in Ger­many in 1989.

    The now most com­mon­ly found “Profibus DP” pro­vides sim­ple com­mu­ni­ca­tions between Profibus mas­ters and their remote I/O slaves. 

    all entries sort­ed aplhabetically

    A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

    A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

    Modbus & iGrid

    We have col­lect­ed, con­vert­ed and trans­ferred data using sev­er­al ver­sions of the Mod­bus pro­to­col in projects all over the world in many kinds of projects. All of our sys­tems are able to com­mu­ni­cate with and con­vert the pro­to­col accord­ing to spe­cif­ic project needs.

    The Slimmest Gateway

    The iGWlite comes with 1 Eth­er­net, 1 RS485/RS422 and an option­al RS-232 port (cop­per or fiber) or a 2G/3G/4G mode tak­ing lit­tle space on a DIN-Rail, but still employ­ing the full iGrid pro­to­col stack.

    iControl SCADA

    High-per­for­mance SCADA for the visu­al­iza­tion and con­trol of sub­sta­tion data. It is able to run either in client/server or stand­alone modes, pro­vid­ing advanced func­tion­al­i­ties such as hot-stand­by redun­dan­cy, auto­mat­ic line col­or­ing, events noti­fi­ca­tion (via e‑mail and sms), SQL log­ging, and reports generation.

    iRTU – With I/Os for Direct Data Acquisition 

    Com­pact and scal­able bay con­troller which can act as IEC 61850 client or serv­er, fea­tur­ing con­fig­urable I/O boards for direct data acqui­si­tion, high-pre­ci­sion time­stamp­ing and an option­al Eth­er­net switch for addi­tion­al Eth­er­net ports.

    iGW‑S Substation Gateway

    Pow­er­ful and reli­able sub­sta­tion gate­way, able to run either in stand­alone or redun­dant modes, with an embed­ded Eth­er­net switch (4 ports) and IEC 61850 client and serv­er capabilities.

    iRTUe – Remote I/O Extensions 

    iGWs, iRTUs and third par­ty mas­ter units can be freely extend­ed by con­nect­ing one or sev­er­al iRTUe.

    They are IEC 61850 (GOOSE) com­pli­ant and come in many con­fig­u­ra­tions such as 48 DI, 16 relays, 16 AI, 24 DI + 8 relays, 24 DI + 8 AI or 8 relays + 8 AI.

    iGW-VM – unlimited control

    The freely scal­able iGW-VM sup­ports all archi­tec­tures using Win­dows or Lin­ux, act­ing as a sub­sta­tion gate­way, bay con­troller, RTU or com­mu­ni­ca­tion front-end for SCADA sys­tems. The iGW-VM is thus the per­fect soft­ware choice for projects with a predetermined/preferred hard­ware or a large grid to cov­er (high num­ber of datapoints).

    iGrid Solutions and Applications

    Automation with IEC 61850 

    The IEC 61850 stan­dard is enabling new opor­tu­ni­ties for ven­dor inter­op­er­abil­i­ty and advanced sub­sta­tion automa­tion. Find out how you can take advan­tage of IEC 61850 with easy-to-use and adapt­able solu­tions for a sim­ple migra­tion or retrofit.

    HV Substation Automation

    Pow­er­ful sub­sta­tion automa­tion sys­tems often han­dle numer­ous com­mu­ni­ca­tion pro­to­cols and media with­in one net­work, which can result in expen­sive and com­plex projects.  Avoid these prob­lems with inter­op­er­a­ble tech­nol­o­gy and smart con­fig­u­ra­tion tools.

    MV Distribution Grid Automation

    It is often dif­fi­cult to find the exact solu­tion you need in a MV appli­ca­tion, lead­ing to high­er costs than nec­es­sary. With our scal­able and adapt­able solu­tions you will be able to only pay for what you real­ly need, with­out com­prim­is­ing on qual­i­ty or security.

    Photovoltaic Power Station

    Using an open and scal­able SCADA sys­tem to mon­i­tor and con­trol a PV plant comes with many ben­e­fits on sev­er­al lev­els. Find out how advanced com­mu­ni­ca­tion tech­nol­o­gy affects PV oper­a­tion, main­te­nance, sys­tem design, invest­ment secu­ri­ty, profits…

    Protocol Conversion

    As com­mu­ni­ca­tion net­works grow in com­plex­i­ty, “plug and play” promis­es become hard­er to keep. Inter­op­er­a­ble pro­to­col con­vert­ers and soft­ware solu­tions with state-of-the-art capa­bil­i­ties and funci­tonal­i­ties can be the bridge to all the func­tions and flex­i­bil­i­ty your net­work needs.

    Generation Dispatch Control Center

    With a gen­er­a­tion dis­patch enter you can auto­mat­i­cal­ly con­trol the gen­er­a­tion of all pow­er plants and make direct bids for ancil­lary ser­vices on one plat­form. Check out the most effi­cient com­mu­ni­ca­tion path between gen­er­a­tion sites, grid oper­a­tors and the pow­er market.

    Smart Metering

    A sin­gle device that col­lects, process­es, trans­fers smart meter data and load curves from sev­er­al meters in dif­fer­ent pro­to­cols via ser­i­al or Eth­er­net, whilst pro­vid­ing advanced automa­tion func­tions? Adapt­able designs and a full com­mu­ni­ca­tion pro­to­col suite make it possible. 

     

    Switchgear & Transformers

    Some­times you have pre­ferred gear for a project or it has already been installed, but it is lack­ing the com­mu­ni­ca­tion capa­bil­i­ties to pro­vide the automa­tion func­tions you are look­ing for. With our soft­ware core iGComms any device can be as smart as you want it to be.