MODBUS应用协议白皮书

Modbus官方应用协议白皮书参考。IOT物联网，PLC开发必读。MODBUS Application Protocol Specification V1.1b3ModbusMBAP MODBUS Application ProtocolDU Protocol data unitPLc Programmable Logic ControllerTCP Transmission control protocol3 ContextThe MOdBUs protocol allows an easy communication within all types of networkarchitecturesMODBUS COMMUNICATIONDrivelPLCHMIPLC∥OMODBUS ON TCP/IPGatewayGatewayPLCPlCHMI2zom2maoEsDe viceDriveoDe viceFigure 2Example of modbus Network ArchitectureEvery type of devices(PLC, HMI, Control Panel, Driver, Motion control, I/O Device.)can useMODBUS protocol to initiate a remote operationThe same communication can be done as well on serial line as on an ethernet tcP/iPnetworks. Gate ways allow a communication between several types of buses or network usingthe MOdBUs protocol4 General description4.1 Protocol descriptionThe MOdBUs protocol defines a simple protocol data unit (PDU)independent of theunderlying communication layers. The mapping of MODBUs protocol on specific buses ornetwork can introduce some additional fields on the application data unit (ADUADUAdditional address Function codeDataError checkPDUFigure 3General Modbus frameApril 26, 2012http://www.modbus.org3/50MODBUS Application Protocol Specification V1.1b3ModbusThe MODBus application data unit is built by the client that initiates a MODBUS transactionThe function indicates to the server what kind of action to perform. The MOdBUs applicationprotocol establishes the format of a request initiated by a clientThe function code field of a modbus data unit is coded in one byte. Valid codes are in therange of 1... 255 decimal (the range 128-255 is reserved and used for exceptionresponses). When a message is sent from a Client to a Server device the function code fieldtells the server what kind of action to perform. Function code"0"is not validSub-function codes are added to some function codes to define multiple actionsThe data field of messages sent from a client to server devices contains additional informationthat the server uses to take the action defined by the function code. this can include itemslike discrete and register addresses, the quantity of items to be handled, and the count ofactual data bytes in the fieldThe data field may be nonexistent (of zero length)in certain kinds of requests, in this case theserver does not require any additional information. The function code alone specifies theactionIf no error occurs related to the ModBUs function requested in a properly received MOdBUsADU the data field of a response from a server to a client contains the data requested. If anerror related to the modBus function requested occurs, the field contains an exception codethat the server application can use to determine the next action to be takenFor exam ple a client can read the on /OFF states of a group of discrete outputs or inputs orit can read/write the data contents of a group of registersWhen the server responds to the client, it uses the function code field to indicate either anormal (error-free)response or that some kind of error occurred (called an exceptionresponse). For a normal response, the server simply echoes to the request the originalfunction codeClientServerInitiate requestunction code Data Request亠 Perform the actionInitiate the responseFunction code Data ResponseReceive the responseFigure 4: MODBUS transaction (error free)For an exception response, the server returns a code that is equivalent to the original functioncode from the request Pdu with its most significant bit set to logic 1ClientServerInitiate requestFunction codeData RequestError detected in the actionInitiate an erroReceive the responseException Function code Exception codeFigure 5MODBUS transaction(exception response)April 26, 2012http://www.modbus.org4/50MODBUS Application Protocol Specification V1.1b3ModbusNote: It is desirable to manage a time out in order not to indefinitely wait for an answer which will perhapsnever arriveThe size of the MODBUS PDU is limited by the size constraint inherited from the firstMODBUS implementation on Serial Line network(max RS485 ADU 256 bytes)ThereforeMODBUS PDU for serial line communication 256- Server address (1 byte)-CRC (2bytes)=253 bytesConsequentlyRS232/RS485 ADU 253 bytes Server address (1 byte ) Crc (2 bytes)=256 bytesTCP MODBUS ADU =253 bytes mAp (7 bytes)=260 bytesThe MODBUS protocol defines three PDUs. They areMODBUS Request PDU, mb req pduMODBUS Response PDU, mb_rsp pduMODBUS Exception Response PDU, mb excep rsp_ pduThe mb req pdu is defined asmb_reg_pdu=[function_code, request_data],function code=[1 byte] modbus function coderequest data=[n bytes] This field is function code dependent and usuallycontains information such as variable referencesvariable counts data offsets sub-function codes etcThe mb rsp_ pdu is defined asmb_rsppdu [function_ code, response data),function code= [1 byte ModBUs function coderesponse data [n bytes] This field is function code dependent and usuallycontains information such as variable referencesvariable counts data offsets sub-function codes etcThe mb excep rsp pdu is defined asmb excep rsp pdu =lexception-function code, request data]whereexception -function code =[1 byte] modbUs function code 0X80exception code=[1 byte] ModBUs Exception Code defined in tableMODBUS EXception Codes"(see section 7)4.2 Data EncodingMODBUS uses a 'big-Endian representation for addresses and data items. This meansthat when a numerical quantity larger than a single byte is transmitted, the most significantbyte is sent first. So for exampleRegister size value16- bits0X1234the first byte sent is 0x12 then 0x34Note: For more details, see [11April 26, 2012http://www.modbus.org5/50MODBUS Application Protocol Specification V1.1b3Modbus4.3 MODBUS Data modelMODBUs bases its data model on a series of tables that have distinguishing characteristicsThe four primary tables arePrimary tablesObject typeTypeCommentsDiscretes InputSingle bitRead-OnlyThis type of data can be provided by an I/O systemCoiSingle bitRead-WriteThis type of data can be alterable by an applicationprogramThis type of data can be provided by an I/o systemInput Registers16-bit wordRead-OnlyHolding Registers16-bit wordRead-WriteThis type of data can be alterable by an applicationprogramThe distinctions between inputs and outputs, and between bit-addressable and word-addressable data items, do not imply any application behavior. It is perfectly acceptable, andvery common, to regard all four tables as overlaying one another, if this is the most naturalinterpretation on the target machine in questionFor each of the primary tables, the protocol allows individual selection of 65536 data itemsand the operations of read or write of those items are designed to span multiple consecutivedata items up to a data size limit which is dependent on the transaction function codeIt's obvious that all the data handled via modbus(bits, registers )must be located in deviceapplication memory. But physical address in memory should not be confused with datareference. the only requirement is to link data reference with physical addressMODBUS logical reference numbers, which are used in MODBUS functions, are unsignedinteger indices starting at zeroImplementation examples of MODBUs modelThe examples below show two ways of organizing the data in device. There are differentorganizations possible, but not all are described in this document. Each device can have itsown organization of the data according to its applicationExample 1: Device having 4 separate blocksThe example below shows data organization in a device having digital and analog: inputs andoutputs. Each block is separate because data from different blocks have no correlation. Eachblock is thus accessible with different modbus functionsDevice application memoryMODBUS accessInput discreteCoilsMODBUS RequestInput RegistersHoldingRegistersMODBUS SERVER DEVICEFigure 6MODBUS Data Model with separate blockApril 26, 2012http://www.modbus.org6/50MODBUS Application Protocol Specification V1.1b3ModbusExample 2: Device having only 1 blockIn this example, the device has only 1 data block. The same data can be reached via severalMODBUS functions. either via a 16 bit access or via an access bit.MODBUS accessInput DiscreteCoilsMODBUS RequestInput RegisterHoldiRegisteMODBUS SERVER DEVICEFigure 7MODBUS Data Model with only 1 block4. 4 MODBUS Addressing modelThe MODBUs application protocol defines precisely PDU addressing rulesIn a modbus pdu each data is addressed from o to 65535It also defines clearly a MODBUs data model composed of 4 blocks that comprises severalelements num bered from 1 to nIn the modbus data model each element within a data block is numbered from 1 to nAfterwards the MODBUs data model has to be bound to the device application( IEC-6113object, or other application model)The pre-mapping between the modBus data model and the device application is totallyvendor device specificApril 26, 2012http://www.modbus.org7/50MODBUS Application Protocol Specification V1.1b3ModbusDevice applicationModBuS data modelMODBUS PDU addressesRead input oDiscrete InputRead coils 4Read registers 1Input registers 21Holding registersRead registers 54MappingApplication specificMODBUS Standard8000000000I0000000000E00000000000000000000000008000000000000000000000010000000000000IFigure 8MODBUS Addressing modelThe previous figure shows that a mOdBUs data numbered X is addressed in the MODBUSPdUX4.5 Define modbus transactionThe following state diagram describes the generic processing of a modBus transaction inserver sideApril 26, 2012http://www.modbus.org8/50MODBUS Application Protocol Specification V1.1b3ModbusWait for a mBndication[Receive MB indicationValidate functioninvalid]Exeptioncode= 1ValidValidate dataAddressException C ode= 2invalid][]Validate datavalueException Code 3invalid[validExecute MBException Code =4, 5. 6invalid]Send modbusExceptionSend modbusResponseReFigure 9MODBUS Transaction state diagramOnce the request has been processed by a server, a mOdBus response using theadequate modbus server transaction is builtDepending on the result of the processing two types of response are builtA positive MODBUS responsethe response function code the request function codeA MODBUS EXception response( see section 7)the objective is to provide to the client relevant information concerning theerror detected during the processingthe exception function code the request function code + 0x80an exception code is provided to indicate the reason of the errorApril 26, 2012http://www.modbus.org9/50MODBUS Application Protocol Specification V1.1b3Modbus5 Function Code CategoriesThere are three categories of MODBUS Functions codes. They arePublic Function codesAre well defined function codesguaranteed to be uniquevalidated by the MODBUS.org community,publicly documentedhave available conformance testincludes both defined public assigned function codes as well as unassigned functioncodes reserved for future useUser-Defined function codesthere are two ranges of user-defined function codes, i. e. 65 to 72 and from 100 to 110decimaluser can select and implement a function code that is not supported by thespecificationthere is no guarantee that the use of the selected function code will be uniqueif the user wants to re-position the functionality as a public function code, he mustinitiate an RFc to introduce the change into the public category and to have a newpublic function code assignedMODBUS Organization, Inc expressly reserves the right to develop the proposed rFcReserved Function codesFunction Codes currently used by some companies for legacy products and thatare not available for public useInformative Note: The reader is asked refer to Annex A(Informative)MODBUSRESERVED FUNCTION CODES. SUBCODES AND MEI TYPES127PUBLiC function codes110100 User Defined Function codesPUBLIC function codes7265 USer Defined Function codePUBLiC function codesFigure 10 MODBUS Function Code CategoriesApril 26, 2012http://www.modbus.org10/50