0329 【万泉河】SMART 200中拆分提取字符串内数据

0329  【万泉河】SMART 200中拆分提取字符串内数据

         

文章《0323 【万泉河】 最难还是模拟量》中提到，我在做模拟量处理模块时，留了一个未解决的难题，一个小尾巴。即因为程序块中使用的TEMP变量资源已经耗尽，所以被逼无奈使用了一个全局变量MD20，做了数据的传递功能。

         

然后做好了之后，我就去做PID模块的移植了。

         

对那里面留下的缺憾，其实我并不怎么着急。 模块化的设计工作就是这样，有遗憾不可怕。 可怕的是遗憾太多，牵扯到整个系统架构， 牵一发而动全身，导致不敢动。

         

而我留下的这种遗憾则无所谓，我只要心中随时留个念想， 一旦有找到好的思路后，回来打个补丁，修复一下也就完美了。 而即便没有打补丁之前，也不影响正常的使用。 这种问题，终究不是大问题，连bug都算不上。 只是完美主义者心中的一个结而已。

         

然后，我在做PID模块的时候，很快就遇到了相似的问题。 原本，按照西门子LBP的数据结构，我原本是可以轻松解决的，资源完全够用。 因而这段时间都在做这部分的调试了。

         

但当调试结束，发现了一个问题，长久以来西门子以及众多同行都忽视的问题。

         

即，PID的输出值的量纲的问题。

         

通常，很多模块都直接以%为单位，或者没有单位，就0-1的一个小数数值了。

         

这在阀门开度等工况时是没问题的，然而很多的PID的输出回路会是变频器，变频器的运行开度，100%对应的是50Hz，那么，如果你在窗口上显示PID回路的输出时，如果仍然以0-100来显示，操作人员使用中就会有些不方便。总要做数值的换算。 一不小心还容易遗忘，算错。

         

所以，我决定要增加这部分的数值输入。 然而就同样遇到了变量使用超标了。

         

想到了这部分的数据在内部程序块中只使用一次，并不总是参与数值计算。同时，模块在调用时，输入的是常量，在运行中也不会变动。 所以，可以考虑用字符串的形式输入。

         

即， 把原本的UNIT的管脚，改名为RANG_UNIT， 包含了上下限和量纲：

0;10;Bar;0;50;Hz

         

字符串中使用分号;将所有数据分割。

         

S7-200中的字符串，在定义到子程序的管脚时，长度只有4byte，所以它本质上只是个指针。 而作为常量的字符串输入时，则不占用任何寄存器资源。

         

所以，编制了一个对字符串分割的函数Split

         


每次调用， 只读取指定的位置的数据。 我也顺便做了转换，即可以读取到字符串放到S1指定的指针，也可以顺便转换为浮点数输出到寄存器中使用。

         

由此，用一个字符串指针4BYTE替代了原本的多个浮点数，程序块的资源终于省出来了。



我在几个周之前， 还分享过一个做BCC校验的程序块，使用场合我没讲。 其实，也是出自同样的原因。

         

在LBP原程序架构中，需要多次校验HMI上数据序列的修改，在数据满足变化或者不变化条件时做出逻辑处理。 在PORTAL中的方法是直接对UDT进行相等比较。 所以在数据区中建立了大量的数据备份。

         

而对于SMART这样的小身板，自然是没那么多资源来存放所有数据的备份的。 所以就想到了使用BCC校验来做。数据序列中任何一个数值如果修改，都会导致BCC校验码不通过，纵然理论上会有某种巧合导致BCC相同，但几率又是小到火星撞地球，而且又是与人机界面人工操作相关，并不关乎安全，可靠性要求也不高。 所以可以以此节省规模不菲的变量资源。

算是对数据校验的另一种另类应用。 关于相撞的几率，我还没算过。与浮点数的表达规则有关，可以单独再研究。 不过未来即便有更严谨的应用场合，我们还可以多个校验算法，比如BCC和CRC校验同时上阵，估计就想撞也撞不到了。

         

我在前一篇文章《0327  【万泉河】论算法在PLC控制系统中的重要性》中，探讨了通常意义的线性变换，PID，飞剪，卷曲等算法对我们做PLC编程的重要性并没多高，甚至都可以认为不是我们这个行业的必备的算法技能。

         

然而如果非要找一些算法功能的话，这里提到的拆分和校验，以及所实现的数据处理交换方式，某种程度上可以算做是了。

         

而且还会通用，多种模块类型中都会遇到。

有需要研究学习的同行可以加我微信索取。