Table of Contents. Modbus

Transcription

1

2 Table of Contents Modbus...1 Modbus Protocol...1 Transmission Modes...2 Connection Types...2 Master / Slave Functionality...2 Methods of Communication...3 Protocol versions...3 Protocol Details...3 Data Encoding...3 Data Model...3 Addressing...4 Function Codes...4 Compatibility between devices...5 Master / Slave Functionality...6 Multiple Network Support...6 Protocol Versions (RTU, ASCII)...7 Connection Methods...8 Modbus Implementation...8 Modbus Master...9 Modbus Group...11 Modbus Slave...12 Port...14 i

3 The MODBUS protocol was developed by Modicon in 1978 as a simple way for transferring control data between controllers and sensors using an RS232 port. The protocol describes an industrial communications and distributed control system developed to integrate PLC s, computers, terminals, and other monitoring, sensing, and control devices. Since it's creation it has become a de facto industry standard used by multiple control and sensor companies. Today Modbus protocol is the single, most supported protocol amongst automation devices. Most devices, being able to communicate serial, talk Modbus. Modbus is now also the most common industrial Ethernet protocol. A newly released study by ARC Advisory Group, the leading analyst firm covering automation and enterprise software, shows Modbus TCP/IP as the world's leading industrial Ethernet protocol, in terms of units shipped in Ethernet port 502 is now standard for the Modbus TCP/IP protocol. Modbus is the only real open Industrial Internet protocol owned by the Industrial community. The Modbus protocol is a trademark of Schneider Electric. However, Schneider Electric made the protocol specification and its implementation available for free to anyone who wishes to implement a Modbus or Modbus TCP/IP device. Although originally designed by Modicon, Modbus is now an open standard supported by an independent, member driven organization which can be found at Modbus IDA The following description gives an overview of the protocol and some of the points to consider when connecting dissimilar equipment using Modbus. Modbus Protocol The Modbus protocol describes an industrial communications and distributed control system developed by Gould Modicon to integrate PLC s, computers, terminals, and other monitoring, sensing, and control devices. Although originally designed by Gould Modicon, Modbus is now an open standard supported by an independent, member driven organization which can be found at Modbus IDA Certain characteristics of the protocol are fixed, such as the frame format, frame sequences, handling of communications errors and exception conditions, and the functions performed. Other characteristics are user selectable. These include a choice of transmission media, baud rate, character parity, number of stop bits, and the transmission modes, (ASCII or RTU). The user selected parameters are Modbus 1

4 set, (hardwired or programmed), at each station. These parameters cannot be changed while the system is running. Transmission Modes The mode of transmission is the structure of the individual units of information within a message, and the numbering system used to transmit the data. Two modes of transmission are available for use in a MODBUS system. Both modes provide the same capabilities for communicating with PLC slaves; the mode is selected depending on the equipment used as a MODBUS Master. One mode must be used per MODBUS system; mixing of modes is not allowed. The modes are ASCII (American Standard Code for Information Interchange), and RTU, (Remote Terminal Unit.). ASCII printable characters are easy to view when troubleshooting and this mode is suited to computer masters programmed in a high level language, such as FORTRAN, as well as PLC masters. RTU is suited to computer masters programmed in a machine language, as well as PLC masters. In the RTU mode, data is sent in 8 bit binary characters. In the ASCII mode, each RTU character is first divided into two 4 bit parts, (high order and low order), and then represented by the hexadecimal equivalent. The ASCII characters representing the hexadecimal characters are used to construct the message. The ASCII mode uses twice as many characters as the RTU mode, but decoding handling the ASCII data is easier. Additionally, in the RTU mode, message characters must be transmitted in a continuous stream. In the ASCII mode, breaks of up to one second can occur between characters to allow for a relatively slower master. Connection Types Hexatec Saturn supports 3 different methods of connecting to Modbus communication devices: Serial Modbus TCP Remote Serial connections use a dedicated serial cable connection between a master and one or more slave devices. A specific standard is used such as RS232 and all connected devices should support and be configured for the same standard. Modbus TCP use a network connection for communications. This can either be dedicated, or shared with other network traffic. Modbus TCP is the world's leading industrial Ethernet protocol in terms of the number of units shipped. Remote connections use modem technology normally connected to the telephone system to access remote devices. Master / Slave Functionality Modbus Modbus is a Master / slave protocol. A number of devices may be interconnected using the protocol, but only one device can be the master. Communications is always instigated and controlled by the master device. All other devices are connected as slaves and will only communicate in response to requests or commands from the single master. The protocol provides for one master device and up to 247 slave devices on a common line. Each device is assigned an address to distinguish it from all other connected devices. Transmission Modes 2

