红外线通讯协议 V1.1

Infrared Data Association Plug and Play Extensions

to

Link Management Protocol

Version 1.1

Monday, January 08, 1996

Intel Corporation

Microsoft Corporation

1. Introduction

There are two scenarios in IR device inter-operability:

? Communication between a host (PC) and a peripheral.

? Communication between two hosts.

The differentiating feature in the two scenarios is that in the first case, an IR peripheral is logically a part of the host (as far as the user is concerned), while in the other, the two hosts are logically independent units. There are Plug and Play issues in both cases.

Scope

The software layers proposed by IrDA enable two IR devices to communicate with each https://www.wendangku.net/doc/0f14873087.html,munication capability alone does not imply Plug and Play. This document focuses on Plug and Play issues pertaining to host and peripheral inter-operability. This document does not address Plug and Play issues supporting the physical infrared provider. The physical infrared provider is similar to any other physical device and PnP issues of this device are addressed in the standard PnP world.

The above diagram illustrates the software stack on a typical IrDA approved PnP compatible device. The stack pictured on the left portrays a PnP ready OS and the layers required to support a

Diagram of software layers required for a COMM Device.

Physical IR Provider Device Personality COMM, LPT, PPP, WinSock IrLAP/IrLMP Protocol Stack PnP Extensions ?

Physical IR Provider COMM Personality

IrLMP IrLAP PnP Extensions

?

general IrDA PnP implementation. The stack on the right depicts an IrDA approved device which only needs software enough to support it’s own device.

Plug and Play issues between two hosts will be addressed at a later time. Currently, we do not address Plug and Play with IR peripherals needed at boot, for example, a keyboard. References

[EISA]EISA specification version 3.12

[WinID]Windows Generic Device ID specification

[PnP]Plug and Play Device Driver Developer's Guide

[IrLAP]Infrared Data Association Link Access Protocol

[IrLMP]Infrared Data Association Link Management Protocol

2. Terminology

Device ID A Device ID is an uncompressed EISA Device ID.

EISA Device ID An EISA device ID is a seven character field consisting of a three-

character manufacturer code, a three-character hexadecimal product

identifier and a one character hexadecimal revision number.

Host In the context of this document, a host is the entity that has discovered

an IR device.

IAS Information Access Service. This is an information service that must

be provided by every IrDA device. The information available via the

IAS contains a description of the services being offered by an IrDA

device to other IrDA devices.

IAP Information Access Protocol, IrLMP defined function set required to

access the IAS data.

IrDA Infrared Data Association. The Standards body responsible for

infrared PC standards.

IrLAP Infrared Link Access Protocol

Initiator Station performing the IrLAP discovery procedure.

IrLMP Infrared Link Management Protocol

LSAP Link Service Access Point

IR Device An IR entity that responds to the XID discovery process.

IR Peripheral An IR device that provides one or more peripheral functions to a host

via an IR connection.

Multi-function Device A peripheral device that supports more than one logical function. For

example a device that provides modem access plus printer services. Peripheral A device external to a Host that provides a specific function to that

host.

Windows Device ID A Windows Device ID is a PnP Device ID. This list of PnP device

ID’s is currently maintained by Microsoft.

Responder A station that responds to an IrLAP discovery procedure.

3. Plug and Play Issues

Many PnP add-in device issues are not relevant for IR devices. IR devices have no need to contend for physical resources such as IRQ’s and IO mappings. However, the IrLAP physical communication device is a standard PnP device consuming physical resources. IR peripherals do need a mechanism for device identification.

For transparency and ease-of-use reasons, connecting to an IR peripheral must be logically similar to connecting to a physically attached peripheral. Once discovered and integrated, the IR peripheral should appear in the host’s view of the underlying hardware. In a like manner, when the user removes the peripheral, it should be removed from the host’s view. In current Microsoft products, this view typically appears in the Registry.

If an IR device is discovered and needs to be incorporated into the system, the Plug and Play concerns could be classified as:

?device identification

?operational status of the peripheral

There are additional OS Plug and Play issues that are beyond the scope of this document.

Device Discovery

As part of the device discovery process, the device passes a DeviceInfo field to the host.[IrLAP] The link management layer controls the content of that DeviceInfo field in the IrLAP discovery process. The DeviceInfo field contains a service hint mask which has a single bit field defined that when set, states that the responding IrDA compliant device is Plug and Play ready. See [IrLMP] for DeviceInfo data definition and in particular for the service hint mask definitions. Note that since the service hint field is advisory a non PnP capable device could state that is was a PnP device and the PnP aware software layers must handle the device properly. However a device specifying, via the service hint mask, that it is a PnP device will incur additional overhead due to the software layers attempting to read the PnP object.

Device Identification

After device discovery, the host must determine the capabilities of the device. The IrLMP specification defines an Information Access Service (IAS) to allow devices to exchange information about device capabilities. This specification adds an IAS object for Plug and Play IR devices. The IAS PnP object is defined later in this document. The IAS PnP object contains two attributes that are needed to identify the discovered IR device.

The DeviceID attribute is the key to recognition of devices in the IrPnP arena. A Device ID is an uncompressed EISA device ID. EISA ID’s include but are not limited to the Windows generic Device ID’s maintained by Microsoft specifically for Plug and Play compatibility. Windows Generic Device ID’s are EISA ID’s using the reserved “PnP” manufacturer’s code. In cases where there exists a definition for a Windows Device ID and a definition for a manufacturer’s specific ID, the Windows Device ID takes precedence.

The Category attribute defines the specific class of function supported by the PnP IR Device. This field is semantically the same as the EISA defined CAT field. See [EISA] for known values for the Category attribute.

In order to support multi-function devices two approaches are available:

1.As in the IrPnP 1.0 specification, a singular device ID can be used to imply multiple functions.

This approach requires that a unique PnP enumerator be written specifically to support that device. It is then up to the enumerator for that device to load or cause the load of the appropriate drivers for the device at all levels. It is due to the complexity of this problem that the new approach is introduced for this 1.1 version of the IrPnP specification

2.Multiple PnP objects can be stored in the IAS of the device. Using this approach, the standard

infrared enumerator can query all the PnP objects on the device and perform the loading of the appropriate devices.

In the case of option number 2, there are various complications:

1.The IrCOMM specification currently provides no way of supporting multiple concurrent

IrCOMM channels. As a result a multi-function device that provides both modem access and printer access concurrently can not be supported by the IrCOMM protocol. To alleviate this problem IrCOMM must be extended to support multiple concurrent channels.

2.When a multifunction device includes IrCOMM support, there is currently no way to

distinguish between a PnP Id that is referring to a device that is accessed through IrCOMM, such as a modem or a printer, or a PnP Id that is refering to some other non-IrCOMM function, such as LAN access or a disk drive. To alleviate this problem, 3 new attributes are added to the PnP object. These attributes describe the relationship between PnP Ids and functions on the device.

Operational Status of the Peripheral

During discovery a device can inform the host of device status. This status may reflect the fact that the device is currently busy or in some way unable to support a service connection at this time. Device status values and their meanings are discussed in the ”IAS PnP Objects for Peripherals“section that follows.

4. IAS PnP Objects for Peripherals

The IrLMP specifies Information Access Service as the means to access information about services provided by IR devices. This information is stored as Objects with Object 0, of class Device, being the only object required by the IrLMP specification. For Plug and Play purposes, we define a set of distinguished objects, of class PnP. These new class object are required to be present on IR devices supporting Plug and Play.

The IAS PnP Object does not contain information about IRQ’s, DMA channels and I/O ports. This information is meaningless since the device described by the object is not physically connected to the host.

