西门子S7-200CP243-1通讯模块

西门子S7-200CP243-1通讯模块

这是个复杂的题目吗？所有接触过的人都认为很简单啦！长时间来，我自己也一直这么认为的。
   
可今年两次遇到的奇葩的故事，促使我不仅把这段技术写出来，还要提前发布了。
   
还是先讲故事。
   
9月份的时候帮一个公司做事，要去现场的时候，老板说还有一个现场WINCC和S7-200通讯原本好好的， 突然坏掉了，希望先顺路帮修复一下。然后就去了。
   
打开电脑一看， PC ACCESS的软件有安装，但没有配置PCA文件。问一下现场工作人员，说原本有做好的，但不小心搞坏了，没有备份。
   
我说，那问题也不大，S7-200的程序有吗？
有，在PLC里面可以上传上来。
   
要带符号表的源程序。
没有。
   
那当时PC ACCESS的配置表从哪儿做的？
上位机的组态工程师一个字一个字敲出来的。
   
然后我直接晕掉了，只能答复：这事我帮不了，你们自己重新想办法吧！
   
先遇到的是S7-200的， 然后上周，又再次遇到了一次几乎一模一样的故事，只不过CPU换成了SMART 200。
   
应该怎么做呢？核心一条，OPC变量不能手动建立，得从plc程序导过来！

        也许这时候，大家可能会疑惑前面都在谈如何使用PUT/GET来证明是否发生在时间片还是CCP，而这里就使用了PG来证明呢。其实道理很简单，主要考虑两方面的因素，一是前面提到PG与300PLC通信发生在CCP，而400PLC发生在时间片，二是继续使用PUT/GET的方式进行测试有点繁琐，没有使用PG做的简单。主要是为了验证M100.1是否置位。其实重要的是还是运气，当时想着看看PG测试如何，换个角度和方法是不是取得意想不到的效果。

        在PG的变量监控表中，添加MW10，MW0，M100.0以及M100.1，无论对于300PLC还是400PLC，变量表也是一样的。当使能M100.0，以及设置MW0=100，那么就以为这延时1秒钟的程序启动了，延时程序的启动，意味着当PG修改MW10的数值为1时，这个数值传递给PLC时，应该都在这个1秒钟的时间跨度内，因为除去延时程序，前后剩余的程序的运行时间可以忽略不计。所以按照概率计算的话，这是一个非常大的概率事件，MW10在这段时间内进入到PLC中。

        那么当看到后结果时，所有的问题感觉就烟消云散了。当MW10修改为1时，400PLC中的M100.1会被置位，在多次的测试中，置位的次数也是非常多的，偶尔也会出现不被置位的情况，这意味着MW10的数值被PLC读取没有发生在演示程序之间，而是正好发生在两端。而300PLC的M100.1不会被置位。这就说明当MW10的数值进入到CPU时，如果发生在延时程序中，对于400PLC，MW10和MW12比较必然不同，这就意味400PLC与PG的这种通信发生在时间片，而300PLC由于发生在CCP，即使MW10的数据已经进入到CPU，但是并没有进入程序，在某个缓冲区等待中，当CCP执行时，CCP就会把MW10的数据读取到，重新执行到下一圈程序时，MW10会把这个数值传递给MW12，这就会使MW10和MW12的数值永远相同，也就是M100.1不会被置位，这就证明300PLC与PG的这种通信发生在CCP。

        那么我就在我的笔记本上做个小结吧，从CPU的循环周期来看，包含4个部分，分别是PII，PIQ，AP，CCP。AP由若干个时间片构成，通信也是时间片的一部分，也就是说通信发生在时间片，在具体说CPU对于Partner数据的读写发生在时间片，当数据进入到CPU的通信缓冲区中，暂且我们不知道这个缓冲区在哪里，甚至叫什么名字。当时间片包含通信时，就会立刻对该缓冲区的数据进行读写，这种通信速度理论上是更加快速的，而CCP的通信，需要等到CPU的一个循环周期结束时，CCP才对该数据缓冲区进行读写，这样的通信相对来说是慢速的，参考上述的PG实例也能够体会出来。而且由于CCP它是神秘的，手册中的描述不多，但是可以看到它的运行时间并不长，对于整个循环周期的占比也不大，那么CCP的通信数据也不会太多，所以手册中所提到的PUT/GET Server的数据一致性从原来的64B提升到240B，也就是只有CPU的性能提升了，这部分的通信能力才得到提升，从中也可以看出西门子一代代PLC的版本提升，不仅仅是firmware的提升，还包括了硬件的升级。在这里需要强调的是1500和400的通信行为相同，从中可以看出1500的底层框架应该是源于S7-400PLC。

        谈S7-300PLC，是因为它是全面参数的PLC，几乎开放了所有的参数给用户去设置，因为它相对S7-400和S7-1500较低端，参数的开放有利于用户去优化各种性能，例如：通信。那么更多的提到S7-300，有助于理解这些参数，理解PLC的通信以及通信的底层原理。

        此外，还要特别强调一下S7-1500的通信行为的特殊之处，因为通信的**级是15，那么当出现更高**级的OB时，通信就会被抑制，或者说当通信发生时，存在多个时间片要对数据进行读写时，有更高**级的OB出现时，数据读写就会停止，直到该OB执行结束后，时间片继续与该通信缓冲区交换数据。