5 This simple structure ensures the protocol overhead is kept to a minimum. Device addressing is simple. Methods of Communication The original Modbus protocol was designed for use with serial communications devices using RS 232 or RS 485. RS 232 is normally restricted to single slave, short distance communications, whereas RS 485 is better when distance and / or multiple slaves are required. Modbus Plus was introduced by Modicon as a global fieldbus network to enable faster (2 MBit/s) communications between multiple (up to 32) devices. A token passing topology is used over an RS485 interconnection. Modbus TCP/IP takes the original protocol and structures it for use over Ethernet using the TCP/IP protocols. This is done in such a way as to minimise implementation changes to software developers and has resulted in a large number of devices quickly supporting the protocol. Modbus TCP/IP allows concurrent master / slave operation. For simple non networked implementations, the original protocol is fine. For larger, distributed systems, especially where Ethernet may already be installed, Modbus TCP/IP has many advantages. Be aware however, that Modbus TCP/IP installations will only be as good / reliable as the underlying network! Protocol versions Modbus devices can communicate using either of two versions of the Modbus protocol, RTU (Remote Terminal Unit.) or ASCII (American Standard Code for Information Interchange). RTU is a binary format requiring the least number of characters for transmission, whereas ASCII uses only text readable characters requiring more per message and is thus slower. Some devices will only support one or the other. All connected devices should be configured to the same version Modbus TCP/IP does not have the ASCII option. Some proprietary 'versions' define additional data types / uses such as Enron / Daniels which define methods of passing 32 bit integer and floating point values (see Compatibility between devices below). Note that these are still RTU or ASCII based however. Protocol Details Data Encoding MODBUS uses a big Endian representation for addresses and data items. This means that when a numerical quantity larger than a single byte is transmitted, the most significant byte is sent first (see Compatibility between devices below). Data Model Modbus MODBUS bases its data model on a series of tables that have distinguishing characteristics. The four primary tables are: Primary tables Type of access Comments Methods of Communication 3

6 Object type Discretes Input Single bit Read Only This type of data can be provided by an I/O system. Coils Single bit Read Write This type of data can be alterable by an application program. Input Registers Holding Registers 16 bit word 16 bit word Read Only Read Write This type of data can be provided by an I/O system This type of data can be alterable by an application program. The distinctions between inputs and outputs, and between bit addressable and word addressable data items, do not imply any application behaviour. It is perfectly acceptable, and very common, to regard all four tables as overlaying one another, if this is the most natural interpretation on the target machine in question. For each of the primary tables, the protocol allows individual selection of data items, and the operations of read or write of those items are designed to span multiple consecutive data items up to a data size limit which is dependent on the transaction function code. It s obvious that all the data handled via MODBUS (bits, registers) must be located in device application memory. But physical address in memory should not be confused with data reference. The only requirement is to link data reference with physical address. MODBUS logical reference number, which are used in MODBUS functions, are unsigned integer indices starting at zero. It is worth noting at this point that only single bit and 16 bit words are defined object types for data access (ASCII characters are also included in diagnostic messages). How the words are interpreted / combined is not defined in the protocol definition (see Compatibility between devices below). Addressing Modbus can address separate addresses. Function Codes Public Function Codes Modbus Are well defined function codes guaranteed to be unique validated by the modbus.org community publicly documented have available conformance test are documented in the MB IETF RFC includes both defined public assigned function codes as well as unassigned function codes reserved for future use. Addressing 4

