1011 【万泉河】优化编程第二弹：MODBUS通讯字符串

我很欣慰， 又发表了一篇标志性意义的雄文《0923 【万泉河】换个视角看TIA PORTAL 数据块的优化和非优化》

掀起了主张PORTAL编程中全面使用优化方法的潮流。 请大家记住这个时间，2024年国庆节前， 然后过些年后，大家看一下当时的行业现状，再回过头看看我今天提出的这一主张又提前了多少年。

就有人不乏醋意的评论道：遥遥领先，又自以为是的遥遥领先了！我说，嗯，谢谢大家给面子，谢谢行业的其他大神都松弛懈怠不进步，或者有了成果后也不总结为观点发布， 总之又被我一不小心占了先机。而至于领先多少， 还是取决于同行的捧场， 如果对方永远不进步，即便到退休也不到这个层级，那就又是一辈子了。

然后只有跟在后面叮错别字， 指望着发现一个错别字，就可以对文章所有观点全盘否定，然后就试图实现把我拉回到和你们一样的一事无成，没有成果，没有自己观点的平庸，然后就以为自己赢了。 这也可以，我会不断的留一些破绽的，满足一些人的欲望。

文章发表后， 有人在后面表达支持，虽然不多，足够了。再多还显示不出那么先进性，我还没那么高兴呢！

后来为了补充验证，又发了一篇《0929 【万泉河】TIA PORTAL 优化模式的S7通讯实现》，主要讲解了在优化模式下， 通讯用到的variant类型的数据，可以用复杂数据类型的符号寻址绑定实参，也仍然可以正常运行。

其实还有一个相似但更为复杂一点的问题，比如有人提问如何用MODBUS通讯传递字符内容？

所以在前一篇做的TCP全双工通讯功能上做个演示实现。

实验思路很简单，2个通讯任务，首先将字符串STR1的内容通过MODBUS传送给MODSIM模拟器的数据区，然后再运行第2个任务把同一批数据读回到PLC中字符串STR2中。那么只要STR1中预设了内容， 通讯成功后，STR2中会得到与STR1同样的内容。

使用前一篇文章实现的FB块，调用直接将STR1绑定到BUFF管脚，惊奇地发现可以直接成功：

MODSIM中显示的数据：

这些字符显然就是预设字符”YANTAI”所对应的ASCII码，比如有2个A，所以里面有2个41

然而这与我以前的认知是不符的，检查发现，原来是因为调用的FB的类型不知何时不经意被设置为了非优化。 所以本质上STR1和STR2数据区是非优化数据。

而在将FB改为优化之后，再次下载运行，显示为：

报错误16#818B。

正确的通讯的数据区需要是byte数组，数据区中增加了2个数组：

并在2次任务的前后分别增加了数据格式序列化和反序列化的转换：

则可以顺利实现数据的转换和通讯。

总结：

Serialize序列化和Deserialize这一对函数是优化函数，非必须用非优化数据对接，而且它们就是我们用来处理数据优化数据类型的。 把复杂数据序列化成一个数组，然后用于通讯，这在计算机编程中也经常遇到。 相当于C语言编程中的RAWDATA。 而且我相信，如果通讯的对接方是电脑， 那么对方也应该用RAWDATA来对接的。

（回顾一下PORTAL中哪一个版本开始具备了这一对函数的？那就是PORTAL全面支持了全优化编程的起点）

在顺利完成字符串的通讯传递之后，我们自然而然地会想到还可以用来传送中文字符。 很简单， 只需要把字符串类型改为WSTRING即可。 只要通讯双方使用的同一种字符编码方式，那么字符内容就可以正确显示。 而我们实验用的本机，自然也不会有错误。

然而，这里需要喊一个大大的停！

我这里用的是PORTAL V16，为了中文这部分测试，我曾经一度把S7-1200CPU干崩溃了！报错误：

然后再不管是恢复出厂， 升级固件，CPU都不能正常，把我郁闷到真以为CPU坏掉了。

只不过后来又用V19升级了固件， 再后来又回到V16，下载正常的程序， 才正常了。 而这段对中文字符的序列化，我不敢搞了。

不过，我猜， 这应该只是V16中的BUG， 有可能在更高的版本比如V19中，已经解决了。 但我不敢试了。

有勇敢者可以试一下。

代码即：

#POS := 0;

#RET:=Serialize(SRC_VARIABLE := #WSTR1, DEST_ARRAY => #ARR1, POS := #POS);

这篇文章做的例子仍然会发布到烟台方法知识星球，星球居民可以同步下载实验学习验证。