全局数据块和背景数据块的区别
对于全局数据块而言,所有的程序块 (FB,FC 和 OB)均可以读写该数据块中的数据。而背景数据块被分配给特定的功能块,包含所分配的FB的本地数据。 全局数据块 | 背景数据块 | 所有的程序块 (FB,FC 和 OB)可以访问程序中全局数据块中的数据 | 背景数据块 DB 被指定到一个 FB | 在程序中能够独立地创建全局数据块 | 在程序中只能够对相关联的 FB 创建背景数据块 | 不能创建静态变量 | 在FB中可以定义静态变量,当数据块建立完成并且已经被保留了几个循环之后,存储的本地静态数据不会丢失,除非数据再次被更改 | 在数据块中添加,删除,改变变量 | 在相关的功能块中添加或删除变量,改变变量 | 可以改变初始值和当前值 | 不能改变变量的初始值和当前值 | 全局数据块的结构能够被指定 | 在相关的FB中预定义数据块的结构 | 表 1
注意 在 CPU 中的 STEP7 程序对全局和背景数据块有相等的读写权利。

图 01
不同 FB 的数据可以存储在单个背景数据块中 (多重背景)。图 02 给出了一个例子,说明了在 FB1 中 FB5 和 FB6 如何作为多重背景的。两个 FB 将它们的背景数据保存在调用它们的 FB1 的背景数据块 DB1中。在 FB1 的声明中,多重背景块保存为静态变量。
图 02
更多信息可以参考 STEP 7 在线帮助以下部分 - “背景数据块”
- “创建数据块 (DB)”
- “数据块 (DB) 的结构”
- “使用多重背景”
从 STEP 7 V4.02 升级到 V5.x 需要注意
当升级 STEP 7 V4.02 到 V5.x 版本时,在 LAD/STL/FBD 编辑器中可能会在调用 CALL 功能时出现红色。这种现象的原因是块中调用的一个背景数据块已经在符号表里被声明为全局数据块。在 STEP7 编程规则中这是不允许的,并且在 STEP7 V5.x 版本中也是不能被接受的。 补救措施
可以按照下列步骤来修改发生错误的数据块: - 在符号表中删除声明错误的 DB 所在行。
- 然后删除错误的 DB 块。
- 打开调用的块然后重新生成背景数据块。
调用 CALL 功能如何影响 DB 寄存器
当程序块在 STEP 5 或 STEP 7 中被调用时,DB1 和 DB2 寄存器的初始内容被恢复。已经打开的数据块会一直保持有效直到另一个数据块被打开。DB 寄存器的内容反映了当前打开的数据块(DB / DI)。 然后,必须明确,不是所有的 S7 编辑器/编译器对 DB 寄存器的改变对用户来说都是明显的。例如,当使用 CALL 指令调用 FC 时,如果给 FC 形参分配的是完整的数据块变量地址,编译器会打开指定的数据块。当 FC 调用完成时,DB 号仍然保存在 DB1 寄存器中。在 FC 中改变 DB 寄存器不会影响调用完成后 DB 寄存器的值。
举例: | DB1 寄存器 | AUF DB1 | 1 | L DBB 0 | | CALL FC1Input1:= DB2.DBB0
Input2:= DB3.DBB0
| | L DBB 0 | 3 | 表 2
如果调用功能块和相关的背景数据块,调用 CALL 指令后,背景数据块号保存在 DB1 寄存器中。传输完整的数据块变量地址给 FB,在 FB 中更改 DB 寄存器不会影响 DB1 寄存器的内容。
举例: | DB1 寄存器 | AUF DB1 | 1 | L DBB 0 | | CALL FB1, DB10Input1:= MW0
Input2:= DB3.DBB0
| | L DBB 0 | 10 | 表 3
调用系统功能块后 (SFB),相应的背景数据块号保存在 DB1 寄存器中。然而,使用 UC 或 CC 指令后,数据寄存器始终保持不变,这是由于这些调用没有指定参数和背景数据块。 注意
为了避免在 STEP 编程过程中处理数据块时出现区域长度错误和访问错误,尽量只使用完整的地址访问 DB 中变量。(如 DBx.DBBy 或符号名 "DBName".Variable_name)。
|