西门子S7-200EM277通讯模块

西门子S7-200EM277通讯模块

        初步的试验所得出的结论，让我看到一丝曙光，然而就像黎明前总是伴随着黑暗，接一下来的一系列问题让我有些不知所措。

        在使用PUT/GET编程的时候，我想每一个工程师都会读一读在线帮助或者程序手册，去了解这两个功能块如何编程，尤其故障代码的含义。而阅读手册的时候，我又顺便了解BSEND/BRECV，以及USEND/URECV，这时候我会纠结这些功能块到底有什么区别？

        按照手册，BSEND/BRECV通信要建立连接，而USEND/URECV是*建立连接的，那么S7到底是什么妖魔鬼怪？一个协议可以随着心意变化，而不是固定的协议交换模式，这是个使我百思不得其解的地方。那么手册中所提到的S7协议，不是单一协议吧？也就是说BSEND/BRECV，USEND/URECV以及PUT/GET使用不同的S7协议，虽然它们都叫做S7协议。那么要如何测试呢？作为西门子的私有协议，如何找到答案呢？

        S7的PUT/GET Server侧，是不需要编写任何功能块的，而 BSEND/BRECV，以及USEND/URECV双方都是编写功能块的，那么PUT/GET Server侧不编程就可以实现通信是如何做到的呢？又是谁帮助它实现了S7的数据交换呢？

        因为300PLC手册中提到此通信发生在CCP，而此时400PLC作为客户端，编写的GET接收数据，是不是发生在时间片？因为手册中已经提到CPU循环周期的AP部分由若干时间片组成，而GET是编写在AP中的，那么400PLC中的GET的通信必然发生在时间片？可以肯定吗？

        如果300PLC侧接收数据，那么400PLC侧需要使用PUT指令来发送数据，在Wireshark中所看见的就是400PLC侧发出的S7报文，由300PLC接收，在300PLC内部是何时接收的，在哪里接收到的呢？如何证明300PLC是在CCP接收数据呢？那又如何证明400PLC使用PUT指令进行的通信发生在时间片呢？

        上述这些问题都是源于那个通信负荷默认20%的CPU属性这个参数，那么是针对所有该PLC的通信服务吗？根据手册，这个参数至少对于CCP产生的通信应该是无效的，尽管手册中的只言片语，通过上面的试验也可以确定CCP自成一体。那么除了AP，和CCP，CPU的整个循环周期时间就剩下PII和PIQ了。而PII和PIQ是在每一个循环周期开始刷新，用于IO数据刷新，保证数据一致性，那么20%只能作用AP吧？那它能影响哪些通信服务呢？西门子PLC推出了那么多的通信服务，例如TCP/IP，PROFINET IO等等受20%的参数控制吗？如果控制，那又如何作用呢？参数的大小调整会对通信服务产生什么样的影响呢？

        反复研读手册，手册会提到通信的地方，必然会提及数据一致性这个概念，那么数据一致性的真正意义是什么？什么时候需要注意呢？又如何注意呢？手册常常提到通信PLC可以保证具有一定的数据一致性长度，例如TCP的一致性是8K，为什么？为什么会有这样的限制？300PLC的S7通信常常会提到240字节的数据一致性，而S7 PDU也是240个字节，它们之间又有什么关联呢？

我们来思考一下，想象当时我的思考过程。首先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数据。

工程中，经常需要遇到一些需要循环累积的物理值，比如水的流量，电能等等。

而浮点数的累积是个公认的难题。

其中涉及到的简单的原理是，CPU对浮点数的表达是有精度限制的。通常一个32位的浮点数REAL，只能有7位数的精度。

在平常的数学运算中，这样的精度足够了。但在流量、电能等需要数值累加的场合，当累加值达到一定的程度，准确说是累加值和运行值数量级差出来1E7倍的时候，累加计算就会出问题了。

比方说需要12345678.0 和0.1累加的时候，你以为应该得到12345678.1，但因为表达精度限制，PLC的REAL数不能表达，得到的结果仍然是12345678.0 。而且一旦累积值过了这个限制，以后就永远不会增长了，我称之为加不进去了。

而其实都不需要到数量级差1E7倍，通常我们的模拟量都是有精度要求的，比如12位精度，累加的数值自己先带了4位数小数，所以当数值差到1E4的时候，运行中已经出现问题了，数据的低位的精度已经丢失掉了。在使用者看来，累积值精度不准了。

我们以往遇到有人咨询这样的问题的时候，通常给出的建议是累加的地方用双整数DINT来替换real，即在输入的地方累加数和运行值都放大一定的倍数，比如1000，并转化为DINT,然后累加，累加完成后，再将得到的结果转换为浮点数，然后除掉系数，得到正确的累加结果。

因为整数的相加总是准确没有误差的，所以累积过程中不会有错误。比方说上面的累加，虽然一次累加得到的12345678.1不能被正确表达，但10次以后, 数值进位到高位，得到12345679，就可以显示出来了。

但转换为整数，有一个问题，就是具体乘多少倍的倍数，又是个难题。针对项目中具体的物理量，还是容易些。比如瞬时流量的标定单位如果是100，那倍数3个0，而如果标定上线是10000，那倍数1个0即可。

但如果要做一个通用的标准块，就没那么容易了。总不能所有数值都不管三七二十一加5个0 ，那样浪费了精度之后终累加数据的容量还会不够用。况且，你提前不能知道物理量的量纲的话，说不定啥时候出来个需要加10个0呢？

所以，我就一直没能做出个标准的累加块来。一度想把倍数系数作为一个参数，调用时根据实际情况*，但也感觉实在太low了，还不如不做。

西门子S7-200EM277通讯模块