答案只有一个：设备无关性。

把物理硬件与逻辑程序彻底解耦，把重复劳动变成模板配置，把 “写点位” 升级为 “定义对象”。

这篇文章，我将借鉴 PCS7 与 Linux 设备树的思想，在欧姆龙 PLC上，完整描述一套真正面向对象、极致解耦、可复用、可扩展的项目思维。

一、思考

声明：本文以欧姆龙PLC编程平台为基础，探讨一种极致的编程思想——实现设备无关性、极致的面向对象编程、极致解耦物理IO点与程序抽象逻辑。这些思考将推动我对程序、IO表、图纸做出一系列根本性的改动。

在文章开始前，先问一个经典问题：把大象放进冰箱需要几步？

答案是三步：打开冰箱，把大象放进去，关上冰箱。在这个问题中，“打开”“放进去”“关闭”是过程，“大象”“冰箱”是对象。

现在问题变了：把长颈鹿放进去需要几步？

还是三步：打开冰箱，把长颈鹿放进去，关上冰箱。

很清晰——这个过程本身没有发生任何改变。但现在大象和长颈鹿都站在冰箱门口，需要几个冰箱？两个：一个胖冰箱放大象，一个高冰箱放长颈鹿。

于是我们有了两种实现方式：

方式一（过程式）打开胖冰箱 → 放大象 → 关上胖冰箱打开高冰箱 → 放长颈鹿 → 关上高冰箱

方式二（面向对象式）打开冰箱 → 放动物 → 关上冰箱

其中，“高冰箱”“胖冰箱”自动代入“冰箱”，“大象”“长颈鹿”自动代入“动物”。

显然，方式二更加高级优雅。它把“打开-放入-关闭”这个过程封装起来，把“冰箱”和“动物”作为对象描述——这正是面向对象编程的核心思想。

而我在PLC程序架构上的探索，本质上就是在做这件事。自动代入对象，封装过程！

二、两个顶级参照：PCS7 与 Linux 设备模型

面向对象不是 PLC 原创，它本就是计算机世界的底层逻辑。我举两个非PLC但离我们很近的例子：一个是万泉河老师分享的PCS7概念，一个是Linux设备模型。

PCS7是西门子的DCS系统，专门用于过程自动化（如化工、制药、电力等行业）。它最核心的设计思想就是面向对象和模板化。

在传统PLC编程中，如果项目里有100个相同的电机，你可能需要复制粘贴100遍类似的程序，或者手动维护100套IO地址。但在PCS7里，工程师只需要做好一套电机控制模板（CFC），然后在工程视图中把这100个电机当成100个“对象”拖进去，通过列表批量填写它们的参数（比如哪个电机接哪个泵、报警值设多少）。

PCS7引入了“过程对象（PO）”的概念——一个电机是一个PO，一个阀门也是一个PO。工程师站软件就是按PO数量来授权的。这意味着你在编程时，脑子里想的不再是“I0.0、Q0.1”这些散点，而是“电机1、阀门2、PID回路3”这些对象。程序框架和HMI画面都可以通过模板自动生成，工作量从“写代码”变成了“配置对象”。

这就是PCS7对“设备无关性”的诠释——无论是什么型号的电机，在程序眼里它就是一个“电机对象”。

Linux作为支持成千上万种硬件的操作系统，必须解决“统一管理”的问题。它的解决方案是：通过设备树（Device Tree）来描述硬件。

设备树：只描述硬件我有什么设备、挂在哪条总线、用哪个中断、地址多少。

驱动：只实现逻辑open、read、write 一套标准接口。

设备树是一种数据结构，它告诉内核：我有一个叫“电机”的设备，它挂在哪条总线上，用哪个中断，寄存器地址是多少。而设备驱动（如motor_driver.c）只负责实现控制逻辑，比如提供open()、read()、write()这些标准接口。

这样一来，硬件描述和驱动逻辑就分离了。换了一个不同型号的电机，只需要改设备树文件里的描述，驱动代码不用动。上层应用程序看到的永远是/dev/motor0这样的文件接口，根本不知道背后是A公司的电机还是B公司的电机。

这就是Linux的“设备无关性”——通过统一接口屏蔽底层差异，让上层逻辑专注于业务本身。

这两个例子给我的启发是：无论是过程控制还是操作系统，它们都在追求同一件事——把物理世界的多样性，抽象成逻辑世界的统一性。硬件在变、型号在换，但只要描述清楚，上层只管调用接口。这不正是我在PLC上想做的事吗？

三、在欧姆龙平台上的实现与改动

核心思维是：组态 → 业务对象（轴、气缸、CCD等）

用过欧姆龙的都知道，用EtherCAT总线轴控制的时候很简单——因为欧姆龙底层对轴已经描述好了。在欧姆龙手册《运动控制篇》中，我们可以看到轴的PDO配置已经映射到了描述轴的结构体中。

由此我得出一个结论，既然工位控制过程 气缸控制过程 相机控制过程 都没有对应的一个系统结构体，而我们在做过程FB的时候已经描述好了这些对象，为什么不能将配置一起打包进FB呢？答案是可以的，基于此思想，下面展开描述

欧姆龙手册运动控制篇手册如图：

1、IO表规划

在IO表中，我们不再使用X、Y、I、Q这类代指点位的名称。模块的插槽和点位才是主体，使用以下规则（规则可自定义，本文仅示例）：

M01U02A3——

M01：第1个EtherCAT通讯模块（耦合器或主站）

U02：第2个插槽

A3：第3个输入点

