自动化四层架构 · 第三篇
小C：
老A！前两篇我们把概念和为什么选这种架构的理由聊透了，看得我手心发痒。今天你必须带我掀开引擎盖，看看这套四层架构的实操代码了！
之前听你说“不到100行 Python 代码就能搞定”，我真的有点不敢相信。
老A：
哈哈，工业控制不等于故弄玄虚。今天我们直接上干货，看看打通 TwinCAT PLC 和 Web 浏览器的核心桥梁是怎么搭建的。
我们这套转台式洗车机交互的核心，其实就跑在Pad上的一个 main.py 脚本里。
来，看着我的屏幕，我把核心连接层的代码写给你看。
Python (main.py)
import eel
import pyads
# 1. 建立与 TwinCAT PLC 路由的连接
plc = pyads.Connection('192.168.1.9', 801)
plc.open()
symbol_dic = {}
# 2. 将读取 PLC 变量的函数暴露给前端 Web
@eel.expose
def read_plc(name):
try:
if name in symbol_dic:
return symbol_dic[name].value
return plc.read_by_name(name)
except Exception as e:
print(f"PLC Read Error: {e}")
return None
# 3. 将写入 PLC 变量的函数暴露给前端 Web
@eel.expose
def write_plc(name, val):
try:
if name in symbol_dic:
symbol_dic[name].value = val
else:
plc.write_by_name(name, val)
return True
except Exception as e:
print(f"PLC Write Error: {e}")
return False
eel.init('web')
eel.start('main.html', size=(1920, 1080))
小C：
我的天！就这 30 多行代码，就完成了 PLC 通信和本地 Web 服务器的架设？
那 @eel.expose 到底起到了什么魔术效果？
老A：
它就是我第一篇里说的“电话线”。
在 Python 函数上加上这个装饰器，Eel 就会在后台自动用 WebSocket 将这个函数注册到浏览器的 JavaScript 环境里。
这样，前端网页的 JavaScript 就可以像调用本地函数一样，直接跨界调用 Python 的函数！
小C：
那前端 JS 到底要怎么写才能给 PLC 发数据？
老A：
前端更简单。首先，在你的 HTML 文件里引入一行：
<script src="/eel.js"></script>
这就够了，你不需要写任何复杂的 WebSocket 连接代码，Eel 会自动在后台连通。
接着，在 JavaScript 里，如果你想让转台（Turntable）开始旋转，或者点动清洗臂，你只需要写一个异步函数去 await Python 的暴露接口：
JavaScript (HMI Action)
// 前端 JavaScript 异步调用示例
async function startTurntable() {
let success = await eel.write_plc(".bTurntable_Start", true)();
if (success) {
console.log("转台启动成功！");
} else {
console.log("指令下发失败！");
}
}
小C：
等等，老A，我注意到你在 eel.write_plc(...) 后面不仅带了参数，还多带了一对空括号 ()，这是为什么？
老A：
（赞许地看了小C一眼）
好眼力！因为跨语言调用是一个网络异步交互的过程。
在 JS 里，eel.write_plc(name, val) 执行后，它实际上返回的是一个 JS 的 Promise。后面紧跟的那对括号 () 是在真正触发这个 Promise 的执行，然后通过前面的 await 关键字等待 Python 后端的真实通信返回。
这就是 Eel 的通信规则，虽然多了一对括号，但比起自己手写 AJAX 请求或者维护原始 WebSocket 报文，已经简洁得太多了。
小C：
确实！那我们上次讨论的，用 ES6 工厂类把这 300 多个 PLC 变量优雅封装在前端，具体在代码里是怎么体现的？
老A：
这就是我们前端 PlcControlFactory.js（控件工厂）的核心职责。
既然我们要控制 50 多个阀门、8 个轴的状态，我们决不能在网页里为每一个按钮都手写一遍点击事件。
我们要用 ES6 类把它们的交互逻辑提取出来。我写一个开关阀门控件（PlcToggleControl）的精简版类定义给你：
JavaScript (PlcControlFactory.js)
class PlcToggleControl {
constructor(domId, plcVarName) {
this.domId = domId;
this.plcVarName = plcVarName;
this.element = document.getElementById(domId);
if (this.element) {
this.element.addEventListener('click', () => this.click_button());
}
}
async click_button() {
let currentVal = await eel.read_plc(this.plcVarName)();
if (currentVal !== null) {
await eel.write_plc(this.plcVarName, !currentVal)();
}
}
async read_value() {
let val = await eel.read_plc(this.plcVarName)();
if (this.element) {
if (val === true) {
this.element.classList.add('btn-active');
} else {
this.element.classList.remove('btn-active');
}
}
}
}
小C：
太优雅了！把点击时的 PLC 写入，和轮询时的状态更新直接绑定在了一个对象身上。
那我们新加设备时，怎么利用这个类呢？
老A：
新加设备时，我们只需要在 supplements_object.js 里做一个配置矩阵。
你看这行代码，我们把所有的阀门和指示灯放在一个数组里实例化：
JavaScript (supplements_object.js)
const all_ob = [
new PlcToggleControl('btn-water-pump', '.bPump_Water_Start'),
new PlcToggleControl('btn-foam-machine', '.bFoam_Machine_Active'),
new PlcToggleControl('btn-air-valve', '.bValve_Air_01'),
// ... 增加配置即可
];
小C：
我明白了！HTML 结构不需要去改它，也不用去每一个元素里写 onclick 绑定。
那如何驱动这些对象进行实时轮询刷新呢？
老A：
我们建立一个统一的刷新调度器（object_update.js），每 500 毫秒去遍历这个数组，执行它们的渲染函数就行了：
JavaScript (object_update.js)
setInterval(async () => {
for (let obj of all_ob) {
try {
await obj.read_value();
} catch (e) {
console.error("更新失败:", e);
}
}
}, 500);
小C：
妙啊！用 all_ob 统一管理所有的控件，轮询调度器只管按时去抽鞭子，每个控件自己去调 eel.read_plc 去跟 TwinCAT 通信，然后刷新自己的 DOM 状态。
难怪上次看你的 HMI 重构记录，main.html 缩减了 40% 的代码，原来繁重的 HTML 结构全都被这几段简短的 JavaScript 代替了！
老A：
是的。这就是“代码代替配置”的威力。
工业 HMI 的控件虽然多，但它们的行为模式非常固定——要么是点击写入、按压写1松开写0（点动），要么是只读指示灯或数值显示。
只要用 ES6 工厂类把这 11 种基本控件类型（Toggle、Momentary、ValueDisplay等）封装好，剩下的工作就是写配置了，连刚毕业的新人也不会把代码写乱。
小C：
老A，我还有一个疑问：在 500ms 的轮询中，有这么多控件在同时发 eel.read_plc 请求，底层的 ADS 通信不会被塞满甚至崩溃吗？
老A：
这是一个非常深刻的问题！也是我们这套方案在实际调试中会踩到的“大坑”之一。
高频且大量的 ADS 通信，确实会对 PLC 通信网关造成巨大压力。
至于我们是如何通过 pyads.Symbol 的绑定和低负载轮询策略来解决这个瓶颈的——
咱们留到下一篇：《自动化四层架构 · 现场调试与血泪踩坑指南》再细聊。
小C：
（急切地翻开小本子记录）
好！下回我一定要听听你是怎么在现场把这套系统调试上线的！
