一台输送电机接入 PLC 后，自动顺序要启动它，操作员要在 HMI 上手动调试，维护人员还要查看反馈、修改监控时间。若三处各写一套变量，程序虽然可能工作，后续却很难回答：画面上的“运行”，到底是启动命令，还是已经确认的设备状态？

LBC 的架构可以从一个设备对象看起：功能块处理行为，配置决定处理条件，控制接口接收上层命令，HMI 接口提供操作与显示。它们围绕同一台设备组织，但不是同一个变量，也不需要全部塞进同一个 DB。

本篇以 Siemens《Library of Basic Controls》V3.1.0（04/2025）中的 LBC_MotorStarterCn 为例；该块本身仍标为 V3.0.0。原站 PDF 本轮访问受限，文字核对采用公开阅读副本，配图为下文注明的旧版手册页面。本文是架构解读，未运行库工程，也不作 TIA Portal V21 兼容性或现场投运声明。

一、先沿一台电机，把控制对象找齐

LBC_MotorStarterCn 面向可正反转的直接启动器。看接口时，先把反馈、输出与结构化数据分开：前两类连接设备，后一类连接调用方和操作界面。手册 3.1.10 节给出了这几组实际接口。

对象	在这个例子里负责什么
feedbackReady 等反馈	让功能块取得启动器的准备、运行方向和故障信息。
enableStarter、forward、backward 等输出	把功能块处理后的控制结果交给项目的实际设备回路。
configuration	接入这台设备的配置数据。
controlNode	向上层程序提供成组的命令与监视信息。
moduleInterface	供 HMI 等外部系统操作、监视和编辑参数。

图中下方的三条结构接口与上方的现场信号同时存在。Control Node 并没有把所有接线都藏起来，项目仍要将反馈和输出对应到正确设备。

以一台假设的输送电机为例，项目还要为这次 FB 调用分配实例数据，并声明要连接的配置和接口变量。库提供数据类型和功能，不替项目决定“这一份数据属于哪台电机”。复制第二台设备时，只改显示名称并不够，还必须检查调用实例、接口变量和现场信号是否一起分开。

二、configuration、controlNode 和 moduleInterface 为什么并存

先看数据的用途，而不是先争论要建立几个 DB。按手册第 2 章及 4.18 节，MotorStarter 的外部接口包含命令、监视和配置；控制节点则包含命令与监视。两者服务不同的使用者。

configuration 是功能块使用的配置入口。调用方决定这些参数放在哪里。可以纳入上层设备的配置结构，也可以集中保存；“配置集中管理”与“所有运行状态都共用一个 DB”是两件事。

controlNode 面向上层控制。顺序程序通过它表达要做什么、读取处理状态，不必把设备的所有内部状态都当成自己的接口。这里选用的是 Cn 形式，不应仅凭名称把所有版本的 Cn 块都解释成同一种外围包装。

moduleInterface 面向外部操作与显示。其 commands 放操作请求，monitoring 提供监视信息，configuration 用于界面侧的参数交互。这个配置成员不是另一个独立控制算法，也不表示画面改字后所有实际参数就立即改变。

下面的旧版数据类型页可以对照这两种结构。重点看成员分组，不把截图中的默认时间当成自己设备的推荐值。

一个可维护的安排，是先为每台设备明确数据所有者，再决定物理存储位置。两台电机可以使用同一个 FB 类型，但不能因“共用类型”就无意共用一份状态或一份 HMI 命令。这个安排是项目组织建议，不是 LBC 强制的 DB 命名格式。

三、自动请求和手动请求，最后都要回到设备逻辑

继续看输送电机：自动顺序想让它正转，操作员也可能在调试页面提出正转请求。请求来源不同，现场却只有同一台设备，因此必须先确定操作权，再让设备逻辑解释请求。不能让 HMI 和自动程序分别绕过功能块去写同一输出。

在本例接口中，controlNode 组织程序侧的命令，moduleInterface.commands 组织界面侧命令；enableManualCmds 是允许手动命令的输入。MotorStarter 接口说明给出了这些对象，但并没有替你的机器规定完整的自动／手动切换流程。

因此，接入前先回答：自动运行中是否允许手动接管，切换前设备应处于什么状态，退出手动后顺序怎样继续？这些属于上层模式与工艺设计。不能看到一个“手动允许”输入，就把整台机器的模式管理全部省略。

