2 个CPU 之间通过Profibus 实现主从站之间的MS 通讯

实现Profibus 主从站之间的MS 通讯
通过图解，说明2 个CPU 之间通过Profibus 实现主从站之间的MS 通讯。
这个例子是结合某现场的实际情况来的，实际情况是在2 套300 系统之间进行数据通讯，
由于每个CPU300 都带有ET200M 从站，所以317 的主DP 口和315 的DP 口都只能是主站
而不能配置为从站。并且2 套系统之间距离较远，MPI 不行，于是就利用了317 的MPI/DP
口配置成DP 口来和315 通讯。
1.首先，在STEP 7 中新建一个Project，分别插入2 个S7-300 站。这里我们插入的一个
CPU315-2DP，作为主站；一个CUP317-2 作为从站，并且使用317-2 的第一个端口MPI/DP
端口配置成DP 口来实现和315-2DP 的通讯。

然后分别对每个站进行硬件组态：

首先对从站CPU317-2 进行组态：将317 的第一个端口MPI/DP 端口组态为PROFIBUS 类
型，并且创建一个不同于CPU 自带DP 口的PROFIBUS 网络，设定地址。

在操作模式页面中，将其设置为DP SLAVE 模式，并且选择“Test,commissioning,routing”，
是将此端口设置为可以通过PG/PC 在这个端口上对CPU 进行监控，以便于我们在通讯链路
上进行程序监控。下面的地址用默认值即可。

然后选择Configuration 页面，创建数据交换映射区。

这里我们创建了2 个映射区，图中的红色框选区域在创建时是灰色的，包括上面的图中的
Partner 部分创建时也是空的，在主站组态完毕并编译后，才会出现图中所示的状态。由于我
们这里只是演示程序，所以创建的交换区域较小。

组态从站之后，再组态主站。插入CPU 时，不需要创建新的PROFIBUS 网络，选择从站
建立的第二条（也就是准备用来进行通讯的MPI/DP 端口创建的那条）PROFIBUS 网络即可。
组态好其它硬件，确认CPU 的DP 口处于主站模式，从窗口右侧的硬件列表中的已组态的站
点中选择CPU 31X，拖放到主站的PROFIBUS 总线上，

这时会弹出链接窗口，选择以组态的从站，点击Connect 按钮，

然后进入Configuration 页面，可以看到前面在从站中设定的映射区域，逐条进行编辑
（Edit…），确认主从站之间的对应关系。主站的输入对应从站的输出，主站的输出对应从站
的输入。
至此，硬件的组态完成，将各个站的组态信息下载到各自的CPU 中。通过NetPro 可以看
到整个网络的结构图。

2.编写程序。
硬件组态完毕，下载，PLC 运行之后，数据并不会自动交换。需要通过程序来执行。在组
态中，input 和output 区域，也并不是实际硬件组态中的硬件地址，也就是说，input 和output
并不代表I/O 模块的地址和数据。但是映射区域组态用到的input 和output 地址，同时也占
用了I/O 模块的组态地址，就是说，映射区的地址和I/O 地址是并行的，不能重复使用。所
以最好在硬件的I/O 模块全部组态完毕之后再组态映射区。
映射区的数据交换是通过系统功能块SFC14（DPRD_DAT——Read Consistent Data of a
Standard DP Slave）和SFC15（DPWR_DAT——Write Consistent Data to a Standard DP Slave）
实现的。
SFC14 和SFC15 是成对使用的，一个发送一个接收，缺一不可。数据的通讯也是交互的，
可以相互交换数据。本例中，我们通过简单的数据来验证通讯结果。
首先，我们在程序中插入数据区DB1，前面我们只建立了2 个字（2Word）的映射区，于
是我们建立如下内容的DB1，为了查看的方便，DB1 的前半部分作为接收数据的存储区，

后半部分用作发送数据的存储区。

在317 和315 中我们插入同样的DB1，然后分别在OB1 中编写通讯程序。
315（主站）中的程序如下：

其中，程序的LADDR 地址，对应的是硬件的映射区组态时本站的Local Addr 中的地址，
从站的Local Addr 我们组态的是0，对应的Partner Addr 也就是主站的地址是4。需要注意的
是这里的地址是需要用16 进制的格式来表示的，我们组态时是用10 进制表示的。
完成之后，我们在各站中插入OB82、OB86、OB122 等程序块，这些是为了保证当通讯的
一方掉电时，不会导致另一方的停机。完成之后，将所有的程序分别下载到各自的CPU 中，
个站切换到运行状态，通过PLC 监控功能，设定数据之后，我们监控的结果如下：上面的
表格内容为主站315 的数据，下面的是从站317 的数据。