7 User Defined Function Codes there are two ranges of user defined function codes, ie 65 to 72 and from 100 to 110 decimal. user can select and implement a function code without any approval from modbus.org there is no guarantee that the use of the selected function code will be unique if the user wants to re position the functionality as a public function code, he must initiate an RFC to introduce the change into the public category and to have a new public function code assigned. Reserved Function Codes Function Codes currently used by some companies for legacy products and that are not available for public use. Compatibility between devices Some implementations deviate and / or extend on the defined protocol. Examples include alternate byte / word ordering and other data types. This can lead to problems unless all interconnected master and slave devices support the variations. To guarantee communications between devices using Modbus, several checks should be made: 1. The devices all support the same protocol version in order to communicate at all! 2. The devices all support the Function Codes to be used. This often means limiting the use to a subset of the Public Function Codes. 3. Data encoding is compatible between master and slaves. This includes register data types and byte order as some devices may have differing uses from the standard. 4. Addressing ranges comply (number base differences can lead to confusion, for example start with 0 or 1 in setup / usage). Function Codes 5

8 Implementation Modbus is the most common protocol used for communicating with industrial hardware. It works by one 'Master' station, often a PC, requesting data from one or more 'slave' stations. Originally invented as a 'Serial Port' protocol, Modbus over Ethernet is fast becoming the new 'standard'. Hexatec software fully supports the Modbus protocol, over Ethernet and Serial connections, including Remote modems. It can also support both Master and Slave modes. This flexibility ensures it may be used with a wide range of Modbus communication equipment. Master / Slave Functionality Modbus is a Master / Slave protocol. A number of devices may be interconnected using the protocol, but only one device can be the master. Communication is always instigated and controlled by the master device. All other devices are connected as slaves and will only communicate in response to requests or commands from the single master. Slaves are each configured to have a unique address. Modbus TCP is a variant of the original standard and allows concurrent master / slave operation. Master Functionality The software issues Modbus commands in sequence on a per network basis and waits a predetermined time for a reply from the addressed slave device. If, for any reason, an incorrect or no response is returned, the process is repeated a set number of times. This ensures communications can be maintained even if interruptions, such as electrical noise, occur. Connection dependent settings that need to be defined: Serial Port. Port number and associated settings. ASCII / RTU selection. Modbus TCP. A network device (or IP address) and Port number (502 default). Remote (modem) connections. A TAPI device is selected and a number to dial included. ASCII / RTU selection. For device reads, Saturn supports: Coil Status Input Status Holding Registers Input Registers For device writes, the software uses Single Coil Writes for Boolean tags and Single Register Writes for analogue tags. Modbus does not support text or string operations. Some variation is possible in the way Register data is interpreted, so a number of options are included: Registers can be handles as: 2 Byte 2 Byte Signed 4 Byte 4 Byte Signed Modbus Implementation 6

9 4 Byte Float and options allow for byte and word order. In this way, special forms of Modbus, such as: Daniels, Enron, etc., are supported. Slave Functionality A choice of Serial Port or Network connection is available. If remote access via a modem is required, this should be connected via a Serial Port and configured separately. Settings are a subset of the equivalent Master options described above. Multiple Network Support The software supports multiple networks at the same time. Allowing data to be collected from Multiple networks concurrently, even if one is Serial and another Ethernet. The software can also work as a Modbus slave, which means that the PC can also aggregate data and make it available to another Modbus master system such as a central DCS. The diagram shows some of these possibilities. For example it is possible to: 1. Configure a PC running the software to be the master device to one or more networks of slave devices. Each slave network will use one of the three connection options described above. 2. Connect it to another Modbus master, as a Slave. This allows great flexibility in how various Modbus communicating devices may be connected. The configuration of each network is completely separate and there is no interaction. It is even possible to use the software as a protocol converter between dissimilar Modbus devices or between Modbus and other protocols. This flexibility offers great scope to the range of possibilities, when used for real world applications. Master / Slave Functionality 7