An Object is composed of a number of name-value pairs. Each name-value pair is an Attribute. The IrLMP specification defines the data format of Attributes in Section 4.3.3. The Attribute Type definitions used in the following object definition are restricted subsets of the IrLMP Attributes. The attribute names are case sensitive, they must appear exactly as listed below with no trailing blanks.

In the case of a single function PnP Class object, the attributes DeviceID, Name, Manufacturer, Category, Version and Status must be included. In the case of a multifunction device, depending on the object, the Function, ParentFunction and ParentInstance may also be required. See the description below for details. An example PnP object is included in Appendix A. The following table defines the Attributes associated with the PnP Object.

Object 1: Class PnP

Attribute Name PnP Attribute Type

DeviceID IDString

Name VendorString (90)

Manufacturer VendorString (30)

Category VendorString (3)

Version TwoBytes

Status Integer

Function String

ParentFunction String

ParentInstance Integer

CompCnt Integer

Comp#01IDString

.

Comp#nn IDString

Attribute Types

The Attribute types described here are all based upon the Attribute value definitions defined in the IrLMP specification (section 4.3.3). They are defined here so that the IrPnP can impose limitations upon IrLMP defined Attributes. The limitations imposed are length restrictions to reduce overhead.

IDString

The IDString type is a “User String” as defined in the IrLMP Specification limited to 14 Bytes of character data. Notice that the limitation is placed upon the length of the field (or the number of octets in the value). This implies a 14 character limit on ASCII strings and a 7 character limit on Unicode strings. Currently ASCII is the character set used in EISA Device ID’s by convention, but it costs very little to allow for 16 Bit character sets in possible future implementations.

VendorString (xx)

The VendorString type is a “User String” as defined in the IrLMP Specification limited to the number of bytes of character data specified by the xx parameter. Notice that the limitation is placed upon the length of the field (or the number of octets in the value). This means that usage of 16 bit characters would halve the effective amount of data.

Integer

This is the “Integer” type as described in the IrLMP specification.

TwoBytes

This is a restricted case of the “Octet Sequence” described in the IrLMP specification. This is an “Octet Sequence” restricted to exactly 2 Octets.

Attributes

This section describes the usage of the attributes of the PnP Class object.

DeviceID

This is the DeviceID of the IrDA Play and Play device. The Device ID specified here must be used by the higher level software to determine details describing the peripheral, or peripherals in the case of a multi-function device, supported by that device. Multi function devices are identified by a singular DeviceID. The existence of multiple functions on the device must be gleaned by the host from that singular DeviceID. Multi-function devices must also specify the “Category” attribute to be “MFC”, the EISA multi-function moniker.

IrDA Plug and Play device providers are expected to procure a three letter EISA manufacturer’s identifier and assign IDs for their devices. The specific EISA Device ID is constructed from the EISA manufacturer’s ID and the manufacturer’s device number as described in [EISA]. EISA identifiers may be obtained from:

BCPR Services, Inc

P.O. Box 11137

Spring, Texas 77391-1137

(713)251-4770 (phone)

(713)251-4832 (fax)

In the event that there are no device specific device drivers, the DeviceID provided by the manufacturer may alternatively be a Windows Generic Device ID. This allows the vendor to report hardware-level compatibility with standard devices defined by the Plug and Play Association.

Name

This is the device specific description. It is identical to the EISA defined field of the same name. This attribute can include up to 90 ASCII characters of text useful for identifying the product. This field is a textual description suitable for user presentation.

The intended use of this field is to provide a mechanism such that the OS, or other software layer, may present to the user a description of a device that has been detected. This will be useful in cases where the OS does not have support for the newly detected device and the user must supply a software update. For example, an OEM supplied driver diskette. Manufacturer

Manufacturer’s name. It is identical to the EISA defined field MFR. This attribute can include up to 30 ASCII characters of text. This field is a textual description suitable for user presentation. This field is used for the same function as the NAME attribute.

Category

This attribute contains a three upper case character text field. This field identifies the functional category of the device. This field is semantically the same as the EISA defined CAT field. See [EISA] for known values for the Category attribute.

Version

The version number of the IrPnP specification supported by the device. This field is provided for compatibility with future versions. This field is made up of exactly 2 octets. The first Octet is the Major Version number and the second octet is the minor version number. For example IrPnP Specification Version 1.0 would consist of the pair (1,0).

Status

This is a bit field that is used by a device to convey status to the host at discovery time. This is the only mechanism defined to acquire this type of device status. Therefore, in order for a host to determine if a PnP device’s status has changed the host must request the IAS PnP Class information.

Meaning Bit Mask Description

Unavailable0x00000001If this bit is set to one, then the device is not currently

available for use by requesting node. If this bit is set to zero,

then the device is available to the requester.

Reserved0xfffffffe Reserved for future use.

Function

This attribute reflects the function within the device this PnP Id refers to. The format of this field is the same as the format used in the HintBits field during device discovery. This attribute is only necessary for multi-function devices.

ParentFunction

This attribute is required in multifunction devices where some of the devices are “children” of other devices. A typical example would be a modem. In this case the modem is a “child” of IrCOMM and this filed would have the COMM support hint bit set. The format of this attribute is the same as the format used in the HintBits field during device discovery. ParentInstance

This attribute is required in multifunction devices where some of the devices are “children” of other devices and there is more than one instance of the parent function. A typical example would be a modem. In this case the modem is a “child” of IrCOMM. Since there may be multiple instances of a parent function, such as multiple concurrent COMM connections, this attribute is used to distinguish the parents. If the parent is the first IrCOMM instance than this value will be 0. If the parent is the second IrCOMM instance, then this value will be 1 etc…

CompCnt

This attribute defines the number of devices that this device is compatible with. The Compatibility ID’s immediately follow this attribute. If the device has no supported compatibility modes then, this attribute must be zero and there will be no Compatibility ID’s in the PnP Class object.

There can be no more than sixteen compatibility modes for any IrDA PnP device. This restriction is imposed to ensure that the discovery process is reasonable performant.

Comp#nn

This is the PnP DeviceID for the nth standard device that this device is compatible with. A compatible device is used by the OS to identify other device drivers that may be used with the discovered IrPnP device. There must be exactly CompCnt Compatibility ID’s listed in the PnP Class object. By returning a compatibility ID, the device is declaring itself to be operational using the device driver of the specified device.

It is important to note that the Comp#nn name includes a variable number. This number is encoded as a two digit decimal number. For example, the third device listed in the compatibility list would have a name encoded as “Comp#03”. Note that there is no “Comp#00” attribute.

5. Other Relevant Issues

The following issues are relevant in Plug and Play and must be addressed at implementation time:

Performance Issues

It is significant to note that the delay imposed upon a system by the discovery mechanism can be substantially affected by the length of the PnP Class Object defined by the vendor. The vendor can add unnecessary data overhead by specifying more compatabilities than needed and by using an excessively long “Name” attribute.

Device manufacturers must ensure that devices respond as quickly as possible since the IrLAP model specifies that a device can send responses only when it is polled by a host. Also, once polled, the host cannot transmit to the device until the device gives permission to the host (by setting the Final bit). The permission to transmit must be exchanged such that it is not held at one end for a long time.

PnP Device ID Management

The EISA Device ID’s are industry wide resources that must be managed via a standard clearing house. Microsoft is the current owner of the PnP Device ID pool. Other EISA device ID assignments are made via the EISA standards committee.

6. Sequence of Operations

