出现问题的原理：

当数据块在优化访问模式时，DB变量作为输入输出参数，对其进行访问。
在此情况下，数据是用复制模式传送的。运算数据复制后，即使数据未改变，也会在数据块结尾处再次写入回该数据。因此，在数据块过程中HMI系统写入的数据会丢失。

西门子手册：

2.6.5优化和非优化访问的块之间的参数传输

当将结构作为输入/输出参数（InOut）传输到被调用块时，它们默认作为引用传输

但是，如果其中一个块具有“优化访问”属性而另一个块具有“默认访问”属性（我翻译一下，就是FB块和IN/OUT的形参数据一个为优化访问快，一个为非优化访问快），则情况并非如此。在这种情况下，所有参数通常作为副本传输（参见第3.3.1章按值调用）。

在这种情况下，被调用块始终使用复制的值。在块处理期间，这些值可能会更改，并且在处理块调用后将它们复制回原始操作数。

如果原始操作数被异步进程（例如，被HMI或中断OB访问）更改，这可能会出问题。如果在块处理之后将复制的值复制回原始操作数，则原始操作数上异步执行的更改将被覆盖。

实际编程问题：

1513 CPU，

建立一个FB1块（优化访问块），一个IN/OUT接口 ,UDT_AA；

建立一个DB10块（非优化访问快，UDT_AA）DB变量作为输入输出参数

我通过WINCC 或者PLC的监控与强制表，去操作DB块，那么由于调用了FB1,  然后形参使用了DB10。那么会出现操作失败的现象。

比如10bool变量赋值1，赋值0。经常会出现，只能赋值9个，另外有一个无法赋值成功，随机发生。

求助的最终问题：

如果FB和DB 都是优化访问快，或者非优化访问快，则不会出现这个问题。

FB是优化块，INOUT接口参数是非优化块，所以是传值而非传引用

所以问题就是由于一个是优化，一个是非优化，所以IN/OUT变成值传递了。能不能通过VARIANT的什么办法，改成指针传递，然后如何可以解决问题。

资料1：

这个似乎是一个官方的回复，但是有点不理解。

https://support.industry.siemens.com/cs/document/109476062/%E5%BD%93%E4%BD%BF%E7%94%A8-hmi-%E5%8F%98%E9%87%8F%E4%BD%9C%E4%B8%BA%E5%9D%97%E8%BE%93%E5%85%A5%E8%BE%93%E5%87%BA%E5%8F%82%E6%95%B0%E6%97%B6%EF%BC%8C%E4%B8%BA%E4%BB%80%E4%B9%88%E6%9C%89%E6%97%B6%E4%BC%9A%E5%87%BA%E7%8E%B0%E9%80%9A?dti=0&lc=zh-CN

文中提到的补救方法：
在共享数据块中定义变量，并且使用共享DB块变量作为块参数。

我理解他的意思是共享数据块也为优化访问快，但是上位机给的命令，怎么给到这个共享的优化访问快呢？

资料2

https://support.industry.siemens.com/cs/document/109478253/%E4%B8%BA%E4%BB%80%E4%B9%88%E5%9C%A8-s7-1500-%E4%B8%AD-hmi-%E7%B3%BB%E7%BB%9F%E6%88%96-web-server-%E7%9A%84%E6%95%B0%E6%8D%AE%E6%9C%89%E6%97%B6%E4%BC%9A%E8%A6%86%E7%9B%96%EF%BC%9F?dti=0&lc=zh-WW

资料3

https://www.ad.siemens.com.cn/club/bbs/PostStory.aspx?a_id=1536064&b_id=84

资料2，和资料3，都是说建立两个平行的相同的数据块，HMI操作一个DB，程序操作一个DB。

但是两者数据的交互是个大问题呀，如果在FB的开始，将HMI的数据传给程序的DB，FB结束将程序DB给到HMI的DB。

这意味着在块运行期间，操作数(或操作数的一部分)的异步改变(通过 HMI 写访问或者更高优先等级的运行系统)将会丢失，因为块被调用后，操作数的值会被覆盖。

解决方案与总结！！！