我们来思考一下，想象当时我的思考过程。首先300PLC手册中提到S7 PUT/GET server交换数据发生在CCP，而300PLC并没有程序，那么CCP这个部分就承担数据交换的功能。既然CCP做了这个功能，而CCP是每个PLC循环周期必须处理的部分，那么数据的接收和发送是周期性的，周期时间就是300CPU的循环周期。而400PLC中的PUT发送是按照400CPU的循环周期进行的，那么这样一来是不是PUT就在时间片中进行的呢？先不考虑时间片，那么这个400PLC中的PUT在这里测试的意义就不大，只需要400PLC中保留GET即可，这时查看数据是否按照300CPU的循环周期进行发送到400CPU。

        既然按照这个思路，那么就需要设置CPU的循环周期尽量的大一些，因为这样在Wireshark中的抓包可以按照时间排序辨认清晰，能够判断是否数据的发送是按照周期进行的。于是我需要思考如何可以把CPU的周期尽可能的延长。

        通过查找手册，WAIT指令就可以实现这个功能，延长CPU的循环周期。然而WAIT的延时时间单位是微秒，而我需要肉眼可见的时间延时，那么就需要使用LOOP指令，循环多次调用WAIT即可。编写的程序如下：

A M100.0

JCN jmp

L MW0

Next: T MW2

CALL “WAIT”

WT:=10000

L MW2

LOOP next

jmp: NOP 0

        简单解释一下这个程序，这段程序放到OB1即可。M100.0的作用就是是否我们要调用这个延时程序，如果M100.0为1，则启用延时程序。WAIT延时的单位时间设置了10ms，如果设置MW0为100，那么终实现的延时时间就是100x10ms=1000ms，即1秒。这里需要注意的是CPU属性页中的扫描循环监控时间需要设置**过1秒，这里设置大值，即6秒。这样避免在启动延时程序后，CPU发生停机现象。顺便说一下，大家在*大讲堂里面看的程序也是这个，这个程序可以作为一个模板，放到程序的任何一个地方去做测试，这段程序的用途非常广泛，除了测试PLC高级通信，也可以用于测试其它地方。例如，用于测试Profinet RTA的报警响应。这段延时程序非常非常非常有用，因为让时间慢下来，你会看到通信的具体动作。

        试验的结果终验证了这些假设，在Wireshark中可以看见每隔1s钟，会出现一个S7的数据报文，在DB块的数据中，修改DBB0，DBB10,例如AA，BB，可以在报文中看见这些数据变化，更加证明了这些数据就是300PLC发送给400PLC的S7数据。

西门子S7-200CP243-1通讯模块