朱子纯 / erp-framework-wiki

06-hardware.md 4.87 KB

切片 6 — 硬件集成模块（xlyPlc）（可选）

本切片面向会接触印刷车间的人。如果你只读写元数据，可以跳过。

xly 是印刷行业 ERP。在车间，印刷机由 PLC（programmable logic controller，工业自动化控制器）控制。每台机器暴露一串状态：运行 / 停止 / 故障、当前速度、当前张数、当前工单号等。ERP 希望实时把这些记录到正确工单上。xly 的 xlyPlc Spring Boot 模块就是做这件事的桥。

本切片覆盖桥的架构、每机型 profile 机制，以及硬件专用代码与通用框架之间的边界。

记录对象
模块 xlyPlc（代码库中的兄弟 Spring Boot 服务）
方向 单向：PLC → ERP DB（不向印刷机回发命令）
节奏 定时轮询（Quartz PlcScheduledTasks）
每机型区分 Spring profile（-S10、-T0、-T1、-15S、-CT、-yt、-pro）
写入表 mftProduceReportMachineState（dev 中约 207k 行）及相关机器状态从表

模块有多小

xlyPlc/src/main/java/com/xly/ 只有五个文件：

文件 角色
PlcApplicationBoot.java Spring Boot 入口
web/scheduler/PlcScheduledTasks.java Quartz 驱动轮询循环
web/scheduler/PlcRunStatus.java 当前轮询周期的内存状态
web/scheduler/service/PlcToErpService.java 接口
web/scheduler/service/impl/PlcToErpServiceImpl.java 实现：读 PLC、写 DB

这就是整个桥。每个机型的协议处理通过每 profile 的 application-*.yml 和可选原生串口代码（xlyRxtx，当前在 build 中禁用，见维护人员参考：部署）引入的库完成。

每机型 profile

xlyPlc/src/main/resources/ 中有 9 个 YAML 文件：默认配置加 8 个命名 profile：

application.yml          （默认，选择 profile）
application-dev.yml      （开发配置）
application-S10.yml      （S10 机型）
application-T0.yml       （T0 机型）
application-T1.yml       （T1 机型）
application-15S.yml      （15S 机型）
application-CT.yml       （CT 机型）
application-yt.yml       （某客户命名 profile）
application-pro.yml      （生产）

某个 xlyPlc 实例启动时只激活一个 profile，例如 -Dspring.profiles.active=S10。profile 携带该机型的串口设置、轮询频率、字节协议参数和目标 ERP DB 连接。通常是每台印刷机一个 xlyPlc 部署，或每个机型 / 机器一个部署。这是运维问题，不是客户可见功能。

写入什么

轮询循环读取 PLC 寄存器，把它们转成 ERP 领域行，并写入：

  • mftProduceReportMachineState：机器状态时间序列（运行 / 停止 / 故障），此 dev DB 中 207,112 行。
  • 适用时写入相关 mftProductionReport* 从表。

行落库后，ERP 其余部分像处理普通数据一样处理：

  • viw_* 视图把它们聚合进车间看板。
  • 标准切片 1 风格模块渲染这些视图。
  • 元数据层（切片 4 定制）允许客户给看板加字段，而不碰桥接代码。

框架 / 硬件边界

这是 xly 对复杂问题给出的最干净故事：

  • 线以上（xlyEntry、xlyApi、所有元数据机制）：通用框架。 不知道印刷机、PLC 或字节协议。
  • 线以下（xlyPlc）：硬件专用。 知道如何与机器通信。

二者只通过数据库通信。桥写行，框架读行。没有 RPC、没有共享进程内状态、没有回调。这使 xlyPlc：

  • 可独立部署；多个客户把它运行在靠近印刷机的机器上，与中心 ERP 服务器分离。
  • 可独立失败：桥崩溃时，框架继续在旧机器状态上运行；框架宕机时，桥继续写入，框架恢复后看到缓冲行。
  • 难以在没有真实印刷机的情况下端到端测试。多数 CI 测试会 stub PLC 读取。

本切片引入的概念

本切片刻意作为边界案例，不引入新的框架概念。它用于说明：数据驱动运行时只处理框架问题；一旦行写入数据库，框架不关心它来自 PM 在后台手输、客户在前台提交，还是印刷机 PLC 通过 xlyPlc 推送。

本切片使用的参考

  • 维护人员：多服务部署：xlyPlc 是可运行服务之一。部署章节需要补充车间部署说明（每机型一个桥或每机器一个桥）。

待验证项

  1. 线缆协议。 每个机型有不同字节协议；每个 application-<model>.yml 携带参数。按机型记录协议是独立小众章节。
  2. 桥 → ERP DB 延迟。 每个 profile 的轮询间隔是多少？如何影响车间看板刷新？值得记录。
  3. 为什么 xlyRxtx 在 settings.gradle 中禁用。 RXTX 是原生串口库；build 排除了它。需要确认 xlyPlc 当前是否不依赖串口，还是只在特定部署中需要。