昨天跟zane版主通了一个电话。

   

起因是我写了一篇文章【万泉河】PLC系统变量的作用域和生存期.pdf，想咨询下他对我文章的看法。 

一聊，还真有。 除却复杂章节的不算， 一个最底层的认知分歧是FB函数里面的static静态变量，算不算全局变量。

   

zane认为它是全局变量， 因为它和所有的全局数据块内的变量一样， 可以被外部访问，完全等同于全局变量。

   

而我认为不是。 因为在我看来，它只是能被跨周期记忆的内部变量，纵然能被外部访问， 也只是被允许而已。 西门子随时可以在未来发布的新版软件中， 宣布这些变量对外部访问隐藏， 不再运行被访问。

   

至少， 我倒是很希望未来的PORTAL软件增加一个功能， 就是我在设计FB块时，可以选择某个STATIC变量是否对外部访问可视。就像现在有功能可以设定是否被HMI访问一样。 那样， 我在调用某个FB的实例的参数的时候， 不必越过一大堆我根本不想访问的无用的内部变量。

类似这样的， 超长的， 鼠标总也拉不到底的选择框。

现在， 把问题抛给大家来选择：

这是十多年来，我和zane为数不多的观点不一致之处。 所以大家也不必担心哪一个完全对， 哪一个完全错。也不需要骑墙式两边都不得罪的既是又不是。 只需要仔细思考， 做出你倾向性的选择即可。 

思考比什么都重要。 

Static是全局数据块。而且外部访问还挺有用。

比如，生产线的配方数组，只需要复制到那个FB中，In接口不变，就改变了生产线的参数、系数。如果调整了这些系数，也是复制回去即可。

如果相同的FB，不同的背景DB，还得修改程序才能增加一种配方。而这样只增加个DB而已。

本胖支持老万。

从static的生命周期来看，把他理解为全局变量也无不可。

铁证来了。 

看看官方口径是怎么说的吧，注意Function Blocks。

当然是全局的了，静态变量是存在背景DB里的，变量只要是存在DB里，不管是背景DB还是共享DB都可以全局访问的。

嘿嘿。你说的没错，配方、参数是需要其他的单独DB保存；只是传输到背景DB中作为当前运行参数。

对于通过接口传输 和 直接访问背景DB，其实这两者是有差异的。

通过接口传输，好处是它是显性的，一看便知。但每次循环扫描都会执行。DB数据总是最新的。

而直接访问（包括 HMI ）则缺点是隐性的。但程序可以在指定的状态下，背景DB与配方参数DB交换数据。

它所带来好处是：给用户带来了一个确认与Cancel的机会（保留维持原配方参数）。

 目前来看，共享DB和实例DB就读写来说，差别不是太大，基本一样。

但是，我们应该只把共享DB当作全局变量来使用，实例DB最好还是像C语言里面的静态变量一样，只在相应的FB中使用，这也是实例DB应该扮演的角色。

说不定以后实例DB也想c语言一样，不允许在外部读写了呢。

看4楼截图中 有人说背景数据块的静态变量不能被自己的FB调用?

我不太明白，在FB内部，访问自身静态变量，使用数据块+变量名的方式，没觉得有什么问题。

和万泉河通了电话后，我查了一下手册，STEP7和博图的，

S7的数据是这么定义的： 

1.全局数据 与 局部数据  两大类

2.全局数据为 M，全局DB，T，C

3.局部数据分为  局部静态数据   临时数据

（在定义方面，我认为两者没有太大的区别，博图的定义更加明确一些）

4.在STEP 7里直接了当地就告诉说局部静态数据可以被外部程序同全局DB一样访问，但风险自担

5.但在博图对静态数据的访问的描述就相当的暧昧了

    首先是鼓励用数据块及静态数据而不是用M/T，这和万侠的主张一致

    其次告知局部静态数据可以被外部程序同全局DB一样访问，但又不建议这么做，说有风险

    第三主张通过数据接口及多重背景实现数据的交换，但又怕造成多次数据交互造成的重复与浪费，不这么做那就是外部直接访问静态数据效率最高了

