0526 【万泉河】来自技术前沿的战报：IEC61499中没有全局变量了

我上周在朋友圈中转发了一个公众号《IEC61499》中的一篇文章：

《从IEC61131-3到IEC61499迁移的陷阱识别与评估》

转发到朋友圈的原因是我自己需要做个记号， 留在今天引用。

里面有2条非常重要的消息，我在文中划线了。 其他的读者或者我的朋友应该可以看到我画的线。在我看来是绿色实线，你们看到的应该是绿色虚线。

其中一条的内容：

全局和访问变量的缺失：IEC 61131中使用全局变量进行POUs之间的通信，而IEC 61499中没有等效的全局变量。

这很有意思，简直把我乐坏了。  

不管是IEC61131还是IEC61499，与我们使用PLC的PLC工程师来说，关系其实不大的。 这些国际标准，约束（或者是建议）的对象是那些开发PLC系统的开发者，而我们只是使用者。 所以产品中如果支持IEC61131， 那么我们就被动使用IEC61131标准，而如果支持IEC61499了，那么我们就被动使用IEC61499。

所以，我们是断然没有任何能力和理由去研究IEC61131和IEC61499的。 比如IEC61499已经面世了近20年，然而市面上并没有什么真正支持这个新标准的产品和软件面世流通，所以假设你在20年前就早早学习了解掌握了， 以目前的趋势再过10年，IEC61499也并不会完全取代IEC61131成为行业主流， 那么你根本没有机会遇到有IEC61499的产品， 那么这项技能就永远无用武之地。 因为假如即便20年后它流行起来，20+20=40 ， 大概率情况下你的工作年龄已到，你已经退休了，就彻底没机会用到了。

所以，这条消息的真伪我们都没必要去翻看标准原文消化鉴定，我只需要简单相信，假设其为真即可。

然后，这条消息就让我觉得很可乐。 可口可乐。

我在2008-2009年左右，首次提出了PLC编程中不要使用全局变量M和T的建议，并将这一条作为鉴别程序好坏的标准。

然而，惹了行业众怒。

无数同行因此恨死我了，在他们的认知里，我的建议等同于禁止他们使用M和T，并由此哭诉：人家PLC产品里分明设计了M和T， 你却不让俺们用， 你有能耐去跟厂家说，让厂家不要在系统里预留全局变量啊！

这种人连建议和禁止都分不清，连前提条件都不能理解。当然这个前提条件叫做好程序，好程序之外就只能叫垃圾程序，而他们没有掌握不用全局变量能力，如果承认，就等同于承认自己的程序全部都是垃圾程序，这太让他们难堪了。

后来有一个人揭竿而起，明确跳出来跟我拆台唱反调，他竟然拆了一台PLC，并写文章指出来其中的某一部分的内存单元：这里就是M。然后众多郁闷不得志的同行们终于扬眉吐气了， 不必在我的断言阴霾下委屈生存了。这不亚于让我看了一场鲜活的闹剧。  

这个作者的名字我无暇记忆，与他也毫无恩怨。 他自己做的事，历史自然会给他一个记忆。当然，记忆最深刻的还是他自己。 我不知道过20年后，IEC61499成为主流之后， 他还有没有勇气拆一台新款PLC， 找一找主板上还有没有内存单元， 能不能找到他永远相爱的M。

时间过的可真快，2008年到现在2025年， 已经17年了。 再过不消3年，我约定的20年的领先期限就要到了。 不晓得3年后，广大的同行们能否普及实现了PLC编程中不用M，难道非要再过20年，等市场上的PLC主流产品都基于IEC61499，都压根不再支持M的时候，才去被动掌握不用M的技能吗？

就像是我同时提及的时间继电器T， 在TIA PORTAL流行之后， 同行们郁闷的发现，原来用得爽到飞起的时间继电器T不存在了， 不被支持了，而只能被动使用IEC定时器了， 然后因为技能本身没有提升， 只能被迫忍受IEC定时器的缺点：消耗IDB多， 每用一个定时器，就要占用一个背景数据块IDB。其实根源在于其编程方法没有升级，还是在旧的面向过程编程的FC架构下叙事，那就只能忍受这种痛苦了。

我不知道实现了IEC61499之后，大家又会想出来咋样的变通方法，然后又多了一样需要忍受的细节。 在那些标准制定者看来，垃圾程序就像打不死的小强，它们总会找到变通的通道。

我在前一篇小作文《0521 【万泉河】一年一度的烟台方法研讨会结束了》中引用并致敬了电影台词：

“如果要有一个事情留在这个世界上让很多人记住你，你才是真正的一直活着。”

对我自己来说，留给世界上的可以让人记住的，不仅仅是烟台方法， 还有更早的不用M和T理论，这值得我毕生骄傲。

然而，却又不可避免有人想越位超车，直接不承认这一点，他们会宣称，这早就是世人皆知的常识，你这样往自己身上揽功劳很不要脸！我反而认为这样的态度很不要脸。 皇帝的新装里面，世人皆知皇帝光着屁股。 然而第一个指出来皇帝没穿衣服的是某个穷人家的小男孩，而不是皇帝和皇帝的宠臣们。人家小男孩说出来之后再说什么我早就知道的，就只能是不要脸了。

不要脸到啥程度呢？看看他们如何被我戏耍的团团转的过程就知道了：

我跟他们讲， 真正的不用M和T的程序很值钱，你完全可以提炼脱敏一下， 拿出来作为案例售卖，即便没有信心开到5000元，也至少可以卖2500，1500， 500，258。

然而他们又见招拆招应对说：PCS7的程序里面就没有M和T。---反正就是主打一个嘴硬。

这是因为我告诉他们的，我分享过一套我自己用PCS7简单生成的程序，删掉了CFC源代码之后，发了出来。 里面没有M和T。

然后他们在不去亲自验证的情况下，把这一条当成了真理。 尽管我反复建议，PLC工程师学习了解PCS7很重要，很有用。但他们没有学习动力，所以只会跟在我后面鹦鹉学舌。

而其实我没告诉他们的是， PCS7的程序里面，当系统足够庞大， 逻辑足够复杂的时候， PCS7编译时会自动给程序分配M点，用作POU之间的通信。

所以，一套PCS7的例子程序并不值钱，我最早开价10元绝对对得起它的价值，也对得起购买学习者。

再次重申一下， M点的定义是全局变量，所有全局变量包括全局数据块都在这个范围。 西门子之外的PLC， 如果全局变量内存区不叫M和DB，会叫GLOBLE VARIABLE（全局变量）等，也都是。

当然，一直以来我没有把“用”的概念讲清楚。 你在程序中读取了一个来自系统参数的全局变量，或者将某些运行数据写入到全局变量用于保存记录或者用于数据报表， 那些都是可以接受的。 准确的“用”的概念是那篇介绍IEC61499的原文中所述：“用作POU之间的通信”。

当然， POU的概念就不需要有歧义了。 不同的PLC中叫法不一样，但都是程序模块的意思，比如POU , SUB, SBR, PB，FC等等，在PORTAL中即FC。

【万泉河】为什么PLC程序中不要用M和T，为什么要推广PLC编程标准化？

从IEC61131-3到IEC61499迁移的陷阱识别与评估