数据块:TIA Portal 的一等公民

在 TIA Portal 中,数据不仅仅是隐藏在代码背后的东西,它是一个可见的工程对象。

数据块:TIA Portal 的一等公民
梯形图转SCL | 博途AI辅助编程文档 | AI模型价格对比 | AI工具导航 | ONNX模型库 | Vibe Coding教程 | PLC在线仿真器 | Tripo 3D | Meshy AI | ElevenLabs | KlingAI | ArtSpace | Phot.AI | InVideo

在上一篇文章中,我写了关于功能块、函数和实例的内容。这自然引出了实例数据块,因为在 TIA Portal 中,FB 需要一个地方来保存其内存。

现在我想从那个特定案例中退后一步,直接审视数据块。

这是西门子的一个选择,在你使用 TIA Portal 一段时间后会显得很正常。打开"程序块"文件夹,它们就在那里:FB、FC、OB 和 DB 作为项目对象并排放置。

但这并不是唯一的模型。TIA Portal 使数据块成为可见的、可命名的、可下载的、可监控的对象。这个选择影响了调试、诊断、HMI 集成、数据保持、在线更改和团队可读性。

它不仅仅是"变量存储在哪里",它是架构的一部分。

1、什么是数据块

数据块不是代码,它不执行,也不做决策。它存储程序数据。

西门子在 STEP 7 文档中非常直接地描述了全局 DB:数据块存储程序数据,而全局数据块存储可被所有其他块使用的数据。

在实践中,我主要考虑两个类别。

全局数据块是共享数据区域。OB、FB 和 FC 可以从中读取或写入。全局 DB 可能保存机器设置、HMI 命令、报警字、IO 映射结构或完整的系统接口。

实例数据块属于功能块实例。当我创建一个 FB 定义并将其调用为 instPump_P01 时,TIA 需要一个地方来存储该泵实例的状态。如果我再次将相同的 FB 调用为 instPump_P02,第二个实例将获得自己的内存。相同的代码,不同的数据。

这就是基本区别。全局 DB 设计上是共享的,实例 DB 由 FB 实例拥有。

问题从我忘记这种所有权差异时开始。

2、为什么可见的 DB 很有用

DB 的可见性是我仍然喜欢 TIA Portal 模型的原因之一,尽管 TIA 有时会让我感到沮丧。

在调试期间,我可以在线并打开一个 DB。我可以在一个结构化的地方看到机器设置、操作员命令、反馈值、报警标志、状态号和诊断位。如果压力控制器拒绝启动,我通常可以在打开 FB 之前,在 DB 中查看命令、联锁、过程值、设定值和故障状态。

当工厂正在运行,有人站在你旁边等待答案时,这很重要。

可见的 DB 对于快照和起始值也很有用。如果我在调试期间调整参数,这些值作为实际值存在于在线。如果我后来更改 DB 结构并粗心下载,我可能会丢失调整后的值并回退到旧的起始值。

我对重要设置 DB 的习惯很简单:调整后,拍摄实际值的快照,并将快照复制到起始值。西门子在 TIA Portal 中记录了这两个操作:创建实际值的快照和将该快照复制到起始值。然后,如果 DB 稍后被初始化,起始值就不是旧的默认值。

我还倾向于将重要的保持设置保存在它们自己的 DB 或明确分隔的部分中。不是因为 TIA 需要这种结构,而是因为它使职责变得明显。如果 DB 被命名为 MachineSettings,我会在下载前以不同于临时诊断 DB 的方式对待它。

DB 重要的另一个原因是外部访问。HMI 屏幕、OPC UA 客户端、日志工具和测试工具通常需要一个清晰的边界进入 PLC。西门子记录了 DB 级别的 OPC UA 访问设置,包括通过 DB 属性使整个 DB 对 OPC UA 客户端可访问或隐藏的能力。我可以暴露一个有意的通信 DB,而不是让每个内部变量都成为外部接口的一部分。

对于团队可读性,可见的 DB 使数据模型可浏览。新工程师可以打开项目并查看共享数据的位置。

3、全局 DB:强大且危险

全局 DB 很强大,因为它们给你一个单一的事实来源。

在泵站中,我可能有一个结构化的 DB,包含来自 HMI 的泵命令、返回给 HMI 的泵状态、原始 IO 映射和通用系统诊断。泵 FB 可以通过 InOut 参数接收该结构的相应部分。

这个模式可以很干净。我使用过它的变体,因为它使系统数据可见并减少了冗长的参数列表。我传递一个结构化的接口,而不是向块传递二十个单独的标签。

但全局 DB 也很危险,因为它很容易变成一个垃圾场。

糟糕的版本是这样的:每个块都可以写 data ", 每个代码块都可以写入任何内容,没有人拥有某个代码段的所有权,要理解某个值,唯一的办法就是搜索整个项目。程序仍然可以编译,但所有权的概念已经消失了。

我使用的规则不是"避免全局 DB",我不相信这一点。

规则是:决定所有权。

如果一个部分被称为 Commands,HMI 或操作员接口拥有写入端。如果一个部分被称为 Status,设备 FB 拥有写入端。如果一个部分被称为 Inputs,IO 映射层写入它。如果一个部分被称为 Outputs,控制逻辑写入它,IO 映射层将其发送到硬件。

可以有例外,但它们应该是有意的。没有所有权的 DB 只是带有更好名称的全局内存。