我还是比较同意shine的说法，简单点，就当全局变量用就是了。

我理解就是：M，全局DB，T，C。之外的都不是全局变量。satatic虽然全局能用也是中转的变量类型不固定，感觉还是与全局变量有区别。

我的观点就是static类型和全局DB在使用上可能基本上一样，但人为的被分了类。这就是说，从概念上说，他们是不同的。所以，我支持老万，老万现在着魔一样的在追求标准化，我也很支持，虽然我人为要用标准化来一统天下可能性不大，但这种追求还是很好的，我也希望有一天能成功。如果按照标准化的思路，那么这个static类型，就必须不是全局变量了，因为它是在FB里面声明的。

其实，wincc直接访问static数据，有时感觉很方便，比如：PID那个FB41，直接访问可以不用在管脚上另外加变量了，还能省内存。完全可以当成全局变量来用。但我一般情况下，在程序里面（step7）里面，尽量避免直接使用static中的数据，会另外给管脚加变量，使用这个变量。起码，这样的程序好好读。

就是这么定义的标准规范，这话题跟问井盖要做成yuan的还是方的好一样。实质就是绝对地址，FB获得封装后甚至加密，static变量可能会被fb内部逻辑改写值变的好象不可控，用户主动去改写staic的值甚至会破坏fb原有的正常逻辑。

有道理！

我觉得如果只对static变量进行读操作，而不进行写操作，应该是没有风险的；

如果要进行写操作，还是单独拿出来做管脚比较好。

不会吧。出问题还是程序写的有问题吧。

看看西门子自己提供的库程序，例如：MODBUS TCP，不也是封装、加密的？但把原来放在接口的参数，放到背景数据块里了么？还有许多设置，不也是要求去背景数据块里设置么？还有些西门子提供的FB功能库，参数不也是需要外部去背景数据块中读取么？

为什么从接口改到背景数据块中？就是每次调用不需要都传送。

所以，就像这些标准库一样，每次调用都有可能发生改变的，放在接口；仅在特定状态下才需要改变的，就放在背景数据块中。封装、加密后，不允许改变的的就是灰色的，允许外部设置、读取的就是白色。

一个大的功能块，使用者，特别是首次使用的人很难辨别哪些参数是可以改的。我说的变的好象不可控是使用者的一个心理状态。接口是预留给用户使用的，static是开发者不希望被用户改动的东西，但是有的时候为功能块接口看上去什么的简洁，不得不把一些接口放到static

其实，我觉得问题不大。

对于所使用的Statics 写好注释就可以。使用者打开背景数据块，就能知道哪些不要动；哪些需要设置。

其他原设计HMI可访问性都是勾选好的。封装后，用户也改不了。

总觉得，每次调用个FB都要传送一堆不需要改变的参数，很麻烦、很没效率。

【万泉河】设备的设定参数&&数据块的运行值

https://mp.weixin.qq.com/s/lMEy8bQ_XFoFLV407bv6lw

@yming @宁超 其实你们在聊的是参数。 我上一篇文章先写过了。 

 @李岩 @宁超 @liucs_2009 @yming

与外部设备通讯的数据必须是全局数据，WINCC能访问静态变量，就说明静态S7的静态变量有全局属性，WINCC能访问临时变量吗？

你们觉得为了避免外部程序直接读写静态变量，应该把变量做在接口上，请问是输入还是输出？如果我的变量在FB内部有程序干预，同时也允许外部程序干预，风险自担嘛，那它应该是什么接口？输入_输出吗？如果是，那输入_输出接口上的变量就是全局变量，如果只在输入或输出接口，那根本就无法实现，你们可以试试。