为什么用A3？因为我使用的是汇川GL20-16模块，这款模块上自带的标识就是A1-A9、B1-B9。我们完全面向物理层面——模块叫什么，我们叫什么。这个代号仅具备索引物理位置的作用，不再承载其他含义。汇川模块如图：

但是这个点位的名称不叫M01U02A3。点位名称叫做：

EM1_CY1_XV1：工位1气缸1伸感应1

EM1_CY1_XR1：工位1气缸1缩感应1

IO表如图：

输出同理：

M01U03A3→EM1_CY1_YV1（工位1气缸1伸输出1）

M01U03A4→EM1_CY1_YR1（工位1气缸1缩输出1）

IO表如图：

2、图纸改动

图纸中，IO点的黑盒引脚不再使用冗长的X多少，彻底固定为A0-B15。这样就不用自己做黑盒了，可以直接使用该品牌官网提供的EPLAN。

IO模块标识：M01U02（耦合器M01，插槽U02）

IO表中的注释：添加到引脚功能文本

实物标识：耦合器贴M01，插槽贴U02，点位按实物标识

图纸示意如图：

实物示意如图：

3、程序实现

上面的IO表和图纸，已经做到了完全的物理层。程序中只需要对物理层进行一次耦合——仅此一次，此后所有映射程序都不用改动。

① 插入耦合器/主站组态

② 编辑模块PDO配置

③这里需要选择纯BOOL配置，因为我们要对每个点直接映射到后续的FB块。如果选择字节类型，会产生二次中转。

④借助IO表进行快捷操作。其实可以通过Excel宏一键转换成欧姆龙格式。目前Excel宏还没来得及做（本人对Excel宏也不精通，大部分靠AI生成）。类似这种表格模板替换，可以这样训练AI：

“先告诉AI有A表B表，A表表头是……，B表表头是……。B表需要将A表中‘点位编号’行、‘名称’列的数据，放置到B表的‘变量’列、‘插槽’行下。”

这是整理好、可直接复制到欧姆龙IO映射中的示例如图：

⑤粘贴进欧姆龙PLC，如图：

⑥调用气缸FB，这里我用梯形图展示引脚关联，清晰直观：

可以看到，直接利用平台功能填写引脚，就完成了与物理点位的耦合。

建议：还是使用ST文本语言调用。这样我们可以在Excel中做文章——通过设备配置表索引工位号、气缸号，自动生成FB调用代码，粘贴进PLC即可。ST如图：

只需要有这样一张设备配置表，索引其工位号，气缸号，便可以自动生成这些实例，粘贴到PLC，PLC注册变量即可：

⑦程序内部解耦，有人可能会问：为什么还有CY_IN、CY_OUT？

这是对实际物理点位的极致解耦。好处是：

后续查找问题时，可以直接索引EC.EM1.CYIn[1].Sensor这类结构体变量，无需找物理点位名称

HMI做界面块时，可以直接使用结构体封装，一个模板搞定所有气缸，关于气缸的控制过程具体实现，再此不占用过多篇幅，如何控制，监控，报警，各家公司都有这自己的一套过程，如果您的公司目前气缸控制还没有封装，后面建议封装成过程块，过程点位作为形参，由功能块实例写入

对与硬件耦合，功能块内部其实就是一层映射，将物理点位映射到CY_IN、CY_OUT，如图：

⑧HMI界面，HMI中继续使用EM1.CYIn、EM1.CYOut、EM1.CY这些结构体做模板界面。调用模板时，只需更改工位号、气缸号，就能快速生成多个气缸界面：

欧姆龙的触摸屏支持IAG块，可实现相同功能。其他品牌触摸屏也有相似功能。关键在于——描述气缸的结构体必须规范统一。

三、总结

回顾整个改造过程，我们实现了这样一条路径：

开始→物理点（M01U02A3）

→业务名称（EM1_CY1_XV1）

→由此后面开始已经封装完成

→结构体成员（EC.EM1.CYIn[1].Sensor_V）

→ HMI模板（EM1.CYIn）

每一步都遵循同一个原则：只描述一次，只耦合一次。

物理点的位置信息，只在IO表和图纸中描述

业务名称，只在IO映射时与物理点关联一次

结构体封装，为上层逻辑提供统一接口

HMI模板，基于结构体一键生成

这就像我们开头的冰箱比喻——“打开冰箱放动物”这个逻辑只写一次，至于冰箱是胖是高、动物是大象还是长颈鹿，全交给配置去描述。

文章仅以气缸为对象，对于设备急停，设备风扇，设备门禁，工位过程，等等都是一样的思路。

感谢万泉河老师的留言启发，也感谢那些在评论区激烈讨论的同行们。所谓“过程控制”与“非标自动化”的分界线，其实只是我们给自己设的限。跳出技术手段，从更高维度看问题，你会发现：

所谓控制，归根结底都是对象的控制。所谓过程，归根结底都可以封装。

最后，说些题外话

今天是我和女朋友在一起521天的纪念日。感谢她一直以来的陪伴和支持，做项目的时候，总是被图纸、程序、出差调试填满，疏于对她的陪伴。回过头想，女朋友一直在背后支撑着我——程序卡壳的时候，出差累到不想动的时候，她的鼓励和温柔，总能让我重新找回状态。

生活中不只有工作，还有爱你的，和你爱的人更加需要珍惜，一起规划未来，一起努力进步，好好对待彼此。

所以这篇文章，也送给所有在背后支持工程师的人。

祝大家生活愉快，工作顺心。