1.FB和DB块数据，通过优化和非优化之间使用IN/OUT，一定有概率会出现从DB块里面写值，会因为在FB块内部运行被覆盖的现象。

FB的运行机理，

1.传入：值传递：IN,IN/OUT，将数据传递到FB块的一个临时区域。需要使用就拿实例化的数据。

引用传递：IN,IN/OUT，将数据的地址传递到FB块一个临时区域。需要使用的时候直接寻找原始数据，

2.运行：运行FB块内部程序。

3.传出：值传递：Out、N/OUT，在FB块运行结束后，将运算完的数据发送到临时区域，临时区域传出。（问题在这，比如一个数据DB_A数据，在FB运行期间被HMI修改为1，但是由于在第1步之前没有得到数据，临时区域还是0，所以在FB结束，传出的时候，会由临时区域的0进行输出，将DB_A进行写0，从而覆盖了HMI的修改1的操作）

引用传递：Out、N/OUT，在FB运行期间任何时刻实时输出数据。

如何避免

2 .比如一个FB块，里面完成了很复杂的工艺，代码量很大。优化和非优化之间，这种情况一定不能使用IN/OUT。这种大概率会出问题。

但是我想到了一个办法。

• 1.在FB开始的地方通过Varint的方法，将数据传递进来（此时是引用传递），然后将数据存储到Temp。

• 2.在输出的地方（FB的末端）拿Temp和指针进行比较，如果两个值相等才进行输出

3.如果是一个阀门库，电机库这种数据，还是可以通过优化和非优化之间使用IN/OUT。因为这个FB块所需要运行的时间相对于整个程序的扫描周期来说，是极短的，概率极低出现这种赋值失败的现象。

2023.07.18

抱歉各位前辈，我以为提供解决方案和总结，就应该结帖了。但是好景不长，现在发现当中断块在执行的时候进行赋值，即便通过Varint引用传递的时候。 依旧出现不成功的现象。我还在找原因，会继续更新。

宏观上HMI要修改的PLC变量是被PLC周期刷新的，而HMI修改变量的时间在1500里是不确定的，这就是问题。

当然，S7-300/400,S7-1200，S7-1500在通信机制上是有区别的，所以结果也会有所不同。

总体来说，我会避免这样的软件设计。

还有一个解决办法，全部的程序都使用非优化访问快，那样子就可以统一了。毕竟上位机大部分还是使用地址寻址的方式。

但是我担心会有影响设备的实时性和性能

用INOUT（接口）传递UDT/数据块，不管数据是用副本传递，还是指针引用，在块调用之后，这个UDT/数据块都将被覆盖。（即便在FB执行期间的异步操作修改了变量。）

Variant指针传递UDT，也是GET传递到FB的背景数据块静态/临时变量。接口为INOUT时，也是覆盖。

我觉得，比较可靠的方法，是将可外部（HMI访问）操作的变量集中，做成非优化的数据块DB，程序中一次复制到应用操作的各（非HMI访问的优化）数据块。

问题不在这儿。

你要把那些HMI可访问的变量当作I。I 是不可写的。

该点状态是另外一个变量。

使用静态变量，HMI操作静态变量，官方的各种库都是如此处理的。深入一些你会发现操作静态变量更有利于面向对象的思维。

【Zane说编程】之 S7-200SMART 模拟量输入编程入门

看参考一下例程里面，通道工程数据通过界面修改得实现方式，变通一下不难。

这是不考虑HMI与PLC的通信方式的做法。

A[X]数据区经由边沿触发拷贝到A镜像数据区，HMI对A镜像数据区进行修改，A镜像数据区持续拷贝回A[X]数据区。

这不就是我在文章

1118 【万泉河】结构化编程不是设备对象的模块化，而是。。。。

所做的事嘛！

首先，非优化和优化数据的混合访问是必须的，原本就是在通过一个非优化的公共数据块解决与HMI的通信问题以及存储区不够用的问题。

我的做法没有使用INOUT接口而是在FB内部通过SID管理对数据进行传送，倒不是知道有你这里提出的问题，也不太清楚会不会发生同样的问题， 你可以试一下。 但至少， 程序中的处理可以有更多的手段来规避这种影响。 

