0815 【万泉河】一种在PLC程序中比较优雅地使用全局变量M的方法

有不少同行对我怀有深深的敌意。

起因是我在开始研究探索PLC标准化编程的阶段，发表过系列关于建议在PLC程序中尽量不要用全局变量M和T的文章。然后这些人出于自身理解力的原因， 就当成了我不允许他们写程序使用M， 到后来我搞成功了PLC标准化编程烟台方法，并开始对同行的工程师培训推广的时候， 这些人新账旧账一起算， 愤恨更大了。

按他们错误的理解， 我推行的是一种强制的编程规范， 这要是万一没抵挡住，被我推行成功， 那后面大家伙都有得苦日子。放着用着爽的不行的M变量放一边浪费不让用， 非得按他那一套劳什子烟台方法的办法来做程序。凭啥呢！

就好比林则徐禁烟，万泉河禁M变量， 这要是禁令得以推行成功， 不仅仅**， 恐怕香烟都抽不起了。

这固然是笑话，然而在有一大票同行中，是带有深刻印记的。 今年年初的时候， 就有位网友洋洋洒洒写了篇长文， 其中还拆了一台PLC， 把CPU中存储M的单元和V区的单元做了比较， 证明都是一样的内存区域，然后证明既然我允许你们用V区，就也该允许你们用M区。 理由翻来覆去就是一句话，既然PLC厂家给设计了这块内存区， 就是给我用的， 我就有十足的使用它的理由。 不让我用，我就冤曲，我就要满天下告御状。

文章发表后，很快成为热点文章，上百人在下面点赞留言，大呼痛快。在我看来颇有些河南村镇银行储户集体上访的味道了。 下面那些一个个点赞的小手，完全就是按的一个个的血手印啊！

然而， 他们自己理解偏差，却听不进看不懂我各种技术讲解。 那对我来说没啥错可言，自然也没啥可以道歉的了。

要说我没做好的地方呢， 是有的。 当时我摸索标准化架构，从功能强大的S7-1500入手， 在那里面完全可以轻轻松松实现不使用M和T。 忽略了大批栖息在小型PLC生态圈的同行的理解力。也不是我刻意忽略，当时的情况下，在起步阶段， 我能够探索在TIA PORTAL S7-1500 中实现完美架构，已经很侥幸了。 不管精力还是能力方面，都不能顾及小型PLC。甚至，其实，大部分的小型PLC我名字都没听说过，软件没用过，硬件更是没摸过了。 很多年里，我所摸过的小型PLC也只有西门子S7-200以及后来的改进升级版S7-200 SMART。

我在把所有主流PLC品牌的标准化开发工作都陆续完成，其实就是把我一套原本用西门子PLC做的标准化工程项目，分别移植到了其它各个主流品牌。掌握了在这些品牌之间快速移植程序的方法和能力。PLC方面的开发工作就基本停滞了，无事可做了。

直到大半年前， 因为各种原因，陆陆续续开始接触几个小型PLC的软件系统，对它们的架构做了些研究，更在最近发布了两篇文章，《0724 【万泉河】烟台方法前进之路：在信捷PLC中实现FB功能》，《0725 【万泉河】所有小型PLC也都能做标准化程序了》，正式宣布，烟台方法可以覆盖到包括所有已知的和未知的PLC型号和品牌了。

所以，也可以有些精力，对小型PLC中M变量的使用，做些总结，并给一些经验建议了。

这些经验来自烟台方法的标准化架构，然而只是其中的一点小的技术点。我只是针对当下的一个题目给出了建议，所以千万不要误以为下文给出的例子程序方法就是完整的烟台方法，更不要以此拿来抬杠。

我们来完整地阐述下在小型PLC中，在迫不得已，躲不开的情况下，不得不使用M变量的原则：

使用了M变量后，要求在自己或者继承者阅读程序的时候，不需要查阅交叉引用的方式检索变量的使用位置的方法才能读懂程序。

交叉引用是所有PLC都要具备的工具， 也成为所有PLC程序员长久以来阅读程序的利器。 然而， 一个程序如果写的足够好，就可以完全不需要使用它。 只要懂了程序框架结构，具体的程序功能按部就班读下来即可读懂。 甚至如果不理解架构，还是习惯性地祭出交叉引用，以试图通过其帮助发现线索的话，反而程序架构更是读不懂了。

