1、实现 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 站。这里我们插入的一个CPU31
2、5-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 进行监控，以便于我们在通讯链路上进行
3、程序监控。下面的地址用默认值即可。然后选择 Configuration 页面，创建数据交换映射区。这里我们创建了 2 个映射区，图中的红色框选区域在创建时是灰色的，包括上面的图中的 Partner 部分创建时也是空的，在主站组态完毕并编译后，才会出现图中所示的状态。由于我们这里只是演示程序，所以创建的交换区域较小。组态从站之后，再组态主站。插入 CPU 时，不需要创建新的 PROFIBUS 网络，选择从站建立的第二条（也就是准备用来进行通讯的 MPI/DP 端口创建的那条）PROFIBUS 网络即可。组态好其它硬件，确认 CPU 的 DP 口处于主站模式，从窗口右侧的硬件列表中的已组态的站点中
4、选择 CPU 31X，拖放到主站的 PROFIBUS 总线上，这时会弹出链接窗口，选择以组态的从站，点击 Connect 按钮，然后进入 Configuration 页面，可以看到前面在从站中设定的映射区域，逐条进行编辑（Edit ） ，确认主从站之间的对应关系。主站的输入对应从站的输出，主站的输出对应从站的输入。至此，硬件的组态完成，将各个站的组态信息下载到各自的 CPU 中。通过 NetPro 可以看到整个网络的结构图。2.编写程序。硬件组态完毕，下载，PLC 运行之后，数据并不会自动交换。需要通过程序来执行。在组态中，input 和 output 区域，也并不是实际硬件组态中的硬件地址，
5、也就是说，input 和output 并不代表 I/O 模块的地址和数据。但是映射区域组态用到的 input 和 output 地址，同时也占用了 I/O 模块的组态地址，就是说，映射区的地址和 I/O 地址是并行的，不能重复使用。所以最好在硬件的 I/O 模块全部组态完毕之后再组态映射区。映射区的数据交换是通过系统功能块 SFC14（DPRD_DATRead Consistent Data of a Standard DP Slave）和 SFC15（DPWR_DATWrite Consistent Data to a Standard DP Slave）实现的。SFC14 和 SFC15
6、是成对使用的，一个发送一个接收，缺一不可。数据的通讯也是交互的，可以相互交换数据。本例中，我们通过简单的数据来验证通讯结果。首先，我们在程序中插入数据区 DB1，前面我们只建立了 2 个字（2 Word）的映射区，于是我们建立如下内容的 DB1，为了查看的方便，DB1 的前半部分作为接收数据的存储区，后半部分用作发送数据的存储区。在 317 和 315 中我们插入同样的 DB1，然后分别在 OB1 中编写通讯程序。315（主站）中的程序如下：317 中的程序如下：其中，程序的 LADDR 地址，对应的是硬件的映射区组态时本站的 Local Addr 中的地址，从站的 Local Addr 我们
7、组态的是 0，对应的 Partner Addr 也就是主站的地址是 4。需要注意的是这里的地址是需要用 16 进制的格式来表示的，我们组态时是用 10 进制表示的。完成之后，我们在各站中插入 OB82、OB86、OB122 等程序块，这些是为了保证当通讯的一方掉电时，不会导致另一方的停机。完成之后，将所有的程序分别下载到各自的 CPU中，个站切换到运行状态，通过 PLC 监控功能，设定数据之后，我们监控的结果如下：上面的表格内容为主站 315 的数据，下面的是从站 317 的数据。可以看到，两个站都分别将各自的 DBB4DBB7 数据发送出去并被另一方成功接收后存储在各自的 DBB0DBB3
8、中。验证中，我们将一个站的 CPU 切换到 STOP 状态，可以看到，另一个站的 CPU 硬件 SF指示灯报警，但 PLC 正常运行不停机。待该站恢复之后，报警自动消失。扩展问题：在一个站的 CPU 掉站之后，另一个站的接收数据区显示的仍然是最后一次接收到的数据，并且，即使在这种状态下，居然仍然无法修改该数据区内容。这样就存在一个问题，当前站需要知道当前接收数据存储区的内容是否是实时的数据。如何判断。大概思路：方法 1，用以前的方法，在每个数据接收周期开始前，将已接收数据清空。这样当接收周期内接收不到新的数据时，就可以察觉到。但是问题是，SFC14 和 SFC15 没有接收是否完成、是否成功等
9、标识位，并且，在接收不到新的数据时，原有数据不能修改。此方法不通。方法 2，通过别的方式方法检测两个站之间的通讯状态。心跳？在 SIEMENS 的官方文档中，有这样的描述：主站：主站掌握总线中数据流的控制权。只要它拥有访问总线权（令牌） ，主站就可在没有外部请求的情况下发送信息。在 PROFIBUS 协议中，主站也被称作主动节点。从站：从站是简单的输入、输出设备。典型的从站为传感器，执行器以及变频器。从站也可为智能从站，入 S7-300/400 带集成口的 CPU 等。从站不会拥有总线的访问授权。从站只能确认收到的信息或者在主站的请求下发送信息。从站也被称作被动节点。另外，SIEMENS 对
10、SFC14/15 的描述也分别是：用于读取 Profibus 从站的数据 / 用于将数据写入 Profibus 从站。根据这些描述，通过 CPU 集成口通讯这种方式下，作为从站的 CPU 应该属于“智能从站” ，但是 SIEMENS 的描述中，却没有说智能从站和普通的从站之间有什么区别。那么根据上面的主从站的描述，主站可以主动的获取到从站的数据，并可以自主的将数据写入从站；而从站必须在主站的指令下获取或者发送数据。而在本例中，这些说法似乎无法成立。本例中，SFC14、SFC15 是成对使用的，不论在主站上还是从站上，主从站之间的SFC14 和 SFC15 必然是需要成对出现的。也就是说，任何一
11、方没有 SFC15 运行的的话，另一方的 SFC14 都读不到数据。而任何一方没有 SFC14 的话，另一方的 SFC15 发送出来的数据也无人接收。至少从这点看来，看不出主从站有什么区别。不过，联想到以前曾经做过 S7300 和 MM430 的 Profibus 通讯，该通讯方式中，显然 MM440 是作为从站出现的，所以在正确组态之后，只需要在主站(CPU)中写好 SFC14/15 即可，当然，MM440 中我们也写不进去程序。那么在这种方式中，可以说是完全的遵守了 SIEMENS 官方文档中的说法。同时也说明，在“智能从站”这种方式下，并不遵守 SIEMENS 官方文档中对从站的描述。再
12、次研究 SFC14/15 的收发状态，发现，可能是因为数据的存在是过程映像中，所以只要 SFC15 发送过一次，数据即存在于过程映射中，SFC14 随时都从映像中读取数据，所以存在前面说的，SFC14 运行过程中，是无法修改接收数据存储区的数据的。脱离 SFC14/15，而使用 MOVE 方法的研究：不使用 SFC14/15，而是利用组态的时候产生的 I/O 地址来传数据。根据创建过程映射区时的组态信息，我们写写出了如下的程序：在主站 315-2DP 中：在从站 317 中：其中，M 位的使用是测试程序的不同情况下使用的临时点，和本程序功能无关。由此可见，在这种方式下，因为组态时组态的地址是系统的 I 区和 Q 区，所以是可以用 MOVE 来实现通讯的，但是同时也存在的问题是，这种方式下，通讯所用的 I/Q 区占用了 S7-300 的系统区，而 S7-300 的系统区可使用范围是有限的，所以在系统的实际 I/O 模块较多时，通讯的数据量将会变得更加有限。