有多少西门子提供的库程序的FB，除了需要填写FB的管脚（输入输出）之外，我们还要看手册，看一些内部变量的定义，我们需要在FB块之外去直接读写其中的内部变量，这些内部变量都是静态变量。如果一个FB功能块的变量都要体现在其输入输出管脚上，那是灾难性的。

西门子用计算机的术语定义了FB的局部静态变量，但是在实际编程的工程需求上我们对静态变量的读写存在着各种复杂的需求，又不得不赋予其全局变量的属性，我觉得这是明智的，这样才有我们目前灵活多变的编程方法。

 在SIEMENS培训课程A1482的资料中，有一面专门讲到了局部变量，FB中的静态变量应该是属于局部变量。如图所示：

全局变量，但是使用的时候要当作局部变量来使用。

不能在其他的程序里面对FB的静态变量进行写，但是可以读。

什么是黑？什么是白？人的定义一样，就如同时间，这个是人类发明定义的。

说他是全局变量，是因为他可以全局用，

说他是局部变量，是因为他是针对FB的背景DB。但是我们用FC+专有的DB（如同FM350-1高度计算块一样，指定一个DB）效果不是一样吗？。

这个问题，其实zane、老万说的都对。看了楼上诸位老师们的讨论，本胖突然想到发生在自己身上的一件事：

    有一条本胖开车，胖嫂坐在副驾驶位。前面的车流很拥堵，但右边一条车道前面没车，本胖一打方向，从右侧车道直接开到了前面的路口。胖嫂对本胖说：你走的是公交车道，等着扣分、罚款吧。我朝的摄像头真不是盖的，果然扣分罚款了。

    上面的小事说明了啥？说明这个“公交车道”也是道，就算不是公交车，也是能在上面走的。但本胖却被扣分罚款了，这说明这个公交车道在某些时间段还是不够安全的。

    引申一下，就算是没用扣分、罚款，那么就是安全的吗？为啥要设置公交车道呢？索引，本胖觉得FB背景数据块里面的static数据类型，跟公交车道一样，不是不能用，而是要尽量遵守规则。规则就是不能在本FB之外调用。但俺说的是尽量，wincc里面用一下，俺觉得可以算是擦边球。

如果“静态变量 - 只能在FB中使用” 那就不能全局访问。反之，可以全局访问，那它就是全局变量。

1200/1500博图编程与 300/400 STEP7差异就是：它不用绝对地址。因此，在博图中，背景数据块中的静态变量，与其他全局DB没有性质上的差异。

曾经也试过用接口 inout 传送配方、参数。方法是 建立数组DB，固定其数组0 与 FB 交换数据。这时，每次调用，数组0的数据总是最新的。HMI 也与数组0打交道。需要的时候，保存到原来的数组 n 中。

尽管这样也行，但是要在外部做 确认与取消。数组的类型 有时还得做成UTD，反而觉得更麻烦。

后来发现，西门子提供的许多 FB功能块，只把常用的（每次调用都要使用的）做在接口上，不常用的、设置类型的，放在背景DB的静态变量中。再后来发现，西门子提供的封装功能块FB接口越来越简单，像原来放在接口上的IP地址呀，端口呀，PID的参数呀，都“收”到其背景DB的静态变量中了。

另外，像驱动的 Drive 功能块，常用的都是控制字、状态字，好多都是位操作。接口使用位Bool。当我使用8/8PZD时，这功能块接口成什么样了？对于那些简单应用来说（启动、停止、速度给定）使用它，还要带一波没用的参数，烦不烦呀。

（尽管可以使用默认参数）

所以这种功能块，还是仅将常用的做成位Bool，其他的也只是传送字。你还得外部将它们分解成位。

甚至有些功能块的诊断状态，还得从其背景数据块中取得。

 静态变量虽然可以全局使用，但本质上还是局部变量

“所以，我的意思是：静态变量在定义上是归入局部变量的，但它可以全局使用。”

非常同意这句话，一句话就说到本胖胃里去了。