更进一步，更优雅地使用M变量的姿势：一个程序模块（会被称作FC, POU, SBR , SUB等等）使用过M变量之后，应该不对使用的M变量造成污染。 即使用之前对使用的M区域的现场值做保护，使用完成之后离开时数据恢复原样。

就好比， 优雅的绅士一家人到一个风景优美的景区游玩，游玩过程中当然要有吃喝玩乐，有消费，然而离开时，会保护恢复原样，就像没来过一样。

那么， 对于一个PLC系统，假设其中有若干个模块单元，尽管未必是严格符合烟台方法的模块化，但总是大家各自心目中规划的模块。那么，不同的模块之间， 哪怕是使用了相同的M变量区域，也不会产生逻辑干扰。

由此可以实现，假如不同的模块来自不同的同事的分工合作， 那么事先做程序时，不需要规划和约定每个模块使用的M变量区域，不需要担心各自区域是否够用等等。

而一套两套三套系统调试完成后，下一个系统有可能从历史的若干个系统中分别挑选几个模块单元组合拼装为到新系统中来成为其中的模块， 那么除了物理IO点不可避免的必须逐个对照修改之外， 逻辑功能，以及协助实现逻辑功能的变量， 不应该需要修改。哪怕是最简单的替换修改都不需要，由此杜绝了修改过程中的疏忽带来的BUG。

实现的思路方法为：为每一个POU/SBR分配固定的存储区域，在SBR开始时，将本模块使用的M区域的数值备份到存储V区中，而在SBR临近结束之前，把备份的M数据恢复到M中。

存储区域的地址分配由程序自动完成，一旦分配，每次调用的地址固定不变，而具体的地址所有人并不需要知道， 也不需要记忆。 所以不需要提前规划。

程序自动分配每个POU的地址的依据来自每个POU的编号，即SID。 而这个SID应该可以由专门的程序功能块计算实现。 我在2022年初出过的编程题目：《【万泉河】征集FB的编程题：获取SID》，当时不理解应用场合的人，现在可以知道其需求了。

当然了， 在没有实现SID功能块之前，也可以简单每个块中累加实现，只不过整体程序结构少了一点点优雅，需要在OB1开始时对SID做个初始化的清零。

每一个POU开始时的前处理：

每个POU假设分配20个BYTE区域，前10个BYTE用于保存M数据的场景， 后10个用于退出时保存M数据在本模块内的数据值，这里规划VB10000以后的数据区用于存储这些场景值。 计算先得到了两部分数据的地址， 分别在LD50和LD54中，然后分别对M数据的保存和恢复。

而在POU逻辑功能结束， 临近退出时， 则做后处理：

 当下块对M区的数值保存，恢复到之前保存的场景。并在最后对SID编号递增。

而中间的段落， 则可以尽情使用这些M区的变量， 而不需要担心干扰了。

如果你是一个系统的规划架构师， 你只需要把这个程序的架构交给属下的工程师，然后他们只需要借助这个程序架构，完成的程序模块，所有系统之间都可以互换借用。简单方法就接近实现了模块的标准化。

这与一些工厂传统以来的方法， 给每一个项目，每一个模块，不厌其烦地分配M区域地址，0-10， 11-20， 21-30，是不是优雅睿智多了？

上面的演示，数据区有一些浪费支出， 即LD50部分的数据，其实在个POU之间是重复的，完全可以使用同一段数据区。 如果觉得有必要，可以另外再规划实现的方法。

量化数据来了，以Smart ST40（0AA0）为例

以M0.0、V0.0、V1000.0作对比

放置指令足够多，稀释其它因素的运行时间，假设扫描周期就是指令运行时间。

1、M0.0

LD M0.0

= M0.0 // 组成一个指令对

放置5000对（共10000条指令），编译后程序大小约20K。

100个扫描周期累计，共224ms。

每对指令时间=224*1000/（100*5000）=0.448us

2、V0.0

LD V0.0

= V0.0 // 组成一个指令对

放置3500对（共7000条指令），编译后程序大小约21K。

100个扫描周期累计，共230ms。

每对指令时间=230*1000/（100*3500）=0.657us

3、V1000.0

LD V1000.0

= V1000.0 // 组成一个指令对

放置2000对（共4000条指令），编译后程序大小约20K。

100个扫描周期累计，共150ms。

每对指令时间=150*1000/（100*2000）=0.750us

总结：

以V0.0为运行速度100%

变更为M0.0时，速度快46%

变更为V1000.0时，速度慢14%。