【万泉河】FB内的static静态变量是全局变量吗？

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

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

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

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

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

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

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

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

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

思考比什么都重要。 

当前投票已结束！

1.STATIC是全局变量

65(62.50%)

2.STATIC不是全局变量

39(37.50%)

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都要传送一堆不需要改变的参数，很麻烦、很没效率。