10 Protocol Versions (RTU, ASCII) Modbus devices can communicate using either of the two versions of the Modbus protocol, RTU or ASCII. RTU is a binary format requiring the least number of characters for transmission, whereas ASCII uses only text readable characters requiring more per message and is thus slower. Some devices will only support one or the other. All connected devices should be configured to the same protocol version. Modbus TCP does not use the ASCII option. Connection Methods Saturn X425 supports three different methods of connecting to Modbus communication devices: Serial connections use a dedicated serial cable connection between a master and one or more slave devices. A specific standard is used such as RS232 and all connected devices should support and be configured for the same standard. Modbus TCP uses a network connection for communications. This can either be dedicated, or shared with other network traffic. Modbus TCP is now the world's leading industrial Ethernet protocol in terms of the number of units shipped. Remote connections use modem technology normally connected to the telephone system to access remote devices. Protocol Versions (RTU, ASCII) 8

11 Master Modbus master configuration consists of this page, the Port property page when Serial Port is selected, the Group Modbus property page and the Group property page settings. Connection Modbus slave devices can be accessed in 3 different ways: Mode Serial Port the Port property page is available to configure the serial port to use for slave device access. Network access Modbus slave devices over the network. Remote use a modem to remote access slaves. For non network configuration, either ASCII or RTU can be used. See the slave details for which to use. Processing Connection Timeout: If set to non zero, retry if connection not established within this time in seconds. Message Timeout: Set a timeout in milliseconds. After issuing any Modbus requests, the server object will timeout and fail the request after this period of time. Fail after: Completely fail transaction after this number of retries. Inactivity Disconnect: On no activity, disconnect from slave. Modbus Master 9

12 Network The device name and port number should be set for the slave device. The device name could be a network name (mycomputer) or address ( ). The standard port for Modbus communications is 502. Remote Select a device and enter a telephone number to dial on the device when communications is required to slave devices. Modbus Master 10

13 Group Settings affect all tags included within the group. Refer to the documentation of the slave device for details on settings. Slave Address The slave address to communicate with for this group. Base Address The Base Address within the slave to use for data. The Base Address should be 1 or above. Read Type Set to the data type to use for read requests. Register Data Type Treat data as the type selected. Word and / or byte swapping is available should the slave device order data bytes differently. Modbus Group 11

14 Slave Tags can be optionally accessed by devices using the Modbus protocol. In order to do this, the Tags object has to be setup as a Modbus Slave. Individual Server objects can then be set to serve data to Modbus master devices by checking the Modbus Slave option on the Server property page. Note that to achieve communications between slaves and masters, it is necessary to use the same configuration settings for both. Connection Select the communications method the project will respond to as a Modbus slave. The choice is: Mode None Do not function as a Modbus Slave. Serial Port Respond to modbus requests on the selected serial port. The Mode and Serial Port options are available for configuration. Network Respond to Modbus requests made over the network. The Network Port option is available for configuration. For serial port use only. Select either ASCII or RTU. ASCII is a text readable version of Modbus, but requires more characters to be transmitted. Serial Port Select the serial port to use when the project is running which will be monitored for Modbus requests. The various port settings should also be set to agree with connected Modbus master device settings. Note that 8 Data bits should always be selected when working in RTU mode. Modbus Slave 12

15 Network Set the port number to monitor on the network for Modbus requests. The default port for the Modbus protocol is 502. Modbus Slave 13

16 Port The Port Property Page configures a single serial port. The port is used when either Modbus or Serial Port is selected on the Server property page. For general information on the Serial Port and its use, see Serial Port Overview. Port The serial port to be used (COM1:,COM2: etc) is selected by number. Thus for COM2: use 2. Baud rate The baud rate to communicate at. Select from the list or enter an alternative. Data Bits The number of data bits to be used in communication. Parity The format used when bytes are checked for parity errors. Stop Bits The number of stop bits used in communication. Port 14

17 Xon/Xoff Software Xon/Xoff handshaking is used. Rts/Cts Hardware Rts/Cts handshaking is used. Using this mode of handshaking will remove the ability to change the Rts line elsewhere. Dtr/Dsr Hardware Dtr/Dsr handshaking is used. Using this mode of handshaking will remove the ability to change the Dtr line elsewhere. Monitor Checking one or more of the Monitor options causes additional event log Information messages to be generated. This is useful when debugging port usage. These settings are not used when the Modbus protocol is used. Port 15