我在讲座做完之后，有学员反馈他们使用UDT挂管脚，也就是与你相同的方法实现的，不晓得他们有没有发现你说的问题。

我认为没必要分开。 

反而更应该尽量混在一起，即对于传送到HMI的数据，都可以统一作为INOUT来对待。 哪怕是OUTPUT。

而最终如果HMI选择只读， 那它在PLC侧就完全相当于OUTPUT。

为每一个设备接口设计2个UDT甚至3个， 是不可接受的。 

楼主说的是：

来自HMI的各变量做成一个UDT数据类型（其中包括HMI的“按钮”之类的输入项）放在一个全局数据块DB10中，通过INOUT 接口传送到FB中。

这里会发生一个问题：

因为HMI的操作与FB在程序中的执行是异步的。在FB执行期间，发生了HMI对DB10中UDT中的置位。而FB的INOUT接口是复制到背景数据块中的操作。完成之后，通过INOUT又复制给DB10的UDT（覆盖）了。造成HMI对那几个置位的“丢失”！

（当INOUT接口使用的是指针时，将直接操作DB10的UDT，而不是复制。不同的PLC还不一样。）

我做了一个简单的程序，模拟了楼主描述的状况，实际与是否优化，是否FB/FC都没有关系，能否修改成功的概率与该FB/FC块的执行时间有关，块的执行时间越长，修改失败的概率愈高，因为数据在块内周转的时间越长。

这是与1500的通信机制有关系的，如果与200SMART或300那样是在用户程序扫描后执行系统通信的，就不会有上述问题。

解决方案无非就是在FB/FC块外还是块内，建立一个全局副本变量，HMI修改该副本变量的值，并通过事件逻辑标志位触发传送赋值；块外的话，直接对全局变量进行传送赋值；块内的话，输入副本变量，对输出变量进行传送赋值。

inoutHMI_20221120_2244.rar

V17的测试例程

目前我用了指针的方式，（避免值传递）然后加上标志位判断是否是在FB执行时，HMI的数据发生变化了，能解决这个问题。但是并不能做到对所有的地方都做这种处理。@Zane

例：

HMI_DB10 ——UDT_HMI 非优化

FB10 优化  

IN/OUT ： Vraint