还要保持请求、控制输出和反馈的区别：提出正转请求，只能证明有人想启动；输出已经发出，仍需按配置和反馈判断运行状态。由此推理，顺序的“下一步条件”和 HMI 的“运行显示”，都不宜直接拿启动请求代替。

普通控制许可不是功能安全措施。本文不把 LBC 的联锁输入当作急停、安全门或安全输出功能，也不建议通过强制许可来调试运行设备。涉及现场下载与动作验证时，需要另外落实相应的安全设计和授权条件。

四、一个 Unified 面板怎样知道自己属于哪台电机

在手册 9.1.1 节，Basic View 的 moduleInterface 属性需要指向对应的 HMI 变量，而该变量再连接到 PLC 中相应的接口实例。面板类型可以复用，绑定的数据对象必须逐台明确。只复制面板并改标题，不会自动把它绑定到另一台电机。

可以用一个离线检查情境理解这层关系：复制电机 A 的画面给电机 B，显示名称已经改成 B，但接口仍指向 A。此时画面的外观和数据对象已经脱节。这个例子不是本站发现的现场故障，而是检查复制操作时值得排除的一种可能性。

Basic View 用于设备概览；Extended View 将监视、参数、报警和手动操作进一步展开。手册 9.2 节还说明，扩展页面需要接收并重新绑定目标接口与相应资源。本文只讲对象关系，不拼接一段未经验证的弹窗脚本。

所以，把 HMI 接入检查分成三层更清楚：先确认 PLC 调用了正确的块并接上接口，再确认 HMI 变量连接到该接口，最后检查面板及弹窗是否继续指向同一个对象。图形列表、文本列表和用户权限也要随相应对象核对，不能以“面板显示出来了”作为全部完成的标志。

五、参数和诊断，不是附在画面上的两项装饰

参数编辑需要处理两份数据的关系：一份供模块运行使用，一份供界面显示和修改。LBC 的Module interface 说明（2.5 节）区分刷新、编辑和保存配置的命令，目的不是让 HMI 无限制地改写模块内部状态。

对读者而言，先理解这三件事就够了：刷新把当前配置送到界面；编辑时不能持续用原配置覆盖正在修改的内容；保存则将修改交回配置数据。具体触发和状态应按所用面板与块版本实现，不把这段解释当作完整的通信协议。

这也说明，画面上两个数值看起来相同，并不证明它们一直同步。若调用方另有逻辑周期性重写配置，界面改动的去向就需要重新检查。参数存在哪里、谁可以改、怎样备份，是接入对象时就该定下来的规则。

诊断则解决另一件事：把设备的处理结果说明白。LBC 将状态信息与相应文本列表配合使用；在 S7-1500 的相应场景还有预配置的 ProDiag 监督。具体消息如何上送，仍须对应实际集成。作为补充，Siemens 的 AF 诊断示例展示了状态值、监督与报警文本的联系；这是集成示例，不是本篇电机的故障码表。

接入项目时，应能从报警追到设备对象，再追到当时的命令、反馈和配置。只有“电机故障”一个总标志，虽然能让画面变红，却不足以区分请求未获允许、启动反馈未到，还是设备已报错。把这些信息保持关联，比在画面上再增加一种颜色更有用。

六、接入自己的项目，先检查一条完整的数据路径

前两篇分别讨论了LBC 的定位与库类型和配套依赖。到了这一篇，检查的对象不再只是“库里有什么”，而是某台设备的一次调用怎样接入项目。

检查位置	应当能够回答
PLC 调用与实例	调用的是哪个实际块版本？状态是否属于目标设备？
现场输入与输出	反馈和控制结果是否接到同一个设备回路？
配置与两套接口	存储在哪里？谁写命令、谁读状态、谁允许修改配置？
HMI 与诊断	基本面板、扩展页面和报警是否对应同一个设备对象？

推荐先选一台对象，把这条路径在工程副本里核对完整，再扩展到整条设备线。发现面板绑定错误，就回到绑定关系；发现两台设备共用状态，就回到实例与数据分配。不要先复制几十台，再逐个修补零散变量。

本篇的终点不是让读者背下三个 UDT 名字，而是理解：上层决定做什么，设备块解释请求与反馈，HMI 使用约定的接口，配置和诊断贯穿同一个对象。下一步才是按确定版本准备官方示例，逐项记录实际运行结果。

配图为 Siemens 手册的公开转载页面，权利归相应权利人，原标识保留；不纳入本站原创文字许可。资料核对：2026-09-11。本篇未进行编译、仿真或实机测试。