https://www.rtautomation.com/technologies/modbus/ | BingShi

https://www.rtautomation.com/technologies/modbus/

The Modbus communications protocol is the networking granddaddy of the industry. Modbus has stood the test of time and is still being used in a wide range of applications, including industrial automation, process control, building automation, transportation, energy, and remote monitoring.

You can find virtually every type of sensor and controller device incorporating Modbus networking, including programmable logic controllers (PLCs), process controllers, process instruments, process sensors, PID controllers, motor drives, energy meters, Supervisory Control and Data Acquisition (SCADA) systems, programmable automation controllers (PACs), discrete sensors, valves, and many other embedded devices.

In simple terms, Modbus is a method used for transmitting data over serial lines between electronic devices. Originally intended for communications between programmable logic controllers (PLCs) and computers, it has become a de facto standard communication protocol for connecting a wide range of industrial electronic devices.

Modbus is an extremely compact and flexible protocol that continues to prove it can be adapted for use in a wide range of applications and media. It is popular for remote applications that communicate over almost any means, including wired and cellular telephone, licensed and unlicensed radios, and satellite.

Modbus resources

Want to learn more about Modbus?

Subscribe to our Automation Education email series to learn the ins and outs of Modbus and the top industrial protocols in a byte-size weekly format!

History of Modbus

The Modbus serial communication protocol was developed by Modicon and published by the company in 1979 for use with its programmable logic controllers (PLCs). The early roots of Modicon started in 1968 with a core group of engineers led by Dick Morley that invented the first programmable logic controller.

Modbus is an open standard, meaning that manufacturers can build it into their equipment without having to pay royalties. It is the most pervasive communications protocol in industrial automation and is the most commonly available means of connecting industrial electronic devices.

Modbus introduced the concept of data on the factory floor. Modbus made it possible to connect an entire group of devices using only two wires on the controller. That alone saved a massive investment in wire, labor and installation time. Instead of miles and miles of wire connecting hundreds of devices, a simple two-wire pair could be daisy-chained from one device to the next to the next. It was revolutionary for its time.

Modbus has found its way into hundreds of thousands—if not millions—of devices. You can find it in everything from valve controllers, to motor drives, to HMIs, to water filtration systems. It would be difficult indeed to name a product category in Industrial or Building Automation that doesn’t use Modbus.

Why Modbus has Flourished

Why did Modbus have such an impact on the Industrial Automation industry that it still survives to this day as one of the leading industrial networks of the 21st century? Here are the three primary keys to its success:

  1. Modbus is an Open Standard: Modicon did not keep the standard proprietary. They released it as a non-proprietary standard and welcomed developers, even competitors, to implement it. They rightly assumed that it would be best for everyone, including them if Modbus became successful in the marketplace. Because of this thinking, Modbus became the first widely accepted Fieldbus standard.
  2. Modbus uses Standard Transports: The transport layer for Modbus RTU commands is also simple to understand. Modbus RTU uses RS232, RS422, and RS485. Modbus TCP/IP uses Ethernet.
  3. Modbus uses a Simple Protocol: Modbus is very easy to understand. Its primary purpose is to simply move data between an RTU Master device (a Client in Modbus TCP) and an RTU Slave device (a Server in Modbus TCP). There are only two kinds of data to move, registers and coils. Registers are 16-bit unsigned integers. Coils are single bits. The simplicity of Modbus has also led to many companies expanding the message structure, data representation, and transports.

Another reason Modbus was so successful was the fact that it could be so readily understood by non-programmers. Simplicity has led to an incredible amount of activity and propagation of Modbus into many different industries around the world. There is probably no product category in the last thirty years that hasn’t had an offering without Modbus.

Modbus Protocol Message Structure

The standard structure of a Modbus request and a Modbus response is identical for all forms of Modbus messages. That structure begins with a byte indicating the function the Slave should perform and ends with the last byte of data in the message.

The general components of a Modbus message follow:

Function Code (FC)The Function Code identifies the request to the Modbus Slave. There are a large number of possible message requests, but about eight that are commonly used. These are the function codes that are detailed in this chapter.
Starting AddressThe Starting Address is the index into the data area in the Modbus device. If the function code targets coils, this field specifies the index the coils (bits) of the coil address space. If the function applies to registers, this field specifies the index into the registers for that part of the address space.

Note: Modbus address spaces are one based—the first register or coil is one. The Modbus protocol is zero-based. The first register or coil is zero. The address on the wire is always one less than the address in the Modbus data request.