During the normal discovery process, a host will detect various IR devices. The detected devices may or may not be PnP IR devices. In order to determine if a discovered device is a PnP device, the host must query the PnP compatibility bit in the DeviceInfo data returned by the device during the discovery process [IrLMP]. When it determines that a device says it is PnP compatible, the host software must issue an IAP LM-GetValueByClass request for the “DeviceID” attribute of the “PnP” class object. The device is a PnP device only if the request for the “PnP” object returns one or more valid PnP objects.

The steps to install a specific device on a system is implementation dependent, and as such is not discussed in detail here. However, it is important to note that a device’s status will provide an indication to the host that the device, while detected, is not available for use at discovery time.

The Version 1.1 extensions allow the system attaching to the PnP device to understand the relationship between device functions. This eliminates the need for each device class to have its own method of enumerating its children devices. For instance, a device that supports a COM port attached to a modem and concurrently supports LAN access provides 2 PnP objects, one of which is the LAN access PnP Id and another which describes a modem as a child of IrCOMM.

The transition of logical device connections is an implementation issue and must be addressed at another level.

Other

The device driver for the detected peripheral is responsible for handling other information such as distinguishing different event types on the peripheral. For example, an IR mouse will have two different types of events: movement of the mouse, and the button clicks, only the device driver need be aware of these different event types.

7. Example PnP Class Object

This section contains an example PnP Class object. The data is presented in a manner intended to portray the data that must be transferred for each object. The attribute ordering is not important to the “PnP” class object. The example uses ASCII encoding only.

The table below lists both the names and the values of the device attributes since for each attribute both the name and the value is transmitted. The number below each element of an attribute is the number of bytes of data that must be transmitted for that element. The two columns at the right is the total number of bytes transmitted for that attribute of information and of data. For example the DeviceID attribute consists of nine characters for the user string “DeviceID” (length byte = 8, and 8 characters), the one byte Type field (type=4), the one byte character set (ASCII=0) and eight characters for the EISA ID (length byte=7 and 7 characters) for a total of 9+1+1+8 = 19 bytes of transmitted data.

Bytes

Len Characters Transmitted Len Characters Type Char

Set

8DeviceID307ZAP0403

18111719

4Name3055Zappa's Special Midi Device, Version 2.7, IrDA Approved

141115563

12Manufacturer3017Loud Systems Inc.

1121111733

8Category303OTH

18111315

7Comp#01307PNPB002

17111718

7Comp#02307PNPB007

17111718

7Comp#03307PNPB011

17111718

Len Characters Type Integer Value

6Status10

161412

8CompCnt12

181412

Len Characters Type Len Octet 1Octet 2

7Version2210

17121113

Total221

关于西门子PLC的PPI通信协议的研究

关于西门子PLC的PPI通信协议的研究 摘要：本文结合西门子PLC的PPI通信协议的相关理论，主要研究了PPI协议的 通信过程、通信协议模型，并对PLC网络通信模式的构建进行了实例分析。 关键词：西门子PLC；PPI通信协议；通信程序 前言 PPI通信协议是一种特殊的通信协议，其协议本身是不公开的，只有西门子 S7-200的设备支持它。但掌握它也很重要，有时s7-200系列的设备之间只能通过PPI协议通信，例如上位机STEP7-Micro／WIN与S7-200PLC之间的基本通信；有 时只要通过一根电缆就可以实现S7-200PLC之间的简单通信，非常适用。但由于PPI通信协议不是公开的协议，因此一般现场设备是不支持的，限制了其作为标 准现场总线的应用，由此还需对协议内容、功能实现进行研究和分析。 1西门子PLC的PPI通信协议概述 1.1通信过程 在PPI网上，计算机与PLC通信，是采用主从方式，通信总是由计算机发起，PLC予以响应。具体过程如下： 1）计算机按通信任务，用一定格式，向PLC发送通信命令。 2）PLC收到命令后，进行命令校验，如校验后正确无误，则向计算机返回数 据E5H或F9H，作出初步应答。 3）计算机收到初步应答后，再向PLC发送SD（开始定界字符，为10H）、 DA（目标地址，即PLC地址02H）、SA（源地址，即计算机地址00H）、FC（功 能码，取5CH）、FCS（SA、DA、FC和的256余数，为5EH）、ED（结束分界符）确认命令。 如按以上设定的计算机及PLC地址，则发送10、02、00、5C、5E及16，6个字节的十六进制数据，以确认所发命令。 4）PLC收到此确认后，执行计算机所发送的通信命令，并向计算机返回相应 数据。 需要注意的是：如为读命令，情况将如上所述。但如为写或控制命令，PLC 收到后，经校验，如无误，一方面向计算机发送数据E5H，作出初步应答；另一 方面不需计算机确认，也将执行所发命令。但当收到计算机确认信息命令后，会 返回有关执行情况的信息代码[1]。 1.2 PPI协议模型 PPI通信协议的模型以OSI模型为基础，将其中的物理层、数据链路层和应用 层构成现场总线通信的三层模型，如表1所示。 其中PPI的应用层是通信模型的最高层，负责进行应用数据的读写操作。应用层是在数 据链路层之上的，接收数据链路层上传的数据，用来更新本站点的相关数据。当应用层需要 发送数据时，它只要将发送数据的目的站点、数据类型和数据本身等信息下载给数据链路层，由数据链路层去实现数据的发送。 PPI的数据链路层是位于通信模型的第2层，它介于物理层与应用层之间。一方面，它要 执行应用层的数据发送任务，生成数据和控制帧，并将这些帧下载给物理层，通过物理层实 现帧的发送；另一方面，数据链路层还要接收物理层的帧，根据帧进行校验等操作，若是数 据帧，则将其中的数据从帧中读出，上传给应用层。 一次数据写出操作的步骤包括：首先由本站(主站)向从站发出写入请求，从站作出正确接

欧姆龙PLC以太网TCP命令FINS协议实验

ETN21以太网fins/TCP命令 实验时间：2014年10月8日 实验设备：CP1H-XA40DR-A、CP1W-EXT01、CJ1W-ETN21、网线 实验目的：利用SOCKETTOOL发送fins/TCP命令，对CPU内存进行读取和写入。 实验步骤： 1、IP地址设置： ①打开电脑本地连接查看IP地址如下： ②usb线连上电脑，打开I/O表，将ETN21模块的ip地址与电脑设置为同一 个网段不同节点，节点号跟硬件上的node number一样，下载重启模块，如下： 2、配置socketool软件 ①软件选TCP Client，创建，输入ETN21的IP地址和端口号，端口号9600，如下：

点击连接，显示十六进制值打勾： 3、握手信号 TCP方式客户端需要发给服务器握手信号，等待服务器正常反馈表示握手成功，才能正常交流数据。客户端发出的命令格式如下：

服务器反馈的命令格式如下： 故sockettool发送命令为：46494E53（FINS）0000000C（长度12字节）00000000（命令代码）00000000（错误代码）000000D6（客户端节点号214），即： 46494E530000000C0000000000000000000000D6 46494E530000000C00000000000000000000003C

反馈是46494E53（FINS）00000010（长度16字节）00000001（命令代码）00000000（错误代码）000000D6（客户端节点号）00000003（服务器节点号） 通讯建立成功。 4、TCP命令 ①命令帧如下，ETN手册W421第7-4有相关介绍，如下： Fins 命令格式：

S7200_PPI通信协议