可以看到，两个站都分别将各自的DBB4—DBB7 数据发送出去并被另一方成功接收后存
储在各自的DBB0—DBB3 中。
验证中，我们将一个站的CPU 切换到STOP 状态，可以看到，另一个站的CPU 硬件SF
指示灯报警，但PLC 正常运行不停机。待该站恢复之后，报警自动消失。
扩展问题：
在一个站的CPU 掉站之后，另一个站的接收数据区显示的仍然是最后一次接收到的数据，
并且，即使在这种状态下，居然仍然无法修改该数据区内容。这样就存在一个问题，当前站
需要知道当前接收数据存储区的内容是否是实时的数据。如何判断。
大概思路：

方法1，用以前的方法，在每个数据接收周期开始前，将已接收数据清空。这样当接收周
期内接收不到新的数据时，就可以察觉到。但是问题是，SFC14 和SFC15 没有接收是否完
成、是否成功等标识位，并且，在接收不到新的数据时，原有数据不能修改。此方法不通。
方法2，通过别的方式方法检测两个站之间的通讯状态。心跳？
在SIEMENS 的官方文档中，有这样的描述：
主站：主站掌握总线中数据流的控制权。只要它拥有访问总线权（令牌），主站就可在
没有外部请求的情况下发送信息。在PROFIBUS 协议中，主站也被称作主动节点。
从站：从站是简单的输入、输出设备。典型的从站为传感器，执行器以及变频器。从站
也可为智能从站，入S7-300/400 带集成口的CPU 等。从站不会拥有总线的访问授权。从站
只能确认收到的信息或者在主站的请求下发送信息。从站也被称作被动节点。
另外，SIEMENS 对SFC14/15 的描述也分别是：用于读取Profibus 从站的数据/ 用于将
数据写入Profibus 从站。
根据这些描述，通过CPU 集成口通讯这种方式下，作为从站的CPU 应该属于“智能从
站”，但是SIEMENS 的描述中，却没有说智能从站和普通的从站之间有什么区别。那么根
据上面的主从站的描述，主站可以主动的获取到从站的数据，并可以自主的将数据写入从站；
而从站必须在主站的指令下获取或者发送数据。而在本例中，这些说法似乎无法成立。
本例中，SFC14、SFC15 是成对使用的，不论在主站上还是从站上，主从站之间的SFC14
和SFC15 必然是需要成对出现的。也就是说，任何一方没有SFC15 运行的的话，另一方的
SFC14 都读不到数据。而任何一方没有SFC14 的话，另一方的SFC15 发送出来的数据也无
人接收。至少从这点看来，看不出主从站有什么区别。不过，联想到以前曾经做过S7－300
和MM430 的Profibus 通讯，该通讯方式中，显然MM440 是作为从站出现的，所以在正确
组态之后，只需要在主站(CPU)中写好SFC14/15 即可，当然，MM440 中我们也写不进去程
序。那么在这种方式中，可以说是完全的遵守了SIEMENS 官方文档中的说法。同时也说明，
在“智能从站”这种方式下，并不遵守SIEMENS 官方文档中对从站的描述。
再次研究SFC14/15 的收发状态，发现，可能是因为数据的存在是过程映像中，所以只
要SFC15 发送过一次，数据即存在于过程映射中，SFC14 随时都从映像中读取数据，所以
存在前面说的，SFC14 运行过程中，是无法修改接收数据存储区的数据的。
脱离SFC14/15，而使用MOVE 方法的研究：
不使用SFC14/15，而是利用组态的时候产生的I/O 地址来传数据。根据创建过程映射区

时的组态信息，我们写写出了如下的程序：
在主站315-2DP 中：

其中，M 位的使用是测试程序的不同情况下使用的临时点，和本程序功能无关。

由此可见，在这种方式下，因为组态时组态的地址是系统的I 区和Q 区，所以是可以用
MOVE 来实现通讯的，但是同时也存在的问题是，这种方式下，通讯所用的I/Q 区占用了
S7-300 的系统区，而S7-300 的系统区可使用范围是有限的，所以在系统的实际I/O 模块较
多时，通讯的数据量将会变得更加有限。