西门子S7-200EM223CN模块

西门子S7-200EM223CN模块

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

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

其中涉及到的简单的原理是，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了，还不如不做。

        也许这时候，大家可能会疑惑前面都在谈如何使用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执行结束后，时间片继续与该通信缓冲区交换数据。

西门子S7-200EM223CN模块