S7-200 PPI通信协议 PPI通信协议是一种主从式的通信协议，上位机即PC机为主，PLC为从。通信开始由计算机发起，PLC予以响应。 1）、计算机按通信任务，用一定格式，向PLC发送通信命令。 2）、PLC收到命令后，进行命令校验，如无误，则向计算机发送数据E5H或F9H，作出初步应答。 3）、计算机收到初步应答后，再向PLC发送SD DA SA FC FCS ED确认命令。 这里，SD为起始字符，为10H；DA为目的，即PLC地址02H；SA为数据源，即计算机地址00H；FC为功能码，取5CH；FCS为SA、DA、FC和的256余数，为5EH；末字节ED为结束符，也是16H。如按以上设定的计算机及PLC地址，则发送10、02、00、5C、5E、及16，6个字节的十六进制数据，以确认所发命令。 4）、PLC收到此确认后，执行计算机所发送的通信命令，并向计算机返回相应数据。它的通信过程要往复两次才完成一次的通信，比较麻烦，但较严谨，不易出错。 SD LE LER SD DA SA FC DASP SSAP DU FCS ED SD:(Start Delimiter)开始定界符，占1字节，为68H LE:（Length）报文数据长度，占1字节，标明报文以字节计，从DA到DU的长度； LER:（Repeated Length）重复数据长度，同LE SD: (Start Delimiter)开始定界符(68H) DA:（Destination Address）目标地址，占1字节，指PLC在PPI上地址，一台PLC时，一般为02，多台PLC时，则各有各的地址； SA:（Source Address）源地址，占1字节，指计算机在PPI上地址，一般为00； FC:（Function Code）功能码，占1字节，6CH一般为读数据，7CH一般为写数据 DSAP:（Destination Service Access Point）目的服务存取点，占多个字节 SSAP:（Source Service Access Point）源服务存取点，占多个字节 DU:（Data Unit）数据单元，占多个字节

modbus协议及modbus_RTU的C51程序

查看完整版本: [-- modbus协议及modbus RTU的C51程序--] 电子工程师之家-> 51单片机论坛-> modbus协议及modbus RTU的C51程序[打印本页]登录-> 注册-> 回复主 题-> 发表主题 一线工人2007-11-15 21:44 modbus协议及modbus RTU的C51程序 完整的程序请下载[attachment=1488] Modbus通讯协议 Modbus协议最初由Modicon公司开发出来，在1979年末该公司成为施耐德自动化(Schneider Automation)部门的一部分，现在Modbus已经是工业领域全球最流行的协议。此协议支持传统的RS-232、RS-422、RS-485和以太网设备。许多工业设备，包括PLC，DCS，智能仪表等都在使用Modbus协议作为他们之间的通讯标准。有了它，不同厂商生产的控制设备可以连成工业网络，进行集中监控。 当在网络上通信时，Modbus协议决定了每个控制器须要知道它们的设备地址，识别按地址发来的消息，决定要产生何种行动。如果需要回应，控制器将生成应答并使用Modbus协议发送给询问方。 Modbus 协议包括ASCII、RTU、TCP等，并没有规定物理层。此协议定义了控制器能够认识和使用的消息结构，而不管它们是经过何种网络进行通信的。标准的Modicon控制器使用RS232C实现串行的Modbus。Modbus的ASCII、RTU协议规定了消息、数据的结构、命令和就答的方式，数据通讯采用Maser/Slave方式，Master端发出数据请求消息，Slave端接收到正确消息后就可以发送数据到Master端以响应请求；Master端也可以直接发消息修改Slave端的数据，实现双向读写。 Modbus 协议需要对数据进行校验，串行协议中除有奇偶校验外，ASCII模式采用LRC校验，RTU模式采用16位CRC校验，但TCP模式没有额外规定校验，因为TCP协议是一个面向连接的可靠协议。另外，Modbus采用主从方式定时收发数据，在实际使用中如果某Slave站点断开后（如故障或关机），Master端可以诊断出来，而当故障修复后，网络又可自动接通。因此，Modbus协议的可靠性较好。 下面我来简单的给大家介绍一下，对于Modbus的ASCII、RTU和TCP协议来说，其中TCP和RTU协议非常类似，我们只要把RTU协议的两个字节的校验码去掉，然后在RTU 协议的开始加上5个0和一个6并通过TCP/IP网络协议发送出去即可。所以在这里我仅介绍一下Modbus的ASCII和RTU协议。

Siemens PPI协议分析

Siemens PPI协议分析 大家好：我是山东临沂的郝金红，由于前段时间的疯狂的研究西门子PPI协议解密之故，所以无心插柳的研究出了较实用的西门子S7-200 PPI协议，今天奉献大家。我们经常要用于上位机、现场设备与S7-200CPU之间的通讯，但是西门子公司没有公布PPI协议的格式，用户如果想使用PPI协议监控，必须购买其监控产品或第三方厂家的组态软件。大家要知道国内的组态王、紫金桥、力控等等组态公司是花了多少钱才得到的PPI的深层协议吗？其实西门子工控产品的超高价垄断掠夺行为已经引起了我们国家及业内人士的抵制和抗议，他们的什么软件都需要授权且对于系统的霸道性是有目共睹的。 这样给用户自主开发就带来了一定的困难，特别是想用VB、VC等语言自行开发，根本没办法接入PLC，要么你大把掏钱给他们。洋为中用，最近在国外网站得到一个串口监视软件，带协议分析的相当不错，你吧！我就是通过此软件的数据监视、分析方法，找出了PPI协议的关键报文格式所在。 其实西门子S7-200 PLC之间或者PLC与PC之间通信有很多种方式:自由口，PPI方式，MPI方式，Profibus方式。使用自由口方式进行编程时，在上位机和PLC 中都要编写数据通信程序。使用PPI协议进行通信时，PLC可以不用编程，而且可读写所有数据区，快捷方便。这也是我们之所以要研究、找出PPI协议的源动力！ 下面我们就要说说分析的方法了！ 西门子的STEP 7 MicroWIN 是用于S7-200系列PLC的开发工具，它使用PC机上的COM口通过一条PC/PPI编程电缆连到PLC的编程口上。这说明，PC实际上是可以通过串口同S7-200 CPU通讯。只是我们不知道通讯协议而已。通过截获PC机串口上的收发数据，对照Step 7软件发出的指令，我们就有可能分析出有关指令的报文和通讯方式；然后，直接通过串口向PLC发送报文，以验证这些指令报文是否正确。本着这一思想，我们采用以下步骤获得这些报文。

Modbus RTU通讯协议

要实现Modbus RTU通信， 一、需要STEP 7-Micro/WIN32 V3.2以上版本的编程软件，而且须安装STEP 7-Micro/WIN32 V3.2 Instruction Library（指令库）。Modbus RTU功能是通过指令库中预先编好的程序功能块实现的。 Modbus RTU从站指令库只支持CPU上的通信0口（Port0） 基本步骤： 1. 检查Micro/WIN的软件版本，应当是STEP 7-Micro/WIN V3.2以上版本。 2. 检查Micro/WIN的指令树中是否存在Modbus RTU从站指令库（图1），库中应当 包括MBUS_INIT和MBUS_SLAVE两个子程序。 如果没有，须安装Micro/WIN32 V3.2的Instruction Library（指令库）软件包； 1. 西门子编程时使用SM0.1调用子程序MBUS_INIT进行初始化，使用SM0.0调用 MBUS_SLAVE，并指定相应参数。 关于参数的详细说明，可在子程序的局部变量表中找到； 调用Modbus RTU通信指令库图中参数意义如下： a. 模式选择：启动/停止Modbus，1=启动；0=停止 b. 从站地址：Modbus从站地址，取值1~247 c. 波特率：可选1200，2400，4800，9600，19200，38400，57600，115200 d. 奇偶校验：0=无校验；1=奇校验；2=偶校验 e. 延时：附加字符间延时，缺省值为0 f. 最大I/Q位：参与通信的最大I/O点数，S7-200的I/O映像区为128/128， 缺省值为128 g. 最大AI字数：参与通信的最大AI通道数，可为16或32 h. 最大保持寄存器区：参与通信的V存储区字（VW） i. 保持寄存器区起始地址：以&VBx指定（间接寻址方式） j. 初始化完成标志：成功初始化后置1