Bit LengthThe number of bits to read or write.
Word CountThe number of registers to read or write.
Byte CountThe number of data bytes of data included in the message request or response.
Response CodeThis byte indicates the successful completion of the message request. It is identical to the original message request.
Exception Response (FC)An exception response is indicated by combining the Response Code of the original Modbus Function Request with 80 hexadecimal. For example, a Modbus exception response to Function Code 3 is 83 hexadecimal. A single data byte value with the Modbus Error Code always follows the exception response byte.

 

Like what you’re reading?

Subscribe to our Automation Education email series to learn the ins and outs of the top industrial protocols in a byte-size weekly format!

Modbus Data Representation

Like everything else about Modbus, the data representation is simple. There are only two data types in Modbus: coils and registers.

  • Coils: Coils are simply single bits. The bits can be ON (1) or they can be OFF (0). Some coils represent inputs, meaning they contain the status of some physical discrete input. Or they represent outputs, meaning that they hold the state of some physical discrete output signal.
  • Registers: Registers are simply 16-bit unsigned register data. Registers can have a value from 0 to 65535 (0 to FFFF hexadecimal). There is no representation for negative values, no representation for values greater than 65535, and no representation for real data like 200.125. Any application can organize and treat register data in any way it may want, but there is no way for any other Modbus device to automatically know what that representation is. A Modbus application that reads registers from a Modbus Slave device must have some prior knowledge of how particular registers are treated to process them correctly.

Modbus Transport Layers

How we move a message from one station to another is called the Transport Layer. Now, the Transport Layer can be complicated. You can use any transport you want. The Modbus message sequence is a Modbus message sequence regardless of whether you send it on Ethernet, RS232, or RS485. The transport is simply the mechanism you use to move the message from the sender to the receiver.

There are several standard transports used to move Modbus protocol messages: RS232, RS485, and Ethernet. You can use others, but these are the common ones.

RS232

RS232 stands for Recommend Standard number 232. This is the old serial port that we used to find on computers several (okay, more than several) years ago. The full RS-232C standard specifies a 25-pin “D” connector. Now, if we find a serial connector, it uses the 9-pin D type connectors often referenced as a DB9.

RS485

RS485 is 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 can 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.

Ethernet

Modbus communications over Ethernet is known as Modbus TCP. Modbus took a huge step forward when it began using Ethernet as a transport protocol. Now with the increased speed of Ethernet, there is much more bandwidth for sending many more messages. You can connect thousands of devices in a Modbus TCP network, not just the 32 devices like in RS485, and you can also support multiple Clients, not just a single Client.

Modbus Certifications

Most trade organizations specify a protocol test that must be successfully executed to get a certification statement or logo that a device vendor can use to indicate that the device conforms to the specification of the technology. For many years, there was no conformance test for Modbus products. A developer would create something, test it in some fashion, and ship it. It was left to the user to figure out what worked and what didn’t work.

In the time since the Modbus Organization has remedied this problem. They not only established a test procedure, but they also contracted with the University of Michigan to implement it. You now have two options for certification of your Modbus Slave device or Modbus TCP Server device.

  1. You can self-certify. That means that you download the test and execute it yourself. You pledge that your products meet the minimum functionality of a Modbus device as specified by the test.
  2. You can purchase testing from the Modbus Organization. The test lab at the University of Michigan will perform the test for you and validate your device. That, of course, is going to cost you some cash and some time. But you do get a second set of eyes and third-party testing.

Another thing to note about testing Modbus is that only your Slave or Server device can be tested. There is no test for Master or Client devices.

The reasoning behind this is because it is much more difficult to validate the operation of the Master side. Besides that, only Modbus TCP Server devices now can be tested. The Modbus Conformance test is designed for Modbus TCP Ethernet devices, not Modbus Serial Devices.

Modbus-IDA logo

Modbus Security

If you are new to Modbus or new to security, you already know everything there is to know about Modbus security: NOTHING. There is no security in Modbus, Modbus RTU, or Modbus TCP. It doesn’t exist.

Many people think that because they have their Modbus controller behind a firewall they’re protected. Yes, your controller is not on the Internet, but that doesn’t mean you’re protected. All that does is move your vulnerability up one level. Now, any server you have on the other side of the firewall that’s authorized to access the controller through the firewall is the vulnerability.

