0225【万泉河】一种PLC程序中使用M全局变量的方法

看到题目， 肯定立马有人会跳着杠起来了：你万老师不是反对PLC程序中使用M变量的吗，这怎么还明目张胆地教起人用M变量了？

是的，反对用M变量的是我， 纵容人使用M变量的也是我。

我自己做的PLC项目，当然可以完全绕过使用M变量。 这在我分享给学员们的学习资料中千百次地得到了验证。 没有一个学员从程序中发现了一个M变量，而跳出来找我索赔的。

所以，所有学员， 以及懂一些计算机基本编程原理的同行都知道， 使用M变量的程序实在太LOW， 有太多的后患。

这是一个基本的常识。

然而也有一些学员，在讨论时会羞羞答答地表示，自己还会酌情用一部分M变量。 主要的原因为自己懒， 因为用M变量实现一些特殊比较便捷。

我当然可以表示理解，在工期紧张，现场调试工作量大的情况下，被迫无奈特殊环节使用一点M变量也是有情可原的。 我当然不可能跟着所有学员追杀到他们的工程项目，勒令他们整改。 这本来也不在我的职责与权限之内呀！

所以我提出, 你图便捷省事，要使用M变量，允许。 但我可以教给你们一个用起来不那么糟糕混乱的方法。

即为本文的内容。

何为糟糕混乱呢？有学员就抱怨， 从网上别人处付费购买过的库函数，里面竟然使用了M全局变量！还好是没有密码保护的，程序块插入到PLC后编译打开时直接看到变量下面红色波浪线提示。

我自己也经常遇到这样的程序，包括有国外著名自动化公司制作的库函数，打开之后也是一片红色。 那在不了解这个库函数的使用方法之前， 一定是蒙逼的。

所以非常反感见到这样的库函数。还装模作样以库的形式归档打包，弄得以为封装地多完善似的。 真还不如发出的直接是原始项目呢！

这样的程序库函数，对作者自己其实也比较难受。 因为有波浪线的存在，所以分享的时候就无法加密以实现知识产权保护。 否则别人拿库函数去用的时候，编译都通不过， 自然也没法使用了。

有的时候加密的目的还不完全是不让人看到，而可能是为了保护程序代码不被轻易篡改。 比如一个研发工程师做的程序块， 应用到现场，现场调试的是职级比较低的同事，就不希望他们随便更改核心的逻辑算法。那么加密码保护是一种令人比较放心的作法。

同事在现场调试中出现了故障，开发者在协助诊断时就不必担心问题出在核心模块被动过了。

有人可能会提出：用参数接口啊！

是的， 把使用的变量做成参数放到接口上，调用的时候分配实参，确实可以解决这个问题。 然而， 要知道函数的接口是非常宝贵的，是用于正常的功能参数的。 这种因为程序功能强加到参数接口而多出来的参数，会导致函数调用中异常难用。想想看比如这个FB如果要被调用100次，每次中都还有部分管脚固定分配了某个变量，M0.0, M0.1….那也是相当恶心的。

同比之下，倒还不如直接放到程序里面呢！

我给出的方法是， 在FB库函数中，需要使用M变量的地方，用一个FC替代。 FC内部使用M变量，把值送到OUTPUT管脚输出。FB中通过获取FC的OUTPUT管脚的值，得到了需要的M的状态。

这里还是以FirstScan 为例。

当然， 我以前有些过文章如何不使用S7-1500系统变量而实现FirstScan功能。其实二者在细节上还是有一些差别。所以这里做出来，我自己未来有机会时也可以用到。

首先， CPU中设置了系统变量字， 因而生成了变量符号。

建立FC:  GetFirstScan

然后FB程序中调用这个FC， 并将其输出管脚绑定到FB中所建立的TEMP变量：

这样核心算法FB中就成功得到了需要的M变量的值， 而逻辑中却没有使用M变量。

这样，如果需要加密， 则只需要加密FB，而FC保留公开，如此简单的逻辑，随便委托怎样的新手，都不会改错。

然后建立起对FB的实例调用：

查看整个程序的调用结构：

系统的调用结构从高到低依次为：

OB--FC--FB--FC

其中被夹在夹心层的FB是核心的逻辑算法功能， 而内外两层的FC皆为简单的，可以公开分享的应用。

继而尝试把上面做的FB发布到项目库中，会自动将连带的FC也归档了，得到如下提示：

提示内容即为本文所要解决的问题。

而且，也说明， 老外在做他的所谓库函数的时候，也肯定被提醒过，看到过这个提示。