什么是ModBusRTU通讯协议

什么是ModBusRTU通讯协议 Modbus协议最初由Modicon公司开发出来，在1979年末该公司成为施耐德自动化(Schneider Automation)部门的一部分，现在Modbus已经是工业领域全球最流行的协议。此协议支持传统的RS-232、RS-422、RS-485和以太网设备。许多工业设备，包括PLC，DCS，智能仪表等都在使用Modbus协议作为他们之间的通讯标准。有了它，不同厂商生产的控制设备可以连成工业网络，进行集中监控。 当在网络上通信时，Modbus协议决定了每个控制器须要知道它们的设备地址，识别按地址发来的消息，决定要产生何种行动。如果需要回应，控制器将生成应答并使用Modbus协议发送给询问方。 Modbus协议包括ASCII、RTU、TCP等，并没有规定物理层。此协议定义了控制器能够认识和使用的消息结构，而不管它们是经过何种网络进行通信的。标准的Modicon控制器使用RS232C实现串行的Modbus。Modbus的ASCII、RTU协议规定了消息、数据的结构、命令和就答的方式，数据通讯采用Maser/Slave方式，Master端发出数据请求消息，Slave端接收到正确消息后就可以发送数据到Master端以响应请求；Master端也可以直接发消息修改Slave 端的数据，实现双向读写。

Modbus协议需要对数据进行校验，串行协议中除有奇偶校验外，ASCII模式采用LRC校验，RTU模式采用16位CRC校验，但TCP模式没有额外规定校验，因为TCP协议是一个面向连接的可靠协议。另外，Modbus采用主从方式定时收发数据，在实际使用中如果某Slave站点断开后（如故障或关机），Master端可以诊断出来，而当故障修复后，网络又可自动接通。因此，Modbus协议的可靠性较好。 对于Modbus的ASCII、RTU和TCP协议来说，其中TCP和RTU协议非常类似，我们只要把RTU协议的两个字节的校验码去掉，然后在RTU协议的开始加上5个0和一个6并通过TCP/IP 网络协议发送出去即可。 （一）、通讯传送方式： 通讯传送分为独立的信息头，和发送的编码数据。以下的通讯传送方式定义也与ModBusRTU通讯规约相兼容： 初始结构= ≥4字节的时间 地址码= 1 字节 功能码= 1 字节 数据区= N 字节 错误校检= 16位CRC码

MODBUS-RTU通讯协议简介

MODBUS-RTU通讯协议简介 2008-10-10 17:27 1.1 Modbus协议简述 ACRXXXE系列仪表使用的是Modbus-RTU通讯协议，MODBUS协议详细定义了校验码、数据序列等，这些都是特定数据交换的必要内容。MODBUS协议在一根通讯线上使用主从应答式连接（半双工），这意味着在一根单独的通讯线上信号沿着相反的两个方向传输。首先，主计算机的信号寻址到一台唯一的终端设备（从机），然后，终端设备发出的应答信号以相反的方向传输给主机。 Modbus协议只允许在主机（PC，PLC等）和终端设备之间通讯，而不允许独立的终端设备之间的数据交换，这样各终端设备不会在它们初始化时占据通讯线路，而仅限于响应到达本机的查询信号。 1.2 查询—回应周期 1.2.1 查询 查询消息中的功能代码告之被选中的从设备要执行何种功能。数据段包含了从设备要执行功能的任何附加信息。例如功能代码03是要求从设备读保持寄存器并返回它们的内容。数据段必须包含要告之从设备的信息：从何寄存器开始读及要读的寄存器数量。错误检测域为从设备提供了一种验证消息内容是否正确的方法。 1.2.2 回应 如果从设备产生一正常的回应，在回应消息中的功能代码是在查询消息中的功能代码的回应。数据段包括了从设备收集的数据：如寄存器值或状态。如果有错误发生，功能代码将被修改以用于指出回应消息是错误的，同时数据段包含了描述此错误信息的代码。错误检测域允许主设备确认消息内容是否可用。 1.3 传输方式 传输方式是指一个数据帧内一系列独立的数据结构以及用于传输数据的有限规则，下面定义了与Modbus 协议– RTU方式相兼容的传输方式。 每个字节的位： · 1个起始位 · 8个数据位，最小的有效位先发送 ·无奇偶校验位 · 1个停止位 错误检测(Error checking)：CRC（循环冗余校验） 1.4 协议 当数据帧到达终端设备时，它通过一个简单的“端口”进入被寻址到的设备，该设备去掉数据帧的“信封”（数据头），读取数据，如果没有错误，就执行数据所请求的任务，然后，它将自己生成的数据加入到取得的“信封”中，把数据帧返回给发送者。返回的响应数据中包含了以下内容：终端从机地址(Address)、被执行了的命令(Function)、执行命令生成的被请求数据(Data)和一个校验码(Check)。发生任何错误都不会有成功的响应，或者返回一个错误指示帧。 1.4.1 数据帧格式 Address Function Data Check 8-Bits 8-Bits N x 8-Bits 16-Bits 1.4.2 地址（Address）域 地址域在帧的开始部分，由一个字节（8位二进制码）组成，十进制为0～255，

MPI协议和PPI协议有什么不同

竭诚为您提供优质文档/双击可除MPI协议和PPI协议有什么不同 篇一：通讯不同点 请教下大虾们，常说的总线有profibus、can、modbus、FF、devicenet等，这些是不是以走什么协议来命名的？那 我可以说：“它走can协议吗？”而常见的串口通信modbus,mpi, 据校验和。 在波特率一致、各站地址不同的情况下，ppi，mpi和pRoFibus可以同时在一个网络上运行，并且互不干扰。 这就是说如果一个网络上有s7-300、s7-200，s7-300 之间可以通过mpi或pRoFibus通信，而在同时在同一个网 络上的tp170如果在一个通信网络上存在其他主站（如td200，或者上位计算机等），同时需要进行micro/win的编程、监控，这就是多主站网络编程。 使用西门子的下列设备可以实现micro/win的多主站编程： micro触摸屏可以与一个s7-200cpu通信。 使用智能多主站电缆和micro/winV3.2sp4以上版本。

新电缆可以在网络上传递令牌，因而自动支持多主站网络编程。 如果使用cp卡，如cp5511/cp5512（笔记本电脑pcmcia 卡）、cp5611（台式机pci卡），能够支持多主站编程通信。 如果通过cp卡编程时，选择了mpi协议，注意mpi主站不能访问作为ppi主站的cpu。如果有第三方的产品要连接到多主站网络上，用户需要咨询第三方产品提供商以了解是否支持西门子的s7-200多主站网络。要进行多主站编程，不但编程计算机要支持，网上的其他设备也要有多主站通信能力。 早期的多主站连接依赖于计算机硬件和windows操作系统。随着计算机技术的发展，多数情况下已经不能做到多主站编程通信。建议用户使用西门子的多主站编程电缆或者cp 卡配合micro/win实现多主站编程通信。 4.mpi(multipointinterface)是simatics7多点通信的接口，是一种适用于少数站点间通信的网络，多用于连接上位机和少量plc之间近距离通信。 通过pRoFibus电缆和接头，将控制器s7-300或s7-400的cpu自带的mpi编程口及s7-200cpu自带的ppi通信口相互连接，以及与上位机网卡的编程口（mpi/dp口）通过pRoFibus或mpi电缆连接即可实现。网络中当然也可以不包括pc机而只包括plc。

