开放型MODBUS-TCP规范（英文版）
导读：
OPEN Modbus /TCP SPECIFICATION
Release 1.0, 29 March 1999
Andy Swales
Schneider Electric
[email protected]
Contents
Contents............ 2
1. Status of this specification...... 3
2. Overview........ 3
2.1 Connection-oriented.............. 3
2.2 Data encoding........ 4
2.3 Interpretation of reference numbers......... 4
2.4 Implied length philosophy.... 5
3. Conformance class summary... 5
3.1 Class 0...... 5
3.2 Class 1...... 5
3.3 Class 2...... 6
3.4 Machine/vendor/network specific functions....... 7
4. Protocol structure............. 7
5. Protocol reference by conformance class.................... 8
5.1 Class 0 commands detail............... 9
5.1.1 Read multiple registers (FC 3)................ 9
5.1.2 Write multiple registers (FC 16).............. 9
5.2 Class 1 commands detail............. 10
5.2.1 Read coils (FC 1).................. 10
5.2.2 Read input discretes (FC 2).............. 10
5.2.3 Read input registers (FC 4).............. 11
5.2.4 Write coil (FC 5) 11
5.2.5 Write single register (FC 6).................. 12
5.2.6 Read exception status (FC 7).................. 12
5.3 Class 2 commands detail............. 13
5.3.1 Force multiple coils (FC 15)..... 13
5.3.2 Read general reference (FC 20)..... 14
5.3.3 Write general reference (FC 21)..... 15
5.3.4 Mask write register (FC 22)..... 16
5.3.5 Read/write registers (FC 23)............ 16
5.3.6 Read FIFO queue (FC 24)..... 17
6. Exception codes................ 17
Appendices..... 19
A. Client and Server Implementation Guidance.......... 19
A.1 Client design.......... 19
A.2 Server design.......... 20
A.2.1 Multithreaded server... 20
A.2.2 Single-threaded server 21
A.3 Required and expected performance 22
B. Data Encoding for non-word data........................... 23
B.1 Bit numbers within a word...................... 23
B.2 Multi-word quantities..... 24
B.2.1 984 Data Types.................. 24
B.2.2 IEC-1131 data types 25
1. Status of this specification
Initial release 3 Sept 1997
Draft for public review.
Re-release 29 March 1999 at Revision 1.0.
No technical changes, clarifications only.
Added Appendices A and B in response to common implementation questions.
This specification of Modbus/TCP is being published by being publicly visible on the World Wide Web. It is intended for the benefit of developers wishing to use MODBUS/TCP as an interoperability standard in the field of industrial automation.
Since MODBUS and MODBUS/TCP are in reality ‘de-facto’ standards, in that many vendors and products implement it already, this specification primarily explains the specific encoding of MODBUS messages over the TCP communication protocol universally available on the Internet.
2. Overview
MODBUS/TCP is a variant of the MODBUS family of simple, vendor-neutral communication protocols intended for supervision and control of automation equipment. Specifically, it covers the use of MODBUS messaging in an ‘Intranet’ or ‘Internet’ environment using the TCP/IP protocols. The most common use of the protocols at this time are for Ethernet attachment of PLC’s, I/O modules, and ‘gateways’ to other simple field buses or I/O networks.
The MODBUS/TCP protocol is being published as a (‘de-facto’) automation standard. Since MODBUS is already widely known, there should be little information in this document which could not be obtained elsewhere. However, an attempt has been made to clarify which functions within MODBUS have value for interoperability of general automation equipment, and which parts are ‘baggage’ from the alternate use of MODBUS as a programming protocol for PLC’s.
This is done below by grouping supported message types into ‘conformance classes’ which differentiate between those messages which are universally implemented and those which are optional, particularly those specific to devices such as PLC’s.
2.1 Connection-oriented
In MODBUS, data transactions are traditionally stateless, making them highly resistant to disruption from noise and yet requiring minimal recovery information to be maintained at either end.
Programming operations, on the other hand, expect a connection-oriented approach. This was achieved on the simpler variants by an exclusive ‘login’ token, and on the Modbus Plus variant by explicit ‘Program Path’ capabilities which maintained a duplex association until explicitly broken down.
MODBUS/TCP handles both situations. A connection is easily recognized at the protocol level, and a single connection may carry multiple independent transactions. In addition, TCP allows a very large number of concurrent connections, so in most cases it is the choice of the initiator whether to reconnect as required or re-use a long-lived connection.
Developers familiar with MODBUS may wonder why the connection-oriented TCP protocol is used rather than the datagram-oriented UDP. The main reason is to keep control of an individual ‘transaction’ by enclosing it in a connection which can be identified, supervised, and canceled without requiring specific action on the part of the client and server applications. This gives the mechanism a wide tolerance to network performance changes, and allows security features such as firewalls and proxies to be easily added.
Similar reasoning was used by the original developers of the World Wide Web when they chose to implement a minimal Web query as a single transaction using TCP on well-known port 80.
2.2 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. So for example
16 - bits 0x1234 would be 0x12 0x34
32 - bits 0x12345678L would be 0x12 0x34 0x56 0x78
2.3 Interpretation of reference numbers
MODBUS bases its data model on a series of tables which have distinguishing characteristics. The four primary tables are
input discretes single bit, provided by an I/O system, read-only
output discretes single bit, alterable by an application program, read-write
input registers 16-bit quantity, provided by an I/O system, read-only
output registers 16-bit quantity, alterable by an application program, read-write
The distinction between inputs and outputs, and between bit-addressable and word-addressable data items, do not imply any application behavior. 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 65536 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.
There is no assumption that the data items represent a true contiguous array of data, although that is the interpretation used by most simple PLC’s
The ‘read and write general reference’ function codes are defined to carry a 32 bit reference number, and could be used to allow direct access to data items within a VERY large space. Today there are no PLC devices which take advantage of that.
One potential source of confusion is the relationship between the reference numbers used in MODBUS functions, and the ‘register numbers’ used in Modicon PLC’s. For historical reasons, user reference numbers were expressed as decimal numbers with a starting offset of 1. However MODBUS uses the more natural software interpretation of an unsigned integer index starting at zero.
So a modbus message requesting the read of a register at offset 0 would return the value known to the application programmer as found in register 4:00001 (memory type 4 = output register, reference 00001)
2.4 Implied length philosophy
All MODBUS requests and responses are designed in such a way that the recipient can verify that a message is complete. For function codes where the request and response are of fixed length, the function code alone is sufficient. For function codes carrying a variable amount of data in the request or response, the data portion will be preceded by a byte count.
When Modbus is carried over TCP, additional length information is carried in the prefix to allow the recipient to recognize message boundaries even if the message had to be split into multiple packets for transmission. The existence of explicit and implicit length rules, and use of a CRC-32 error check code (on Ethernet) results in an infinitesimal chance of undetected corruption to a request or response message.
3. Conformance class summary
When defining a new protocol from scratch, it is possible to enforce consistency of numbering and interpretation. MODBUS by its nature is implemented already in many places, and disruption to existing implementations must be avoided.
Therefore the existing set of transaction types have been classified into conformance classes where level 0 represents functions which are universally implemented and totally consistent, and level 2 represents useful functions but with some idiosyncrasies. Those functions of the present set which are NOT suitable for interoperability are also identified.
It must be noted that future extensions to this standard may define additional function codes to handle situations where the existing de-facto standard is deficient. However, it would be misleading for details of such proposed extensions to appear in this document. It will always be possible to determine if a particular target device supports a particular function code by sending it ‘speculatively’ and checking for the type of exception response if any, and this approach will guarantee the continued interoperability of current MODBUS devices with the introduction of any such extensions. Indeed, this is the philosophy which has led to the current function code classification.
3.1 Class 0
This is the minimum useful set of functions, for both a MASTER and a SLAVE.
read multiple registers (fc 3)
write multiple registers (fc 16)
3.2 Class 1
This is the additional set of functions which is commonly implemented and interoperable. As explained before, many slaves choose to treat input, output, discrete and register as equivalent.
read coils (fc 1)
read input discretes (fc 2)
read input registers (fc 4)
write coil (fc 5)
write single register (fc 6)
read exception status (fc 7)
This function typically has a different meaning for each slave family
3.3 Class 2
These are the data transfer functions needed for routine operations such as HMI and supervision
force multiple coils (fc 15)
read general reference (fc 20)
This function has the ability to handle multiple simultaneous requests, and can accept a reference number of 32 bits. Current 584 and 984 PLC’s only use this function to accept references of type 6 (extended register files).
This function would be the most appropriate to extend to handle large register spaces and data items which currently lack reference numbers such as ‘unlocated’ variables.
write general reference (fc 21)
This function has the ability to handle multiple simultaneous requests, and can accept a reference number of 32 bits. Current 584 and 984 PLC’s only use this function to accept references of type 6 (extended register files).
This function would be the most appropriate to extend to handle large register spaces and data items which currently lack reference numbers such as ‘unlocated’ variables.
mask write register (fc 22)
read/write registers (fc 23)
This function allows the input of a range of registers and the output of a range of registers as a single transaction. It is the most efficient way, using MODBUS, to perform a regular exchange of a state image such as with an I/O module.
Thus a high performance but versatile data collection device might choose to implement functions 3, 16 and 23 to combine rapid regular exchange of data (23) with the ability to perform on-demand interrogations or updates of particular data items (3 and 16)
read FIFO queue (fc 24)
A somewhat specialized function, intended to allow the transfer of data from a table structured as a FIFO (for use with the FIN and FOUT function blocks on the 584/984) to a host computer. Useful in certain types of event logging applications
3.4 Machine/vendor/network specific functions
All of the following functions, although mentioned in the MODBUS protocol manuals, are not appropriate for interoperability purposes because they are too machine-dependent.
diagnostics (fc 8)
program (484) (fc 9)
poll (484) (fc 10)
get comm event counters (Modbus) (fc 11)
get comm event log (Modbus) (fc 12)
program (584/984) (fc 13)
poll (584/984) (fc 14)
report slave ID (fc 17)
program (884/u84) (fc 18)
reset comm link (884/u84) (fc 19)
program (ConCept) (fc 40)
firmware replacement (fc 125)
program (584/984) (fc 126)
report local address (Modbus) (fc 127)
4. Protocol structure
This section describes the general form of encapsulation of a MODBUS request or response when carried on the MODBUS/TCP network. It is important to note that the structure of the request and response body, from the function code to the end of the data portion, have EXACTLY the same layout and meaning as in the other MODBUS variants, such as
MODBUS serial port - ASCII encoding
MODBUS serial port - RTU (binary) encoding
MODBUS PLUS network - data path
The only differences in these other cases are the form of any ‘framing’ sequence, error check pattern, and address interpretation.
All requests are sent via TCP on registered port 502.
Requests are normally sent in half-duplex fashion on a given connection. That is, there is no benefit in sending additional requests on a single connection while a response is outstanding. Devices which wish to obtain high peak transfer rates are instead encouraged to establish multiple TCP connections to the same target However some existing client devices are known to attempt to ‘pipeline’ requests. Design techniques which allow a server to accommodate this behavior are described in Appendix A.
The MODBUS ‘slave address’ field is replaced by a single byte ‘Unit Identifier’ which may be used to communicate via devices such as bridges and gateways which use a single IP address to support multiple independent end units.
The request and response are prefixed by six bytes as follows
byte 0: transaction identifier - copied by server - usually 0
byte 1: transaction identifier - copied by server - usually 0
byte 2: protocol identifier = 0
byte 3: protocol identifier = 0
byte 4: length field (upper byte) = 0 (since all messages are smaller than 256)
byte 5: length field (lower byte) = number of bytes following
byte 6: unit identifier (previously ‘slave address’)
byte 7: MODBUS function code
byte 8 on: data as needed
So an example transaction ‘read 1 register at offset 4 from UI 9’ returning a value of 5 would be
request: 00 00 00 00 00 06 09 03 00 04 00 01
response: 00 00 00 00 00 05 09 03 02 00 05
See later section for examples of the use of each of the function codes in conformance classes 0-2
Designers familiar with MODBUS should note that the ‘CRC-16’ or ‘LRC’ check fields are NOT needed in MODBUS/TCP. The TCP/IP and link layer (eg. Ethernet) checksum mechanisms instead are used to verify accurate delivery of the packet.
5. Protocol reference by conformance class
Note that in the examples, the request and response are listed from the function code byte onwards. As said before, there will be a transport - dependent prefix which in the case of MODBUS/TCP comprises the seven bytes
ref ref 00 00 00 len unit
The ‘ref ref’ above is two bytes of ‘transaction reference’ number which have no value at the server but are copied verbatim from request to response for the convenience of the client. Simple clients usually choose to leave the values at zero.
In the examples, the format for a request and response is given like this (the example is for a ‘read register’ request, see detail in later section)
03 00 00 00 01 => 03 02 12 34
This represents a hexadecimal series of bytes to be appended to the prefix, so the full message on the TCP connection would be (assume unit identifier 09 again)
request: 00 00 00 00 00 06 09 03 00 00 00 01
response: 00 00 00 00 00 05 09 03 02 12 34
(All of these requests and responses were verified by using an automatic tool, querying a current specification Modicon Quantum PLC)
5.1 Class 0 commands detail
5.1.1 Read multiple registers (FC 3)
Request
Byte 0: FC = 03
Byte 1-2: Reference number
Byte 3-4: Word count (1-125)
Response
Byte 0: FC = 03
Byte 1: Byte count of response (B=2 x word count)
Byte 2-(B+1): Register values
Exceptions
Byte 0: FC = 83 (hex)
Byte 1: exception code = 01 or 02
Example
Read 1 register at reference 0 (40001 in Modicon 984) resulting in value 1234 hex
03 00 00 00 01 => 03 02 12 34
5.1.2 Write multiple registers (FC 16)
Request
Byte 0: FC = 10 (hex)
Byte 1-2: Reference number
Byte 3-4: Word count (1-100)
Byte 5: Byte count (B=2 x word count)
Byte 6-(B+5): Register values
Response
Byte 0: FC = 10 (hex)
Byte 1-2: Reference number
Byte 3-4: Word count
Exceptions
Byte 0: FC = 90 (hex)
Byte 1: exception code = 01 or 02
Example
Write 1 register at reference 0 (40001 in Modicon 984) of value 1234 hex
10 00 00 00 01 02 12 34 => 10 00 00 00 01
5.2 Class 1 commands detail
5.2.1 Read coils (FC 1)
Request
Byte 0: FC = 01
Byte 1-2: Reference number
Byte 3-4: Bit count (1-2000)
Response
Byte 0: FC = 01
Byte 1: Byte count of response (B=(bit count+7)/8)
Byte 2-(B+1): Bit values (least significant bit is first coil!)
Exceptions
Byte 0: FC = 81 (hex)
Byte 1: exception code = 01 or 02
Example
Read 1 coil at reference 0 (00001 in Modicon 984) resulting in value 1
01 00 00 00 01 => 01 01 01
Note that the format of the return data is not consistent with a big-endian architecture. Note also that this request can be very computation-intensive on the slave if the request calls for multiple words and they are not aligned on 16-bit boundaries.
5.2.2 Read input discretes (FC 2)
Request
Byte 0: FC = 02
Byte 1-2: Reference number
Byte 3-4: Bit count (1-2000)
Response
Byte 0: FC = 02
Byte 1: Byte count of response (B=(bit count+7)/8)
Byte 2-(B+1): Bit values (least significant bit is first coil!)
Exceptions
Byte 0: FC = 82 (hex)
Byte 1: exception code = 01 or 02
Example
Read 1 discrete input at reference 0 (10001 in Modicon 984) resulting in value 1
02 00 00 00 01 => 02 01 01
Note that the format of the return data is not consistent with a big-endian architecture. Note also that this request can be very computation-intensive on the slave if the request calls for multiple words and they are not aligned on 16-bit boundaries.
5.2.3 Read input registers (FC 4)
Request
Byte 0: FC = 04
Byte 1-2: Reference number
Byte 3-4: Word count (1-125)
Response
Byte 0: FC = 04
Byte 1: Byte count of response (B=2 x word count)
Byte 2-(B+1): Register values
Exceptions
Byte 0: FC = 84 (hex)
Byte 1: exception code = 01 or 02
Example
Read 1 input register at reference 0 (30001 in Modicon 984) resulting in value 1234 hex
04 00 00 00 01 => 04 02 12 34
5.2.4 Write coil (FC 5)
Request
Byte 0: FC = 05
Byte 1-2: Reference number
Byte 3: = FF to turn coil ON, =00 to turn coil OFF
Byte 4: = 00
Response
Byte 0: FC = 05
Byte 1-2: Reference number
Byte 3: = FF to turn coil ON, =00 to turn coil OFF (echoed)
本文转自
http://www.fieldbuses.com/n995c45.aspx
OPEN Modbus /TCP SPECIFICATION
Release 1.0, 29 March 1999
Andy Swales
Schneider Electric
[email protected]
Contents
Contents............ 2
1. Status of this specification...... 3
2. Overview........ 3
2.1 Connection-oriented.............. 3
2.2 Data encoding........ 4
2.3 Interpretation of reference numbers......... 4
2.4 Implied length philosophy.... 5
3. Conformance class summary... 5
3.1 Class 0...... 5
3.2 Class 1...... 5
3.3 Class 2...... 6
3.4 Machine/vendor/network specific functions....... 7
4. Protocol structure............. 7
5. Protocol reference by conformance class.................... 8
5.1 Class 0 commands detail............... 9
5.1.1 Read multiple registers (FC 3)................ 9
5.1.2 Write multiple registers (FC 16).............. 9
5.2 Class 1 commands detail............. 10
5.2.1 Read coils (FC 1).................. 10
5.2.2 Read input discretes (FC 2).............. 10
5.2.3 Read input registers (FC 4).............. 11
5.2.4 Write coil (FC 5) 11
5.2.5 Write single register (FC 6).................. 12
5.2.6 Read exception status (FC 7).................. 12
5.3 Class 2 commands detail............. 13
5.3.1 Force multiple coils (FC 15)..... 13
5.3.2 Read general reference (FC 20)..... 14
5.3.3 Write general reference (FC 21)..... 15
5.3.4 Mask write register (FC 22)..... 16
5.3.5 Read/write registers (FC 23)............ 16
5.3.6 Read FIFO queue (FC 24)..... 17
6. Exception codes................ 17
Appendices..... 19
A. Client and Server Implementation Guidance.......... 19
A.1 Client design.......... 19
A.2 Server design.......... 20
A.2.1 Multithreaded server... 20
A.2.2 Single-threaded server 21
A.3 Required and expected performance 22
B. Data Encoding for non-word data........................... 23
B.1 Bit numbers within a word...................... 23
B.2 Multi-word quantities..... 24
B.2.1 984 Data Types.................. 24
B.2.2 IEC-1131 data types 25
1. Status of this specification
Initial release 3 Sept 1997
Draft for public review.
Re-release 29 March 1999 at Revision 1.0.
No technical changes, clarifications only.
Added Appendices A and B in response to common implementation questions.
This specification of Modbus/TCP is being published by being publicly visible on the World Wide Web. It is intended for the benefit of developers wishing to use MODBUS/TCP as an interoperability standard in the field of industrial automation.
Since MODBUS and MODBUS/TCP are in reality ‘de-facto’ standards, in that many vendors and products implement it already, this specification primarily explains the specific encoding of MODBUS messages over the TCP communication protocol universally available on the Internet.
2. Overview
MODBUS/TCP is a variant of the MODBUS family of simple, vendor-neutral communication protocols intended for supervision and control of automation equipment. Specifically, it covers the use of MODBUS messaging in an ‘Intranet’ or ‘Internet’ environment using the TCP/IP protocols. The most common use of the protocols at this time are for Ethernet attachment of PLC’s, I/O modules, and ‘gateways’ to other simple field buses or I/O networks.
The MODBUS/TCP protocol is being published as a (‘de-facto’) automation standard. Since MODBUS is already widely known, there should be little information in this document which could not be obtained elsewhere. However, an attempt has been made to clarify which functions within MODBUS have value for interoperability of general automation equipment, and which parts are ‘baggage’ from the alternate use of MODBUS as a programming protocol for PLC’s.
This is done below by grouping supported message types into ‘conformance classes’ which differentiate between those messages which are universally implemented and those which are optional, particularly those specific to devices such as PLC’s.
2.1 Connection-oriented
In MODBUS, data transactions are traditionally stateless, making them highly resistant to disruption from noise and yet requiring minimal recovery information to be maintained at either end.
Programming operations, on the other hand, expect a connection-oriented approach. This was achieved on the simpler variants by an exclusive ‘login’ token, and on the Modbus Plus variant by explicit ‘Program Path’ capabilities which maintained a duplex association until explicitly broken down.
MODBUS/TCP handles both situations. A connection is easily recognized at the protocol level, and a single connection may carry multiple independent transactions. In addition, TCP allows a very large number of concurrent connections, so in most cases it is the choice of the initiator whether to reconnect as required or re-use a long-lived connection.
Developers familiar with MODBUS may wonder why the connection-oriented TCP protocol is used rather than the datagram-oriented UDP. The main reason is to keep control of an individual ‘transaction’ by enclosing it in a connection which can be identified, supervised, and canceled without requiring specific action on the part of the client and server applications. This gives the mechanism a wide tolerance to network performance changes, and allows security features such as firewalls and proxies to be easily added.
Similar reasoning was used by the original developers of the World Wide Web when they chose to implement a minimal Web query as a single transaction using TCP on well-known port 80.
2.2 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. So for example
16 - bits 0x1234 would be 0x12 0x34
32 - bits 0x12345678L would be 0x12 0x34 0x56 0x78
2.3 Interpretation of reference numbers
MODBUS bases its data model on a series of tables which have distinguishing characteristics. The four primary tables are
input discretes single bit, provided by an I/O system, read-only
output discretes single bit, alterable by an application program, read-write
input registers 16-bit quantity, provided by an I/O system, read-only
output registers 16-bit quantity, alterable by an application program, read-write
The distinction between inputs and outputs, and between bit-addressable and word-addressable data items, do not imply any application behavior. 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 65536 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.
There is no assumption that the data items represent a true contiguous array of data, although that is the interpretation used by most simple PLC’s
The ‘read and write general reference’ function codes are defined to carry a 32 bit reference number, and could be used to allow direct access to data items within a VERY large space. Today there are no PLC devices which take advantage of that.
One potential source of confusion is the relationship between the reference numbers used in MODBUS functions, and the ‘register numbers’ used in Modicon PLC’s. For historical reasons, user reference numbers were expressed as decimal numbers with a starting offset of 1. However MODBUS uses the more natural software interpretation of an unsigned integer index starting at zero.
So a modbus message requesting the read of a register at offset 0 would return the value known to the application programmer as found in register 4:00001 (memory type 4 = output register, reference 00001)
2.4 Implied length philosophy
All MODBUS requests and responses are designed in such a way that the recipient can verify that a message is complete. For function codes where the request and response are of fixed length, the function code alone is sufficient. For function codes carrying a variable amount of data in the request or response, the data portion will be preceded by a byte count.
When Modbus is carried over TCP, additional length information is carried in the prefix to allow the recipient to recognize message boundaries even if the message had to be split into multiple packets for transmission. The existence of explicit and implicit length rules, and use of a CRC-32 error check code (on Ethernet) results in an infinitesimal chance of undetected corruption to a request or response message.
3. Conformance class summary
When defining a new protocol from scratch, it is possible to enforce consistency of numbering and interpretation. MODBUS by its nature is implemented already in many places, and disruption to existing implementations must be avoided.
Therefore the existing set of transaction types have been classified into conformance classes where level 0 represents functions which are universally implemented and totally consistent, and level 2 represents useful functions but with some idiosyncrasies. Those functions of the present set which are NOT suitable for interoperability are also identified.
It must be noted that future extensions to this standard may define additional function codes to handle situations where the existing de-facto standard is deficient. However, it would be misleading for details of such proposed extensions to appear in this document. It will always be possible to determine if a particular target device supports a particular function code by sending it ‘speculatively’ and checking for the type of exception response if any, and this approach will guarantee the continued interoperability of current MODBUS devices with the introduction of any such extensions. Indeed, this is the philosophy which has led to the current function code classification.
3.1 Class 0
This is the minimum useful set of functions, for both a MASTER and a SLAVE.
read multiple registers (fc 3)
write multiple registers (fc 16)
3.2 Class 1
This is the additional set of functions which is commonly implemented and interoperable. As explained before, many slaves choose to treat input, output, discrete and register as equivalent.
read coils (fc 1)
read input discretes (fc 2)
read input registers (fc 4)
write coil (fc 5)
write single register (fc 6)
read exception status (fc 7)
This function typically has a different meaning for each slave family
3.3 Class 2
These are the data transfer functions needed for routine operations such as HMI and supervision
force multiple coils (fc 15)
read general reference (fc 20)
This function has the ability to handle multiple simultaneous requests, and can accept a reference number of 32 bits. Current 584 and 984 PLC’s only use this function to accept references of type 6 (extended register files).
This function would be the most appropriate to extend to handle large register spaces and data items which currently lack reference numbers such as ‘unlocated’ variables.
write general reference (fc 21)
This function has the ability to handle multiple simultaneous requests, and can accept a reference number of 32 bits. Current 584 and 984 PLC’s only use this function to accept references of type 6 (extended register files).
This function would be the most appropriate to extend to handle large register spaces and data items which currently lack reference numbers such as ‘unlocated’ variables.
mask write register (fc 22)
read/write registers (fc 23)
This function allows the input of a range of registers and the output of a range of registers as a single transaction. It is the most efficient way, using MODBUS, to perform a regular exchange of a state image such as with an I/O module.
Thus a high performance but versatile data collection device might choose to implement functions 3, 16 and 23 to combine rapid regular exchange of data (23) with the ability to perform on-demand interrogations or updates of particular data items (3 and 16)
read FIFO queue (fc 24)
A somewhat specialized function, intended to allow the transfer of data from a table structured as a FIFO (for use with the FIN and FOUT function blocks on the 584/984) to a host computer. Useful in certain types of event logging applications
3.4 Machine/vendor/network specific functions
All of the following functions, although mentioned in the MODBUS protocol manuals, are not appropriate for interoperability purposes because they are too machine-dependent.
diagnostics (fc 8)
program (484) (fc 9)
poll (484) (fc 10)
get comm event counters (Modbus) (fc 11)
get comm event log (Modbus) (fc 12)
program (584/984) (fc 13)
poll (584/984) (fc 14)
report slave ID (fc 17)
program (884/u84) (fc 18)
reset comm link (884/u84) (fc 19)
program (ConCept) (fc 40)
firmware replacement (fc 125)
program (584/984) (fc 126)
report local address (Modbus) (fc 127)
4. Protocol structure
This section describes the general form of encapsulation of a MODBUS request or response when carried on the MODBUS/TCP network. It is important to note that the structure of the request and response body, from the function code to the end of the data portion, have EXACTLY the same layout and meaning as in the other MODBUS variants, such as
MODBUS serial port - ASCII encoding
MODBUS serial port - RTU (binary) encoding
MODBUS PLUS network - data path
The only differences in these other cases are the form of any ‘framing’ sequence, error check pattern, and address interpretation.
All requests are sent via TCP on registered port 502.
Requests are normally sent in half-duplex fashion on a given connection. That is, there is no benefit in sending additional requests on a single connection while a response is outstanding. Devices which wish to obtain high peak transfer rates are instead encouraged to establish multiple TCP connections to the same target However some existing client devices are known to attempt to ‘pipeline’ requests. Design techniques which allow a server to accommodate this behavior are described in Appendix A.
The MODBUS ‘slave address’ field is replaced by a single byte ‘Unit Identifier’ which may be used to communicate via devices such as bridges and gateways which use a single IP address to support multiple independent end units.
The request and response are prefixed by six bytes as follows
byte 0: transaction identifier - copied by server - usually 0
byte 1: transaction identifier - copied by server - usually 0
byte 2: protocol identifier = 0
byte 3: protocol identifier = 0
byte 4: length field (upper byte) = 0 (since all messages are smaller than 256)
byte 5: length field (lower byte) = number of bytes following
byte 6: unit identifier (previously ‘slave address’)
byte 7: MODBUS function code
byte 8 on: data as needed
So an example transaction ‘read 1 register at offset 4 from UI 9’ returning a value of 5 would be
request: 00 00 00 00 00 06 09 03 00 04 00 01
response: 00 00 00 00 00 05 09 03 02 00 05
See later section for examples of the use of each of the function codes in conformance classes 0-2
Designers familiar with MODBUS should note that the ‘CRC-16’ or ‘LRC’ check fields are NOT needed in MODBUS/TCP. The TCP/IP and link layer (eg. Ethernet) checksum mechanisms instead are used to verify accurate delivery of the packet.
5. Protocol reference by conformance class
Note that in the examples, the request and response are listed from the function code byte onwards. As said before, there will be a transport - dependent prefix which in the case of MODBUS/TCP comprises the seven bytes
ref ref 00 00 00 len unit
The ‘ref ref’ above is two bytes of ‘transaction reference’ number which have no value at the server but are copied verbatim from request to response for the convenience of the client. Simple clients usually choose to leave the values at zero.
In the examples, the format for a request and response is given like this (the example is for a ‘read register’ request, see detail in later section)
03 00 00 00 01 => 03 02 12 34
This represents a hexadecimal series of bytes to be appended to the prefix, so the full message on the TCP connection would be (assume unit identifier 09 again)
request: 00 00 00 00 00 06 09 03 00 00 00 01
response: 00 00 00 00 00 05 09 03 02 12 34
(All of these requests and responses were verified by using an automatic tool, querying a current specification Modicon Quantum PLC)
5.1 Class 0 commands detail
5.1.1 Read multiple registers (FC 3)
Request
Byte 0: FC = 03
Byte 1-2: Reference number
Byte 3-4: Word count (1-125)
Response
Byte 0: FC = 03
Byte 1: Byte count of response (B=2 x word count)
Byte 2-(B+1): Register values
Exceptions
Byte 0: FC = 83 (hex)
Byte 1: exception code = 01 or 02
Example
Read 1 register at reference 0 (40001 in Modicon 984) resulting in value 1234 hex
03 00 00 00 01 => 03 02 12 34
5.1.2 Write multiple registers (FC 16)
Request
Byte 0: FC = 10 (hex)
Byte 1-2: Reference number
Byte 3-4: Word count (1-100)
Byte 5: Byte count (B=2 x word count)
Byte 6-(B+5): Register values
Response
Byte 0: FC = 10 (hex)
Byte 1-2: Reference number
Byte 3-4: Word count
Exceptions
Byte 0: FC = 90 (hex)
Byte 1: exception code = 01 or 02
Example
Write 1 register at reference 0 (40001 in Modicon 984) of value 1234 hex
10 00 00 00 01 02 12 34 => 10 00 00 00 01
5.2 Class 1 commands detail
5.2.1 Read coils (FC 1)
Request
Byte 0: FC = 01
Byte 1-2: Reference number
Byte 3-4: Bit count (1-2000)
Response
Byte 0: FC = 01
Byte 1: Byte count of response (B=(bit count+7)/8)
Byte 2-(B+1): Bit values (least significant bit is first coil!)
Exceptions
Byte 0: FC = 81 (hex)
Byte 1: exception code = 01 or 02
Example
Read 1 coil at reference 0 (00001 in Modicon 984) resulting in value 1
01 00 00 00 01 => 01 01 01
Note that the format of the return data is not consistent with a big-endian architecture. Note also that this request can be very computation-intensive on the slave if the request calls for multiple words and they are not aligned on 16-bit boundaries.
5.2.2 Read input discretes (FC 2)
Request
Byte 0: FC = 02
Byte 1-2: Reference number
Byte 3-4: Bit count (1-2000)
Response
Byte 0: FC = 02
Byte 1: Byte count of response (B=(bit count+7)/8)
Byte 2-(B+1): Bit values (least significant bit is first coil!)
Exceptions
Byte 0: FC = 82 (hex)
Byte 1: exception code = 01 or 02
Example
Read 1 discrete input at reference 0 (10001 in Modicon 984) resulting in value 1
02 00 00 00 01 => 02 01 01
Note that the format of the return data is not consistent with a big-endian architecture. Note also that this request can be very computation-intensive on the slave if the request calls for multiple words and they are not aligned on 16-bit boundaries.
5.2.3 Read input registers (FC 4)
Request
Byte 0: FC = 04
Byte 1-2: Reference number
Byte 3-4: Word count (1-125)
Response
Byte 0: FC = 04
Byte 1: Byte count of response (B=2 x word count)
Byte 2-(B+1): Register values
Exceptions
Byte 0: FC = 84 (hex)
Byte 1: exception code = 01 or 02
Example
Read 1 input register at reference 0 (30001 in Modicon 984) resulting in value 1234 hex
04 00 00 00 01 => 04 02 12 34
5.2.4 Write coil (FC 5)
Request
Byte 0: FC = 05
Byte 1-2: Reference number
Byte 3: = FF to turn coil ON, =00 to turn coil OFF
Byte 4: = 00
Response
Byte 0: FC = 05
Byte 1-2: Reference number
Byte 3: = FF to turn coil ON, =00 to turn coil OFF (echoed)
本文转自
http://www.fieldbuses.com/n995c45.aspx