Modbus was not built for security. It has no passwords, no authorizations, no facility to pass certificates or anything else that would be required if you were building it today. Strangely enough, Modbus RTU is seeing continued use due to security concerns.

The Difference Between Modbus RTU and Modbus TCP

The most basic difference between Modbus RTU and Modbus TCP (Also known as Modbus IP and Modbus TCP/IP) is that Modbus TCP runs on an Ethernet physical layer and Modbus RTU is a serial level protocol. Modbus TCP also uses a 6-byte header to allow routing and removes the CRC.

A Modbus RTU Master is a single Master bus. It sends a message to an RTU slave device and gets an answer. Modbus RTU is limited to a single master. Only one set of signals can be on the RS485 link at any one time. Either the single RTU Master is transmitting or one of the RTU Client devices is transmitting.

With the introduction of Modbus TCP, this limit was removed. With Modbus TCP, controllers can much more efficiently use the bandwidth on Ethernet to be the Master to hundreds of Modbus TCP devices. Where RS485 had an electrical limitation of 32 devices, Ethernet is unlimited. Operating RAM is the only practical limitation. With Modbus TCP, there is the ability for a network designer to use multiple Clients/Masters if they so choose. Modbus TCP allows for multiple Clients.

With Modbus TCP, you need to get network switches involved. With Modbus RTU (serial), you can just daisy chain all the devices together. Devices with old 8-bit processors and a tiny bit of memory can easily do Modbus serial but you’ll need a more expensive platform to do Ethernet.

The Difference Between Modbus RTU and Modbus/ASCII

There are two basic transmission modes found in serial Modbus connections, ASCII and RTU. These transmission modes determine the way in which the Modbus messages are coded. In ASCII format, the messages are readable, whereas in RTU the messages are in binary coding and cannot be read while monitoring. The trade-off is that the RTU messages are a smaller size, which allows for more data exchange in the same time span. One should be aware that all nodes within one Modbus network must be of the same transmission mode, meaning Modbus ASCII cannot communicate with Modbus RTU and vice versa.

In Modbus/ASCII, messages are encoded with hexadecimal value, represented with comprehensive ASCII characters. The characters used for this encoding are 0…9 and A…F. For every byte of information, two communication-bytes are used because every communication-byte can only define 4 bits in the hexadecimal system. Modbus RTU, however, exchanges data in a binary format where each byte of data is coded in one communication-byte.

The Modbus messages on a serial connection are not broadcast in plain format. They are constructed in a way that allows receivers an easy way to detect the beginning and end of a message. The characters start and end a frame when in ASCII mode. To flag the start of a message, a colon ‘:’ is used, and each message is ended with a CR/LF combination. Modbus RTU uses a different method. In RTU, framing is constructed by measuring gaps of silence on the communication line. Before each message, there must be a minimum gap of 3.5 characters. To prepare for new messages, the receiver clears the buffer when a gap of 1.5 characters is detected. One of the main differences between Modbus/ASCII and Modbus RTU is that ASCII allows gaps between the bytes of a message with a maximum length of 1 second. With Modbus RTU, continuous streams of messages must be sent.

Modbus Ethernet or Modbus Over Ethernet

While Modbus TCP/IP is a fully formed technical specification the vast adoption of Modbus, the loose certification standard and early movers to Ethernet led to a number of non-standard implementations that are still present in the market. If you see Modbus Ethernet or Modbus over Ethernet listed on a product it may warrant some additional verification. There are still several products that feature standard Modbus RTU packets encapsulated inside of a TCP/IP packet. These devices will not work in typical Modbus TCP/IP implementations.

Everything You Wish You Knew About Industrial Communication, Delivered Right to Your Inbox

Ready to take your automation protocol knowledge to the next level? Subscribe to the Automation Education Email Series to learn the ins and outs of the top industrial protocols in a byte-size weekly format! Sign up now!

更多文章...
https://www.infineon.com/dgdl/Infineon-Peripheral+-+EtherCAT+Slave+Controller+(ECAT)-TR-v01_00-EN.pdf?fileId=5546d4625696ed7601569c8617fb08ba https://www.beckhoff.com/en-en/products/i-o/ethercat-terminals/ https://de.wikipedia.org/wiki/EtherCAT https://wilo.com/id/en/Solutions-Finder/Connectivity/Building-automation/CANopen/ https://products.pulspower.com/en/power-supplies-with-ethercat
评论
官方技术支持 Odoo, 此 #1 开源电商.
Copyright © bingshi