Modbus+RTU+标准通讯协议格式

HLP_SV Modbus RTU 标准通讯协议格式 通信资料格式 Address Function Data CRC check 8 bits 8 bits N×8bits 16bits 1）Address通讯地址：1-247 2）Function：命令码8-bit命令 01 读线圈状态 上位机发送数据格式: ADDRESS 01 ADDRH ADDRL NUMH NUML CRC 注: ADDR: 00000 --- FFFF(ADDR=线圈地址－1)；NUM: 0010-----0040 (NUM为要读线圈状态值的二进制数位数) 正确时变频器返回数据格式： ADDRESS 01 BYTECOUNT DA TA1 DA TA2 DA TA3 DA TAN CRC 注: BYTECOUNT:读取的字数 错误时变频器返回数据格式： ADDRESS 0X81 Errornum CRC 注: Errornum为错误类型代码 如：要检测变频器的输出频率 应发送数据：01 01 00 30 00 10 3D C9（16进制） 变频器返回数据：01 01 02 00 20 B8 24（16进制） 发送数据：0030hex（线圈地址49） 返回的数据位为“0020”（16进制），高位与低位互换，为2000。即输出频率为 303（Max Ref）的50%。关于2000对应50%，具体见图1。

03读保持寄存器 上位机发送数据格式： ADDRESS 03 ADDRH ADDRL NUMH NUML CRC 注：ADDR: 0 --- 0XFFFF；NUM: 0010-----0040 (NUM为要读取数据的字数) ADDR=Parameter Numbe r×10-1 正确时变频器返回数据格式： ADDRESS 03 BYTECOUNT DA TA1 DA TA 2 DA TA 3 DA TAN CRC 注: BYTECOUNT:读取的字节数 错误时变频器返回数据格式： ADDRESS 0X83 Errornum CRC 如：要读变频器参数303的设定值 应发送数据：01 03 0B D5 00 02 95 BC （16进制） Parameter 303(3029)=0BD5HEX 变频器返回数据：“：”01 03 04 00 00 EA 60 B5 7B 返回的数据位为“00 00 EA 60”（16进制）转换为10进制数为60000, 表示303设置值为60.000 ※当参数值为双字时，NUM的值必须等于2。否则无法读取或读取错误。 05 写单个线圈状态 上位机发送数据格式： ADDRESS 05ADDRH ADDRL DA TAH DA TAL CRC 注：ADDR: 0 ---- 0XFFFF(ADDR=线圈地址－1)；DATA=0000HEX(OFF) OR FF00(ON) HEX 正确时变频器返回数据格式： ADDRESS 05 DATAH DATAL BYTECOUNT CRC 错误时变频器返回数据格式： ADDRESS 0X85 Errornum CRC 如：要使写参数为写入RAM和EEPROM 应发送数据：01 05 00 40 FF 00 CRC（16进制） 变频器返回数据：01 05 FF 00 00 01 CRC（16进制） 发送数据：0040hex（线圈地址65） 06 写单个保持寄存器值（只能写参数值为单个字的参数） 上位机发送数据格式： ADDRESS 06 ADDRH ADDRL DA TAH DA TAL CRC 注:ADDR: ADDR=Parameter Numbe r×10-1 正确时变频器返回数据格式： ADDRESS 06 ADDRH ADDRL DA TAH DA TAL CRC 错误时变频器返回数据： ADDRESS 0X86 Errornum CRC 如：要对变频器参数101写入1 应发送数据：01 06 00 03 F1 00 01 19 BD（16进制） 变频器返回数据：01 06 03 F1 00 01 19 BD（16进制） PARAMETER 101（1009）=03F1 HEX

Omron-Fins通讯协议

OMRON FINS 通讯 1. OMRON FINS 通讯 1.1 FINS 通讯概述 FINS(factory interface network service)通信协议是欧姆龙公司开发的用于工业自动化控制网络的指令／响应系统。运用 FINS 指令可实现各种网络间的无缝通信，通过编程发送FINS 指令，上位机或PLC 就能够读写另一个PLC 数据区的内容，甚至控制其运行状态，从而简化了用户程序。FINS 协议支持工业以太网，这就为OMRON PLC 与上位机以太网通信的实现提供了途径。 1.2 Fins 帧的结构 发送命令结构: 发送命令结构： 响应命令结构： 命令码： 01 01 读数据 01 02 写数据 结束码： 00 00 无错误，否则执行出错； 举例说明： 存储区代码（82代表D 区 80代表CIO 区） 当结束码不为00 00时，则代表执行错误，应重发当前帧。

2 FINS在以太网上的帧格式 Fins在以太网上帧格式比较简单，简单来说就是在上面所说的Fins帧的基础上加上以太网的包头就可以了。具体帧格式分为UDP/IP帧格式和TCP/IP帧格式。 2.1 FINS UDP/IP的帧格式 UDP/IP的帧格式：共10个字节，其名称如下： 其每个字节的具体解释如下： ICF:发送接收标志字节，发送报文：ICF=80HEX；响应报文：ICF=C0； RSV:固定为00HEX； GCT:固定为02HEX； DNA:目标网络号；本网络：00；远程网络：01-7F； DA1:目标节点号；对于以太网来说，即该网络IP地址最后一位的值； DA2:目标单元号；对于CPU来说，固定为00; SNA:源网络号；本网络：00； SA1:源节点号；IP地址最后一位的值； SA2:源单元号：可设置为与目标单元号相同； SID:服务ID，响应端将接收过来的SID复制后添加到响应帧中； 举例说明： PC IP地址：10.11.1.19 PLC IP地址：10.11.1.86 如果要请求DM10开始的10个字的内容 80 00 02 00 00 56 00 00 13 00 00 Data1—Data10

西门子PPI通讯协议