VariantGet(SRC := UDT_HMI,

           DST => #InOut_EM.CW);

#t_EM_CW := #InOut_EM.CW;

XXX

...

IF #t_EM_CW = #InOut_EM.CW THEN

    VariantPut(SRC := #InOut_EM,

               DST := #InOut_HMI_EM);

END_IF;

创建2个全局数据块，即，plcDB:DB10, hmiDB: DB 110, plcDB给PLC使用，hmiDB 给HMI使用。

plcDB 和 hmiDB 交换数据时使用POKE_BLK指令，交换数据有3种情况用个变量来控制：

CASE _variable_name_ OF

    1:  // Statement section case 1 

        停止plcDB 和 hmiDB数据交换;

    2.:  // Statement section case 2

       plcDB 数据写入到 hmiDB ;

    3.:  // Statement section case 3

      plcDB 被 hmiDB 写入

    ELSE  // Statement section ELSE

        ;

END_CASE;

当PLC程序扫描到以上程序时，一定是没调用FB块，因此写入，读取都不会有问题

我来总结一下原因吧：

      造成楼主所描述的现象，我认为是S7-1500的时间片通信服务机制造成的，变量通过INOUT接口被传递进正在执行的FB或FC，经过运算后又经过原变量接口被传递出来，如果在变量被处理运算期间，HMI修改了该变量，那么后续由接口传递出来的值将会覆盖HMI修改的值，这就是HMI修改变量失败的原因。

PLC通信原理探秘-终极揭秘-技术视频免费看-西门子工业1847会员–西门子中国 (siemens.com.cn)

1847专家大讲堂赵工的这节课里面的部分内容针对这个问题就讲的很清楚。

这是通信机制形成的问题，与是否优化访问没有关系，与变量接口定义的类型是简单变量还是结构变量没有关系。

另外再讲一点：FB的INOUT接口定义普通变量，在调用时的确可以不带实参，但这与静态变量就没有什么区别了，而实际上即使HMI对静态变量进行值的修改，只要该变量在FB块内部有赋值操作，也会遇到上述通信机制的问题。

以下是我的例程可以给大家测试。

inoutHMI_20221127_2235.rar

FC/FB接口类型不一样，操作也是不一样的，有的在FC/FB内部直接赋值，有些拷贝副本，FC/FB里面操作完了再赋值，你说的应该是第二种就是在FC/FB中操作的时候，HMI给了赋值，但是又被FC/FB重新覆盖了

这句话是错误的：

当将结构作为输入/输出参数（InOut）传输到被调用块时，它们默认作为引用传输。

应该这么说：当将结构作为输入/输出参数（InOut）传输到被调用块时，它们被默认作为引用传输。

结构struct是值类型，而INOUT是接口，所有接口引入参数都是引用类型，而绝对地址表面上是值类型，但是放到接口上就是引用类型（博图也有自己的编译器），就是说接口已经将值类型转化为引用类型，比如new了新类，其实FB接口就是一个类，内部的程序好比方法，什么时候使用什么时候就调用就好了。

一说到编译器就是把不可识别的东东转成可识别的，而实际上直接用值类型当接口的循环扫描时间会比直接用引用类型慢些，因为它需要处理。但也不好说，如果你接口使用引用类型，比如UDT引用的数据量大的话也会变慢。优化块和非优化块都是编译器去做，只是处理的时间长短。

微微理解。

 @ smile_JIANG

这是值传递的例程，全部是优化访问，只调用了这一个子程序，这样HMI修改值得时候就极大概率的在FB块被调用的时候了，结果是很难修改成功。

 @ smile_JIANG

这是引用传递的例程1：全部优化，块内对端口无操作，百分之百修改成功。

这是引用传递例程2：全部优化，对端口读写操作，极小概率修改不成功。

这是引用传递的例程3：全部优化，端口取值，延时后运算，端口输出，极难修改成功。

有通讯改变数据的场合,最初的设计 还是区分 读缓冲区;写缓冲区,逻辑程序和这些缓冲区交互,并限定交互锁,这样形成比较好的闭包.

IN_OUT属性修饰逻辑程序内的数据相对合适,READ_ONLY 或者WRITE_ONLY属性修使通讯数据相对合适,当然也不是绝对的.

串口或者网口,数据一致性比较好的,就是把重要的有一定关系的标志位安排在同一个字节内,但这样表示的信息很有限,PN应该没有这样的担忧.

接26楼，

当上述三个例子，把全局数据块都改为非优化访问时，FB优化访问不变，程序不变，那么引用传递变为值传递，FB在调用时对INOUT接口的变量建立了副本，在FB退出时会将副本再刷新到接口变量，这时候就会发现，无论是例程1、2、3都极难通过HMI赋值成功。

因此，例程1能在全优化访问下，HMI百分百修改成功，是因为引用传递下没有对变量的访问操作。

例程2在全优化访问下，看似也是百分百，但实际不然，而是因为引用传递下对变量的读写操作前后连续，HMI值修改被覆盖的概率极低。

例程3，则无论是优化非优化都是同样的表现

由此可以得出结论，并不是优化非优化的方式方式造成了HMI修改变量值的失败的原因，而是1500PLC时间片的通信机制造成的。

同时，与INOUT接口是否定义普通变量，或者结构变量（含STRUCT与UDT）都没有关系。

优化非优化访问，是引用传递与值传递之间是否建立副本的差异，可以认为INOUT的值传递就是对变量的读写操作。

是。

PN的操作逻辑与这个问题不同。

PN/IO，程序仍然是对 IO映像区的操作。远程IO与本地IO在同一个IO域中。

其实，就是遵守一个原则，远程的HMI输入项，也当作 I，只能读、不能写。

最好就是分区，（HMI操作分开来。）

没错，曾经就遇到过这种问题，SCADA系统写值，而现场有个触摸屏画面也同时写值就会导致有时SCADA能写进去，有时现场触摸屏能写进去，有时写进去却被另一个覆盖了。

这种最后就是加一个切换按钮，进行无扰切换，对其进行单控。

其实就是I/O不能同时复用。