0517 【万泉河】PLC变量命名规范与程序架构设计实践

前言

在PLC程序开发过程中，变量命名问题困扰着许多工程师。原本在设计阶段规划好的命名规则，到了实际编写时却越来越混乱。本文探讨变量命名的实用方法及其背后的程序架构设计思路。

一、命名规范的实用方案

1.1 混合命名策略：英文缩写 + 中文描述

针对PLC编程的实际场景，有一种简单高效的命名方法：

一个英文字母 + 中文描述

例如：

缩写

含义

应用示例

ai

模拟量输入

ai温度、ai压力

ao

模拟量输出

ao阀门开度

di

数字量输入

di启动按钮、di急停信号

do

数字量输出

do电机启停、do报警灯

tm

定时器

tm延时启动

ct

计数器

ct产品计数

i

输入参数

i设定值、i目标温度

o

输出参数

o实际值、o运行状态

x

临时变量

x中间结果、x计算值

这种方法的优势在于：

l  l     英文缩写便于快捷输入

l  l     中文描述语义清晰、易于理解

l  l     统一前缀便于分类检索和批量处理

1.2 功能性参数的命名

对于PID、运动控制等功能块的参数：

场景

处理方式

积分时间

i积分时间

微分时间

i微分时间

设定速度

i速度设定

实际位置

i当前位置

关键原则：以物理含义命名，而非照搬国外标准的符号。

1.3 为什么不能强求统一命名规范

在讨论命名规范时，有一种观点认为应当统一采用驼峰命名法、帕斯卡命名法或匈牙利命名法等经典规范。然而，在PLC实际工程中，这种要求往往难以实现，原因如下：

第三方库的命名差异

工程项目中不可避免地要使用第三方库函数，而这些库的管脚命名规则各异：

库来源

参数命名示例

规则风格

西门子官方库

Ti、Td

缩写式

施耐德库

TN、TV

缩写式变体

第三方运动库

integralTime、derivativeTime

全单词式

开源社区库

dIntegral、dDerivative

前缀式

难道因为命名规则不统一，我们就不用这些库了吗？显然不可能。

智能设备的对接需求

现代工程项目中，PLC需要与大量智能设备通信：

l  l     变频器（Modbus通信的参数寄存器）

l  l     智能传感器（自定义数据格式）

l  l     视觉系统（图像处理结果数据）

l  l     工业机器人（厂商特定的指令和数据定义）

这些设备的接口数据定义规则来自各自的供应商，不同厂商的命名规则必然不同。PLC程序必须考虑与这些产品的对接，而非要求对方改变命名来适应我们的规范。

务实对待命名问题

讨论变量命名规范时，关键在于语义清晰、便于维护，而非拘泥于某种特定的命名形式。过度追求形式上的统一，反而会增加不必要的麻烦。

面对实际情况，工程师应当：

1.   1.    接受差异：第三方库和设备的命名是既定事实

2.   2.    灵活适配：在调用处添加中文注释说明含义

3.   3.    封装隔离：通过适配层将外部命名与内部规范隔离开

二、命名混乱的根本原因

2.1 表象与本质

很多工程师抱怨"项目开始时感觉规划很好，项目进行中就乱套了"。然而，命名混乱并非问题的根本原因，而是程序架构设计不合理的表现。

2.2 问题的根源

命名混乱 ← 程序架构混乱 ← 缺乏顶层设计

代码质量的根本问题不在于命名规范本身，而在于程序架构的合理性。当程序架构存在以下问题时，命名必然走向混乱：

l  l     层级职责不清

l  l     模块耦合严重

l  l     接口定义模糊

l  l     重构频繁导致命名不一致

三、程序架构设计原则

3.1 逐层封装的理念

程序应当采用逐层封装的设计思路。FB块和FC块的选用、管脚的设计，这些看似基础的问题，实际上决定了程序的整体结构：

┌─────────────────────────────────────┐
│ 应用层（调用方）                       │
│ "我只管用，不关心内部实现"              │
├─────────────────────────────────────┤
│ 功能层（封装块）                       │
│ "提供简洁、统一的接口"                  │
├─────────────────────────────────────┤
│ 基础层（底层驱动）                     │
│ "处理复杂的硬件细节"                   │
└─────────────────────────────────────┘

3.2 翘空理论与接口设计

FB的管脚设计有一个重要原则：能空着就尽量翘空着。

这一原则深刻揭示了良好封装的核心：

设计原则

说明

接口简洁

只暴露必要的管脚，减少调用者负担

内部自治

功能在块内部完整实现，不依赖外部变量

易于使用

调用者只需关注核心参数，无需了解内部细节

封装好的块，别人或上层只管用，不会有人质疑它接口定义符合不符合规范，只要求好用，易用，简练。

3.3 良好封装的特征

封装良好的程序模块应具备以下特性：

特性

说明

表现

易用

接口简洁直观

调用者无需了解内部逻辑

简练

功能边界清晰

一个块做一件事

规范

命名语义一致

内部命名规范统一

可移植

复用性强

换一个项目仍能直接使用

3.4 以官方库为参照

观察西门子、施耐德、三菱等主流PLC厂商的库函数：

l  l     PID 功能块的参数命名（Ti/Td 或 TN/TV）

l  l     运动控制库的轴参数命名

l  l     通信功能块的参数定义

这些库函数没有人会质疑其命名规范与否，原因在于：

1.   1.    功能定义清晰 - 接口即语义

2.   2.    文档完善 - 参数含义明确

3.   3.    使用便捷 - 调用方式统一

4.   4.    无需修改 - 调用者只需适配，无需改名

这正是良好封装的示范：接口定义符合使用习惯，而非追求"命名规范"。

四、实践建议

4.1 项目启动阶段

1.   1.    搭建架构框架

1.     （1）确定程序层级结构

2.     （2）定义模块边界和接口

3.     （3）制定统一的命名规范文档

1.   2.    建立项目模板

1.     （1）标准的功能块结构

2.     （2）统一的变量命名规则

3.     （3）规范的注释模板

4.2 编码执行阶段

1.   1.    遵循既定规范

1.     （1）前缀统一（ai、ao、di、do、tm等）

2.     （2）语义明确（避免单个字母或无意义名称）

3.     （3）层次分明（通过命名体现变量归属）

1.   2.    保持封装意识

1.     （1）一个功能块只负责一个功能

2.     （2）对外接口尽量简化

3.     （3）内部实现对调用者透明

4.3 与第三方库和设备对接时

l  l     接受既定命名：第三方库和设备的参数名是事实标准，无需强行统一

l  l     添加注释说明：在调用处用中文注释解释参数的物理含义

l  l     封装适配层：通过适配层将外部命名与内部规范隔离，对外保持原样，对内使用统一规范

五、总结

PLC变量命名规范的核心要点：

层面

建议

命名层面

采用"英文缩写+中文描述"的命名法，兼顾输入效率和可读性

兼容性层面

接受第三方库和设备的命名差异，通过适配层隔离

架构层面

做好程序顶层设计，采用逐层封装的模块化结构

态度层面

追求"好用、易用、简练"，而非刻意的"命名规范"

实践层面

项目启动时先搭架构，项目进行时遵循规范，遇到差异时灵活适配

核心要点回顾

1.   1.    命名规范不是根本：好的程序架构是命名规范的根基，而命名规范是程序架构的外在体现

2.   2.    封装优于规范：遵循"翘空"原则，追求接口的简洁易用

3.   3.    务实对待差异：工程项目中不可避免地要使用第三方库和智能设备，强求统一命名规范既不现实也无必要

。

0517 【万泉河】PLC变量命名规范与程序架构设计实践.pdf