?西门子PPI通讯协议!看看吧! S7-200?PLC之PPI协议? ????通过硬件和软件侦听的方法，分析PLC内部固有的PPI通讯协议，然后上位机采用VB 编程，遵循PPI通讯协议，读写PLC数据，实现人机操作任务。这种通讯方法，与一般的自由通讯协议相比，省略了PLC的通讯程序编写，只需编写上位机的通讯程序资源 S7-226的编程口物理层为RS-485结构，SIEMENS提供MicroWin软件，采用的是PPI(Point?to?Point)协议，可以用来传输、调试PLC程序。在现场应用中，当需要PLC与上位机通讯时，较多的使用自定义协议与上位机通讯。在这种通讯方式中，需要编程者首先定义自己的自由通讯格式，在PLC中编写代码，利用中断方式控制通讯端口的数据收发。采用这种方式，PLC编程调试较为烦琐，占用PLC的软件中断和代码资源，而且当PLC的通讯口定义为自由通讯口时，PLC的编程软件无法对PLC进行监控，给PLC程序调试带来不便。SIEMENS?S7-200PLC的编程通讯接口，内部固化的通讯协议为PPI协议，如果上位机遵循PPI 协议来读写PLC，就可以省略编写PLC的通讯代码。如何获得PPI协议？可以在PLC的编程软件读写PLC数据时，利用第三个串口侦听PLC的通讯数据，或者利用软件方法，截取已经打开且正在通讯的端口的数据，然后归纳总结，解析出PPI协议的数据读写报文。这样，上位机遵循PPI协议，就可以便利的读写PLC内部的数据，实现上位机的人机操作功能。 软件设计 ?系统中测控任务由SIEMENS?S7-226PLC完成，PLC采用循环扫描方式工作，当定时时间到时，执行数据采集或PID控制任务，完成现场的信号控制。计算机的监控软件采用VB编制，利用MSComm控件完成串口数据通讯，通讯遵循的协议为PPI协议。 ?PPI协议 西门子的PPI（Point?to?Point）通讯协议采用主从式的通讯方式，一次读写操作的步骤包括：首先上位机发出读写命令，PLC作出接收正确的响应，上位机接到此响应则发出确认申请命令，PLC则完成正确的读写响应，回应给上位机数据。这样收发两次数据，完成一次数据的读写[5]。 其通讯数据报文格式大致有以下几类： 1、读写申请的数据格式如下： ? SD?LE?LER?SD?DA?SA?FC?DASP?SSAP?DU?FCS?ED?? SD:(Start?Delimiter)开始定界符(68H) LE:（Length）报文数据长度 LER:（Repeated?Length）重复数据长度 SD:?(Start?Delimiter)开始定界符(68H) SA:（Source?Address）源地址，指该地址的指针，为地址值乘以8 DA:（Destination?Address）目标地址，指该地址的指针，为地址值乘以8 FC:（Function?Code）功能码 DSAP:（Destination?Service?Access?Point）目的服务存取点 SSAP:（Source?Service?Access?Point）源服务存取点 DU:（Data?Unit）数据单元 FCS:（Frame?Check?Sequence）校验码 ED:（End?Delimiter）结束分界符（16H） 报文数据长度和重复数据长度为自DA至DU的数据长度，校验码为DA至DU数据的和校验，只取其中的末字节值。 在读写PLC的变量数据中，读数据的功能码为?6CH，写数据的功能码为?7CH。

MODBUS_RTU通讯协议

精品文档 . ?MODBUS通讯协议 使用手册

1. RTU 方式通讯协议 1.1. 硬件采用RS －485，主从式半双工通讯，主机呼叫从机地址，从机应答方式通讯。 1. 2. 数据帧10位，1个起始位，8个数据位，1个停止位，无校验。 波特率:9600;19200 38400 1.3. 功能码03H ： 读寄存器值 主机发送： 第1字节 ADR ： 从机地址码（=001～254） 第2字节 03H ： 读寄存器值功能码 第3、4字节 ： 要读的寄存器开始地址 要读FCC 下挂仪表， 第5、6字节 ： 要读的寄存器数量 第7、8字节 ： 从字节1到6的CRC16校验和 从机回送： 第1字节 ADR ： 从机地址码（=001～254） 第2字节 03H ： 返回读功能码 第3字节 ： 从4到M （包括4及M ）的字节总数 第4到M 字节 ： 寄存器数据 第M ＋1、M+2字节 ： 从字节1到M 的CRC16校验和 当从机接收错误时，从机回送： 第1字节 ADR ： 从机地址码（=001～254） 第2字节 83H ： 读寄存器值出错 第3字节 信息码 ： 见信息码表 第4、5字节 ： 从字节1到3的CRC16校验和 1.4. 功能码06H ： 写单个寄存器值 主机发送：

当从机接收正确时，从机回送： 当从机接收错误时，从机回送： 第1字节 ADR ：从机地址码（=001～254） 第2字节 86H ：写寄存器值出错功能码 第3字节 错误数息码 ： 见信息码表 第4、 5字节 ： 从字节1到3的CRC16校验和 1.5. 功能码10H ： 连续写多个寄存器值 当从机接收正确时，从机回送： 当从机接收错误时，从机回送： 第1字节 ADR ： 从机地址码（=001～254） 第2字节 90H ： 写寄存器值出错 第3字节 错误信息码 ： 见信息码表

Modbus通讯协议(TCP和RTU)

1MODBUS RTU 读寄存器请求序号意义所占字节字节存放格式 1从设备地址1个字节0x00?0xff 2功能码1个字节0x03 3起始寄存器基地址两个字节高字节在前 4寄存器个数两个字节高字节在前 5CRC校验码两个字节低字节在前 读寄存器回应序号意义所占字节字节存放格式1从设备地址1个字节0x00?0xff 2功能码1个字节0x03 3数据长度1个字节寄存器个数×2 4数据寄存器个数×2个字节每个寄存器高字节在前5CRC校验码两个字节低字节在前 写单个寄存器请求序号意义所占字节字节存放格式1从设备地址1个字节0x00?0xff 2功能码1个字节0x06 3起始寄存器地址两个字节高字节在前 4寄存器值两个字节　高字节在前 5CRC校验码　两个字节　低字节在前 写单个寄存器回应序号意义所占字节字节存放格式1从设备地址1个字节0x00?0xff 2功能码1个字节0x10 3起始寄存器地址两个字节高字节在前 4寄存器值两个字节　高字节在前 5CRC校验码　两个字节　低字节在前 1

写多个寄存器请求序号意义所占字节字节存放格式1从设备地址1个字节0x00?0xff 2功能码1个字节0x10 3起始寄存器地址两个字节高字节在前 4寄存器个数两个字节　高字节在前 5数据长度　1个字节　寄存器个数×2　 6数据寄存器个数×2个字节每个寄存器高字节在前7CRC校验码　两个字节　低字节在前 写多个寄存器回应序号意义所占字节字节存放格式1从设备地址1个字节0x00?0xff 2功能码1个字节0x10 3起始寄存器地址两个字节高字节在前 4寄存器个数两个字节　高字节在前 5CRC校验码　两个字节　低字节在前 错误返回序号意义所占字节字节存放格式1从设备地址1个字节0x00?0xff 2功能码1个字节请求功能码+0x80 3错误码1个字节　其代号见下面表格4CRC校验码　两个字节　低字节在前 错误代号错误代号意义 0x01不支持该功能码 0x02越界 0x03寄存器数量超出范围 0x04读写错误 2

SiemensPPI协议分析

编号：_______________本资料为word版本，可以直接编辑和打印，感谢您的下载 SiemensPPI协议分析 甲方：___________________ 乙方：___________________ 日期：___________________

大家好：我是山东临沂的郝金红，由丁前段时间的疯狂的研究西门子PPI协议解密之故，所以无心插柳的研究出了较实用的西门子S7-200 PPI协议，今天奉献大家。我们经常要用丁上位机、现场设备与S7-200CP比问的通讯，但是西门子公司没有公布PPI协议的格式，用户如果想使用PPI协议监控，必须购买其监控产品或第三方厂家的组态软件。大家要知道国内的组态王、紫金桥、力控等等组态公司是花了多少钱才得到的PPI的深层协议吗？其实西门子工控产品的超高价垄断掠夺行为已经引起了我们国家及业内人士的抵制和抗议，他们的什么软件都 需要授权且对丁系统的霸道性是有目共睹的。 这样给用户自主开发就带来了一定的困难，特别是想用VB VCC?语言自行开发，根本没办法接入PLC要么你大把掏钱给他们。洋为中用，最近在国外网站得到一个申口监视软件，带协议分析的相当不错，你'下裁吧！我就是通过此软件的数据监视、分析方法，找出了PPI协议的关键报文格式所在。 其实西门子S7-200 PLC之间或者PL必P&问通信有很多种方式：自由口， PPI方式，MP方式，Profibus方式。使用自由口方式进行编程时，在上位机和PLC 中都要编写数据通信程序。使用PPI协议进行通信时，PLW以不用编程，而且可读写所有数据区，快捷方便。这也是我们之所以要研究、找出PPI协议的源动力！ 卜面我们就要说说分析的方法了! 西门子的STEP 7 MicroWIN是用丁S7-200系列PLC勺开发工具，它使用PCL上的COI^通过一条PC/PPI编程电缆连到PLC勺编程口上。这说明，PCS际上是可以通过申口同S7-200 CPIffl讯。只是我们不知道通讯协议而已。通过截获PO申口上的收发数据，对照Step 7软件发出的指令，我们就有可能分析出有关指令的报文和通讯方式；然后，直接通过申口向PLCCc送报文，以验证这些指令报文是否正确。本着这一思想，我们采用以下步骤获得这些报文。 你首先下载上面那个英文的申口监控软件，英文不好的网友可以使用我们为你汉化的汉化包，替换原文件即可，你必须使用这个软件，因为我先前使用过很多的监控软件，在收发数据很多的情况下都有死机现象，造成数据丢失，容易给