这也是为什么我在现代 TIA 项目中避免使用 Merker 位作为主要内部架构。M 内存是全局和绝对的。DB 标签给我结构、类型信息和附加所有权的地方。

4、实例 DB:块拥有的状态

实例 DB 解决不同的问题。

功能块是带有内存的代码。西门子将 FB 描述为带有内存的块,因为它们的参数永久存储在实例数据块中,并在块执行后保持可用。官方 FB 文档还指出,每个 FB 实例需要特定于实例的值。

这就是为什么我喜欢上一篇文章中的心智模型:FB 是定义,实例是对象,实例 DB 是对象的内存。

对于泵控制器,实例 DB 可能包含运行锁存、故障锁存、定时器、命令边沿检测、累计运行时间和内部状态。全局 DB 可能包含命令和状态接口,但实例 DB 包含 FB 工作所需的私有内存。

这种区别有助于避免一种常见的设计坏味道:使用全局 DB 存储每个 FB 的所有内部状态。如果一个变量仅仅存在是为了让 FB 在扫描之间记住某些东西,它可能属于 FB 的 Static 部分,因此属于实例 DB。

多实例更进一步。当父 FB 将子 FB 作为 Static 变量包含时,子实例数据可以存在于父实例 DB 中。一个罐系统 FB 可以在一个父实例 DB 中拥有其阀门控制器、液位控制器和报警处理器实例,而不是将单独的 DB 散布在项目树中。

5、数据保持、起始值和下载现实

DB 在在线更改期间变得非常真实。

我在调试期间关心两个值:运行 PLC 中的实际值和存储在项目/加载内存中的起始值。数据保持增加了另一层,因为一些值在断电后仍然存在。

陷阱是认为数据保持意味着"在每次下载中都是安全的",事实并非如此。

如果 DB 或 FB 接口以强制重新初始化的方式更改,TIA 可以将值重置回起始值。如果起始值是最新的,重新初始化的损害较小。如果起始值是旧的默认值,你就丢失了调试工作。

西门子提供了降低此风险的机制,但它们有条件。

较旧的机制是使用内存保留的不重新初始化下载西门子文档指出它适用于 S7-1200 V4 及更高版本和 S7-1500,具有优化访问块,并解释说未来的接口添加可以存储在保留区域中,这样现有加载的标签值在下载期间不会受到影响。关键是你必须在需要之前激活保留,并且它主要关于保留内的扩展。

TIA Portal V21 在加载预览对话框中添加了较新的保留实际值操作。西门子将其描述为允许对数据块进行结构更改而不重新初始化所有标签的实际值。但要求和限制很重要:它适用于 TIA Portal V21、S7-1500 固件 V4.1 和优化访问 DB。它不提供用于数组维度更改、字符串长度更改、数据类型更改或数据保持更改。必须禁用内存保留。西门子还列出了更多限制,包括引用或参数类型以及在 IDB 中设置了数据保持的标签。对于标签名称更改,西门子指出加载时无法保留实际值。

所以我的实际结论是保守的:当项目和 CPU 支持时使用西门子功能,但不要围绕希望构建你的调试纪律。在更改具有重要值的 DB 结构之前,检查 TIA 将要做什么,拍摄重要值的快照,并确保起始值不是过时的。

6、AX 证明这个选择不是通用的

SIMATIC AX 的对比在这里很有用,因为它证明了 TIA Portal 的 DB 模型是一个设计选择,而不是 PLC 编程的定律。

在我之前写的 AX 文章中,映射很直接:TIA 全局 DB 成为 AX CONFIGURATION 中的 VAR_GLOBAL 部分;FB 实例数据通过声明 FB 类型的变量来创建。在 AX 项目结构中没有单独的 DB 对象或 DB 文件。

这并没有错,它更适合基于文本的工作流。TIA Portal 走了另一个方向,它使 DB 成为显式的项目对象。你可以打开它们、监控它们、设置起始值、配置数据保持、配置 OPC UA 访问,并将它们视为工程模型的可见部分。

两个模型都不是自动更好的。AX 给你一个更干净的文本优先表示,TIA 给你一个非常实用的调试对象。

对于我做的那种现场工作,我仍然理解 TIA 为什么做出这个选择。当你在线连接到机器时,一个结构良好的 DB 是了解程序的最快窗口之一。

7、我的实用规则

每个 DB,以及 DB 内的每个主要部分,都应该有一个所有者。

如果它是全局 DB,决定谁写入每个部分以及谁读取它。如果它是实例 DB,将其保留为块拥有的状态,除非有真正的理由在其他地方暴露该值。如果它是设置 DB,将其视为调试数据,而不是一次性的临时内存。如果它是 HMI 或 OPC UA 边界,使其有意图并保持内部实现细节不在其中。

DB 不是我无处存放变量的垃圾箱,它们是程序架构的一部分。

这就是我认为 TIA 将数据块视为一等公民的真正原因。工业控制系统中的数据不是被动的,它是 PLC 如何记忆、HMI 如何与程序对话、调试如何在下载后幸存、诊断如何变得可读以及另一个工程师稍后如何理解系统的方式。

如果你有意识地构建 DB,它们会使项目更容易调试和维护。

如果你不这样做,它们会变成带有更好编辑器的全局内存。

我两个版本都做过,有意识的版本是我想要继续构建的版本。


原文链接:Data Blocks in TIA Portal — Why TIA Treats Data as First-Class Objects

汇智网翻译整理,转载请标明出处