很好的威纶通MODBUS RTU通讯协议与变频器通讯案例

本文研究的是触摸屏通过MODBUS RTU通讯协议与变频器通讯实现变频器的控制。触摸屏采用威纶通TK6070IP,变频器用汇川MD380通用系列。通过触摸屏编程软件，编辑控制画面实现变频器的启动、停止、速度调节、多段速速度设置，通过宏指令实现工程值与实际值的转换。 一、MODBUS RTU 简介： 为了在自动化系统之间、自动化系统和所连接的分散的现场设备之间进行信息交换，如今串行现场总线被主要用作通讯系统。成千上万的应用已经强烈地证明了通过使用现场总线技术，可以节省多至40％的接线、调试及维护的费用。仅仅使用两根电线就可以传送现场设备的所有相关信息，比如输入和输出数据、参数、诊断数据。过去使用的现场总线往往是制造商的特定现场总线，并且同其它现场总线不兼容。如今使用的现场总线几乎是完全公开和标准化的。这就意味者用户可以以最合理的价格选择最好的产品，而不用依赖于每个独立的制造商。Modbus RTU是一种国际的、开放的现场总线标准。作为一种很容易实现的现场总线协议，在全世界范围内，Modbus得到了成功的应用。应用领域包括生产过程中的自动化、过程控制和楼宇自控。MODBUS RTU通讯协议的报文如图1。 图1 MODBUS RTU 通讯协议的报文功能码如下： 01H 读取线圈状态。从执行机构上读取线圈（单个位）的内容； 02H 读取离散量输入。从执行机构上读取离散量输入（多个位）的内容； 03H 读取保持寄存器。从执行机构上读取保持寄存器（16位字）的内容； 04H 读取输入寄存器。从执行机构上读取输入寄存器（16位字）的内容； 05H 强置单线圈。写数据到执行机构的线圈（单个位）为“通”（“1”）或 “断”（“0”）； 06H 预置单寄存器。写数据到执行机构的单个保持寄存器（16位字）； 0FH 强置多线圈。写数据到执行机构的几个连续线圈（单个位）为“通”（“1”） 或“断”（“0”）； 10H 预置多寄存器。写数据到执行机构的几个连续的保持寄存器（16位字）。 二、威纶通编程软件介绍： EB8000软件中MODBUS协议的设备类型为0x、1x、3x、4x、5x、6x，还有3x_bit，4x_bit，6x_bit，0x_multi_coils等，下面分别说明这些设备类型在MODBUS协议中支持哪些功能码。0x：是一个可读可写的设备类型，相当于操作PLC的输出点。该设备类型读取位状态的时候，发出的功能码是01H，写位状态的时候发出的功能码是05H。写多个寄存器时发出的功能码是0fH。 1x：是一个只读的设备类型，相当于读取PLC的输入点。读取位状态的时候发出的功能码为02H。 3x：是一个只读的设备类型，相当于读取PLC的模拟量。读数据的时候，发出的功能码是04H。 4x：是一个可读可写的设备类型，相当于操作PLC的数据寄存器。当读取数据的时候，发出的功能码是03H，当写数据的时候发出的功能码时10H，可写多个寄存器的数据。

PPI MPI Profibus 通信协议详解

1、MPI是Multi-Point Interface,适用于PLC 200/300/400、操作面板TP/OP及上位机MPI/PROFIBUS通信卡，MPI网络的通信速率为网络才支持12Mbit/s的通信速率。MPI网络最多可以连接32个接节点，最大通信距离为50m，但是可以通过中继器来扩展长度。PPI协议是专门为S7-200开发的通信协议。S7-200 CPU的通信口（Port0、Port1）支持PPI通信协议，S7-200的一些通信模块也支持PPI协议。Micro/WIN与CPU进行编程通信也通过PPI协议。PPI是一种主从协议，主站、从站在一个令牌网。在一个PPI网络中，与一个从站通信的主站的个数并没有限制，但是一个网络中主站的个数不能超过32个。主站既可以读写从站的数据，也可以读写主站的数据。也就是说，S7-200作为PPI主站时，仍然可以作为从站响应其他主站的数据请求。 MPI是主站之间的通信；PPI可以是多台主站与从站之间通信。 2、MPI协议：西门子内部协议，不公开； PROFIBUS-DP协议：标准协议，公开。 3、MODBUS 是MODICON公司最先倡导的一种软的通讯规约，经过大多数公司的实际应用，逐渐被认可，成为一种标准的通讯规约，只要按照这种规约进行数据通讯或传输，不同的系统就可以通讯。目前，在RS232/RS485通讯过程中，更是广泛采用这种规约。 常用的MODBUS 通讯规约有两种，一种是MODBUS ASCII，一种是MODBUS RTU。 一般来说，通讯数据量少而且主要是文本的通讯则采用MODBUS ASCII规约，通讯数据数据量大而且是二进制数值时，多采用MODBUS RTU规约。 在实际的应用过程中，为了解决某一个特殊问题，人们喜欢自己修改MODBUS规约来满足自己的需要（事实上，人们经常使用自己定义的规约来通讯，这样能解决问题，但不太规范）。更为普通的用法是，少量修改规约，但将规约格式附在软件说明书一起，或直接放在帮助中，这样就方便了用户的通讯。 3. PPI，MPI和PROFIBUS都是基于OSI（开放系统互联）的七层网络结构模型，符合欧洲标准EN50170所定义的PROFIBUS标准，基于令牌的的网络通信协议。这些协议是非同步的（串行的）基于字符的通信协议，字符格式包括一个起始位、8个数据位、一个偶校验位和一个停止位。其通信帧包括特定的起始和结束字符、源和目的站的地址、帧长度和数据校验和。 在波特率一致、各站地址不同的情况下，PPI，MPI和PROFIBUS可以同时在一个网络上运行，并且互不干扰。 这就是说如果一个网络上有S7-300、S7-200，S7-300之间可以通过MPI或PROFIBUS 通信，而在同时在同一个网络上的TP170 如果在一个通信网络上存在其他主站（如TD 200，或者上位计算机等），同时需要进行Micro/WIN的编程、监控，这就是多主站网络编程。 使用西门子的下列设备可以实现Micro/WIN的多主站编程： micro触摸屏可以与一个S7-200 CPU通信。 使用智能多主站电缆和Micro/WIN V3.2 SP4以上版本。新电缆可以在网络上传递令牌，因而自动支持多主站网络编程。 如果使用CP卡，如CP5511/CP5512（笔记本电脑PCMCIA卡）、CP5611（台式机PCI