1. 工业控制器的新物种当PLC、HMI和边缘AI挤进同一个盒子第一次看到宏集DC-Pi这个产品定义的时候我脑子里蹦出来的画面是一个配电柜里原本要塞三台设备——PLC负责逻辑控制HMI负责人机交互工控机负责跑视觉或数据分析——现在一台巴掌大的控制器全包了。这不是简单的“三合一”硬件堆叠而是把工业控制最核心的三条技术路线在边缘侧做了一次真正的架构级融合。先说清楚这个标题里的几个关键词到底意味着什么。PLC可编程逻辑控制器工业自动化的老黄牛负责跑梯形图、做IO逻辑、控制电机阀门讲究的是确定性和实时性。HMI人机界面就是操作工面前那块触摸屏显示温度压力、报警记录、参数设置。边缘AI则是近几年随着算力下沉到设备端才真正落地的东西——在本地跑推理不依赖云端做视觉检测、异常诊断、预测性维护。这三样东西过去是三个独立的硬件、三套独立的开发工具、三条独立的通信链路现在宏集DC-Pi试图把它们揉在一起。我之所以对这个方向特别关注是因为过去两年在工厂现场做项目最头疼的就是“数据孤岛”和“设备堆叠”。一个中等规模的产线电柜里PLC、触摸屏、工控机、网关、交换机塞得满满当当接线复杂、故障点多、维护成本高。更麻烦的是PLC的数据要传给工控机做分析往往要经过OPC UA、Modbus TCP转好几道手延迟不说调试起来能把人逼疯。DC-Pi这种融合架构本质上是在解决“控制与计算分离”的老问题——让控制层和智能层在同一个硬件平台上共享内存、共享时钟、共享数据总线。这篇文章适合谁看如果你是做PLC编程的工程师想了解边缘AI怎么和梯形图逻辑配合如果你是做上位机或视觉的开发者想知道怎么在工业控制器上直接部署模型如果你是设备集成商或产线负责人在评估下一代控制架构的选型——那这篇内容应该能给你一些来自实际项目视角的参考。我会从架构设计、核心细节、实操要点、常见问题几个维度把这个“工业控制遇上AI”的融合方案拆开来讲。2. 融合架构的底层逻辑为什么不是简单堆硬件2.1 传统三件套方案的痛点在哪里先说说我们过去是怎么干的。一个典型的自动化工作站PLC负责实时控制扫描周期通常在1到10毫秒HMI通过串口或以太网和PLC通信刷新率在100到500毫秒工控机跑Windows或Linux通过OPC UA从PLC拿数据做数据库存储、报表生成或者视觉处理。这三者之间的数据流是“PLC→HMI”和“PLC→工控机”两条独立链路。问题出在三个地方。第一是数据一致性HMI上显示的温度值和工控机数据库里存的值可能因为采样时刻不同而对不上排查故障时经常扯皮。第二是通信延迟PLC的数据要经过协议转换才能到工控机做闭环控制根本来不及只能做事后分析。第三是硬件成本与空间三台设备三套电源三套外壳电柜尺寸小一点都不行。我去年做过一个包装机械的项目客户要求加视觉检测判断包装袋封口是否完整。原来的方案是PLC控制动作工控机加工业相机做视觉两者通过IO信号握手——相机检测到不良品输出一个开关量给PLCPLC再控制剔除气缸。这个方案能跑但问题是相机检测结果只有“好/坏”两个状态具体缺陷类型、缺陷位置、置信度这些信息全丢了没法做质量追溯。而且IO握手有延迟高速产线上偶尔会漏剔。2.2 DC-Pi的融合思路共享内存实时任务调度宏集DC-Pi的做法我理解是在一个硬件平台上跑两个操作系统域或者一个经过实时补丁的Linux内核把PLC运行时、HMI运行时和AI推理引擎都跑在上面。关键不在于“跑在一起”而在于任务调度和内存共享。PLC的实时任务优先级最高保证扫描周期稳定HMI的刷新任务优先级中等允许一定抖动AI推理任务优先级最低但可以利用PLC任务的空闲时间片。三者之间通过共享内存交换数据PLC采集的IO状态、寄存器值AI推理的结果、置信度HMI的按钮事件、参数修改全部在一张内存表里读写延迟在微秒级。这个架构的好处是AI推理可以直接读取PLC的实时数据不需要经过任何协议转换AI的输出也可以直接写回PLC的寄存器参与控制逻辑。比如视觉检测到封口不良不再是简单的开关量而是把缺陷类型、位置坐标、置信度直接写进PLC的DB块PLC根据置信度决定是立即剔除还是报警提示。HMI上也能实时显示这些信息操作工能看到具体是什么缺陷。2.3 边缘AI在工业控制中的定位这里要澄清一个概念边缘AI不是要把云端的大模型塞进控制器。工业场景下的边缘AI更多是轻量级的推理任务——目标检测、分类、异常检测、时序预测。模型大小通常在几MB到几十MB推理延迟要求在几十毫秒以内。DC-Pi这类控制器的算力我推测在几个TOPS级别足够跑YOLO系列的目标检测或者轻量级的时序模型。关键是它和PLC运行时共享时钟AI推理的结果可以打上精确的时间戳和PLC的IO数据对齐。这在做故障分析时特别有用——你知道AI是在哪个扫描周期、哪个工位、哪个动作阶段检测到异常的。注意边缘AI的模型部署不是一劳永逸的。产线换型、光照变化、产品迭代都会导致模型精度下降。我在实际项目中见过太多“上线时准得很三个月后天天误报”的案例。模型更新机制必须提前设计好。3. 核心细节拆解PLC、HMI、AI三者的协同机制3.1 PLC运行时确定性不能丢不管上面跑多少AI任务PLC的实时性是底线。DC-Pi的PLC运行时我判断是基于CODESYS或者类似的软PLC方案。CODESYS在工业界用得很多支持IEC 61131-3标准梯形图、结构化文本、功能块图都能写。它的实时性通过Linux的PREEMPT_RT补丁或者Xenomai双内核来实现扫描周期可以做到1毫秒甚至更低。这里有个关键点AI任务不能阻塞PLC任务。如果AI推理占用了CPU资源导致PLC扫描周期抖动那就是生产事故。所以DC-Pi的任务调度策略应该是PLC任务独占一个CPU核心AI任务跑在另一个核心上通过共享内存通信。如果硬件是四核处理器可能两个核给PLC一个核给HMI一个核给AI。我在测试类似架构时会特别关注一个指标最坏情况下的扫描周期抖动。平均值好看没用要看99.9%分位数。如果标称1毫秒扫描周期实际抖动超过200微秒那高速IO控制就会出问题。3.2 HMI运行时不只是显示HMI在DC-Pi里的角色比传统触摸屏要重。传统HMI就是显示和输入逻辑都在PLC里。但在融合架构下HMI运行时可以直接访问AI推理的结果显示缺陷图片、置信度曲线、历史趋势。它也可以直接调用AI接口比如操作工点击“重新检测”按钮HMI直接触发一次AI推理不需要经过PLC中转。HMI的开发工具我推测是支持Web技术的比如HTML5JavaScript或者基于Qt的框架。这样开发效率高界面灵活还能远程访问。但工业现场对HMI的要求是稳定、响应快、断电不丢数据。Web技术的HMI在低端硬件上可能会有卡顿需要做好资源隔离。3.3 AI推理引擎模型怎么进去结果怎么出来AI推理引擎在DC-Pi上的部署方式常见的有几种ONNX Runtime、TensorRT、OpenVINO或者厂商自研的推理框架。模型训练通常在PC或服务器上完成导出成ONNX格式再转换成目标平台支持的格式。推理的输入来源可以是工业相机通过USB或GigE接口也可以是PLC采集的时序数据振动、温度、电流。推理的输出可以写回PLC寄存器也可以直接显示在HMI上或者上传到数据库。这里有个实操细节图像预处理的时间往往比推理本身还长。工业相机采集的原始图像要做去噪、裁剪、缩放、归一化这些操作如果放在CPU上做可能比模型推理还慢。DC-Pi如果有GPU或NPU预处理也应该尽量放在加速器上做。3.4 三者之间的数据流设计我画一个典型的数据流工业相机采集图像→AI推理引擎做缺陷检测→结果写入共享内存→PLC运行时读取结果→根据置信度决定剔除或报警→HMI运行时读取结果→显示缺陷图片和统计信息。这个链路里PLC和AI之间的数据交换是关键。共享内存的读写要加锁吗如果AI写的时候PLC正在读会不会读到半截数据通常的做法是双缓冲或者环形缓冲区AI写一个缓冲区PLC读另一个通过原子操作切换。这些细节在文档里不一定写但实际开发时必须考虑。4. 实操过程从零搭建一个融合控制方案4.1 硬件选型与接线要点假设我们要用DC-Pi做一个视觉分拣工作站。硬件清单DC-Pi控制器一台、工业相机一台GigE接口、光电传感器若干、气缸和电磁阀一套、24V开关电源、触摸屏如果DC-Pi本身不带显示。接线时要注意相机的网口最好独立走一个网段不要和PLC的EtherCAT或Modbus TCP混在一起避免带宽争抢。光电传感器的信号进DC-Pi的DI端口电磁阀的控制线从DO端口出。如果DC-Pi的IO点数不够可以通过EtherCAT扩展模块。实操心得工业相机的触发信号最好由PLC的DO直接给出而不是软件触发。硬件触发的时间精度在微秒级软件触发受操作系统调度影响可能差几毫秒。在高速产线上几毫秒的偏差就可能导致图像模糊或者位置偏移。4.2 PLC程序框架设计PLC程序我习惯分几个任务主任务负责逻辑控制周期1毫秒通信任务负责和AI引擎交换数据周期5毫秒HMI交互任务负责处理按钮和显示刷新周期50毫秒。主任务的逻辑等待光电传感器信号→触发相机→等待AI结果→根据结果控制气缸。这里有个同步问题AI推理需要时间比如20毫秒主任务不能干等。我的做法是状态机触发相机后进入“等待AI结果”状态主任务继续扫描其他逻辑等AI结果写入共享内存后通过一个标志位通知主任务。4.3 AI模型训练与部署模型训练在PC上做。收集产线上的缺陷样本标注好类别和位置用YOLOv5或YOLOv8训练。训练完后导出ONNX再用DC-Pi支持的转换工具转成目标格式。部署时要注意输入尺寸和归一化参数。训练时的输入是640x640部署时也要保持一致。归一化的均值方差训练和推理必须一样否则精度会掉。推理代码通常是一个独立的进程通过共享内存和PLC运行时通信。代码框架大概是初始化推理引擎→循环读取相机图像→预处理→推理→后处理→写入共享内存。# 伪代码示例AI推理进程 import shared_memory import camera import inference_engine shm shared_memory.open(ai_result) engine inference_engine.load(defect_model.onnx) cam camera.open(gige0) while True: img cam.capture() input_tensor preprocess(img, size(640,640)) output engine.infer(input_tensor) boxes, scores, classes postprocess(output) shm.write({boxes: boxes, scores: scores, classes: classes, timestamp: time.now()})4.4 HMI界面开发HMI界面至少要有几个区域实时图像显示、检测结果统计、参数设置、报警记录。实时图像可以用MJPEG流或者直接显示推理后的标注图。统计信息从共享内存读取每秒刷新一次。参数设置里要能调整置信度阈值、IO触发延时、剔除延时这些关键参数。这些参数存在PLC的保持寄存器里断电不丢。4.5 联调与性能测试联调分三步先单独测试PLC逻辑用模拟IO信号验证状态机再单独测试AI推理用静态图片验证精度最后联调用实际产线跑。性能测试要记录几个指标PLC扫描周期的最坏值、AI推理的平均延迟和95分位延迟、从触发相机到气缸动作的总延迟。总延迟如果超过产线节拍方案就不可行。5. 常见问题与排查技巧实录5.1 PLC扫描周期抖动大怎么办现象PLC程序跑着跑着扫描周期从1毫秒跳到5毫秒。排查思路先看CPU占用率如果AI推理进程占了太多CPU把AI任务绑到另一个核心上。再看内存如果共享内存频繁读写导致缓存失效优化数据交换频率。最后看中断网卡中断如果太频繁会打断PLC任务可以调整中断亲和性。5.2 AI推理结果和PLC数据对不上现象HMI上显示的缺陷位置和实际位置差了几毫米。原因通常是时间戳不对齐。AI推理的结果要打上相机触发时刻的时间戳PLC读取时根据时间戳匹配对应的编码器位置。如果时间戳精度不够用硬件触发信号同时锁存编码器值。5.3 模型精度下降怎么排查先看输入图像有没有变化光照、焦距、产品颜色。再看预处理参数有没有被改动。如果都没问题可能是模型过拟合了需要补充新样本重新训练。我通常会在产线上保留一个“影子模式”AI推理结果不参与控制只记录用来监控精度变化。5.4 HMI界面卡顿HMI卡顿通常是资源争抢。把HMI进程的优先级调低但保证它不会被饿死。图像显示用硬件加速不要用CPU软渲染。刷新率不要设太高人眼看到25帧就够了设60帧纯属浪费。5.5 常见问题速查表问题现象可能原因排查方法解决措施PLC扫描周期抖动AI任务占CPUtop查看CPU占用绑核、限制AI任务CPU配额AI结果与PLC数据不一致时间戳未对齐检查时间戳来源硬件触发同步锁存模型精度下降输入分布变化对比训练和推理输入补充样本重新训练HMI卡顿资源争抢查看内存和CPU调整优先级、硬件加速相机丢帧网络带宽不足检查网口流量独立网段、降低分辨率推理延迟大预处理在CPUprofile各阶段耗时预处理放到加速器避坑技巧DC-Pi这类融合控制器散热是个容易被忽视的问题。PLC任务和AI任务同时跑CPU满载如果电柜通风不好夏天很容易过热降频。我一般会在电柜里加一个温度传感器接到PLC的AI通道超过45度就降载或者报警。6. 融合控制架构的适用场景与选型建议6.1 什么场景适合用融合控制器不是所有项目都适合上DC-Pi这种融合架构。我总结了几类适合的场景第一类是空间受限的设备比如小型包装机、桌面级自动化设备电柜里塞不下三台设备。第二类是数据闭环要求高的场景比如视觉伺服、力控打磨AI结果要实时参与控制。第三类是分布式产线每个工位一个控制器本地做AI推理只把统计结果上传减少网络依赖。不适合的场景也很明确超高速产线扫描周期要求100微秒以下的还是老老实实用专用PLCAI模型特别大的比如跑Transformer的边缘控制器算力不够对功能安全有认证要求的融合架构的认证成本很高。6.2 选型时的关键参数选DC-Pi这类产品时我关注几个硬指标CPU核心数和主频、NPU或GPU的算力TOPS、内存大小至少4GB、存储eMMC或SSD、IO接口类型和数量、支持的通信协议EtherCAT、Modbus TCP、OPC UA、Profinet。软件方面看PLC运行时的品牌和授权方式、AI推理框架的支持列表、HMI开发工具的上手难度。6.3 成本对比融合方案 vs 传统方案粗略算一笔账传统方案PLC3000元HMI2000元工控机5000元相机3000元电柜空间和接线2000元合计约15000元。融合方案DC-Pi8000元相机3000元电柜1000元合计约12000元。硬件成本省了20%左右但更大的价值在于调试时间和故障点的减少。传统方案三套软件三套通信调试至少一周融合方案一套工具链调试两三天。6.4 从传统架构迁移的注意事项如果现有产线要改造不要一次性全换。我的建议是分步走第一步保留原有PLC和HMI只加一个边缘AI控制器做视觉检测通过IO和原PLC握手。第二步把HMI功能迁移到边缘控制器上原HMI作为备用。第三步把PLC逻辑也迁移过去原PLC退役。每一步都要有回退方案产线不能停。7. 我在实际项目中的几点体会做工业控制和AI融合的项目最大的挑战不是技术本身而是思维方式的转变。做PLC的人习惯确定性输入决定输出时序严格做AI的人习惯概率性模型有置信度有误报漏报。这两拨人坐在一起开会经常鸡同鸭讲。我的经验是在系统设计阶段就要明确边界。哪些逻辑必须用PLC做保证确定性哪些判断可以交给AI允许一定误差。比如安全相关的急停、限位必须走PLC硬逻辑缺陷检测、质量分级可以走AI但要有置信度阈值和人工复核机制。另一个体会是数据比模型重要。很多项目失败不是因为模型不好而是因为训练数据不代表实际产线分布。我在项目前期会花大量时间做数据采集把各种工况、各种缺陷、各种光照条件都覆盖到。上线后还要持续收集数据做增量训练。最后不要迷信端到端。有些方案鼓吹从相机到控制全部用AIPLC只做执行器。这在实验室可以在工业现场风险太大。AI负责感知和判断PLC负责逻辑和安全这个分工在可预见的未来都不会变。DC-Pi这类融合控制器价值在于让两者之间的数据流动更顺畅而不是让AI取代PLC。最后分享一个小技巧在DC-Pi上跑AI推理时把模型的输入尺寸设成32的倍数比如640x640或者416x416。很多推理引擎对非32倍数的尺寸会做padding浪费算力。另外如果相机分辨率是500万像素不要直接缩放到640先裁剪ROI再缩放能保留更多细节。
工业控制器融合架构：PLC、HMI与边缘AI的协同设计与实践
1. 工业控制器的新物种当PLC、HMI和边缘AI挤进同一个盒子第一次看到宏集DC-Pi这个产品定义的时候我脑子里蹦出来的画面是一个配电柜里原本要塞三台设备——PLC负责逻辑控制HMI负责人机交互工控机负责跑视觉或数据分析——现在一台巴掌大的控制器全包了。这不是简单的“三合一”硬件堆叠而是把工业控制最核心的三条技术路线在边缘侧做了一次真正的架构级融合。先说清楚这个标题里的几个关键词到底意味着什么。PLC可编程逻辑控制器工业自动化的老黄牛负责跑梯形图、做IO逻辑、控制电机阀门讲究的是确定性和实时性。HMI人机界面就是操作工面前那块触摸屏显示温度压力、报警记录、参数设置。边缘AI则是近几年随着算力下沉到设备端才真正落地的东西——在本地跑推理不依赖云端做视觉检测、异常诊断、预测性维护。这三样东西过去是三个独立的硬件、三套独立的开发工具、三条独立的通信链路现在宏集DC-Pi试图把它们揉在一起。我之所以对这个方向特别关注是因为过去两年在工厂现场做项目最头疼的就是“数据孤岛”和“设备堆叠”。一个中等规模的产线电柜里PLC、触摸屏、工控机、网关、交换机塞得满满当当接线复杂、故障点多、维护成本高。更麻烦的是PLC的数据要传给工控机做分析往往要经过OPC UA、Modbus TCP转好几道手延迟不说调试起来能把人逼疯。DC-Pi这种融合架构本质上是在解决“控制与计算分离”的老问题——让控制层和智能层在同一个硬件平台上共享内存、共享时钟、共享数据总线。这篇文章适合谁看如果你是做PLC编程的工程师想了解边缘AI怎么和梯形图逻辑配合如果你是做上位机或视觉的开发者想知道怎么在工业控制器上直接部署模型如果你是设备集成商或产线负责人在评估下一代控制架构的选型——那这篇内容应该能给你一些来自实际项目视角的参考。我会从架构设计、核心细节、实操要点、常见问题几个维度把这个“工业控制遇上AI”的融合方案拆开来讲。2. 融合架构的底层逻辑为什么不是简单堆硬件2.1 传统三件套方案的痛点在哪里先说说我们过去是怎么干的。一个典型的自动化工作站PLC负责实时控制扫描周期通常在1到10毫秒HMI通过串口或以太网和PLC通信刷新率在100到500毫秒工控机跑Windows或Linux通过OPC UA从PLC拿数据做数据库存储、报表生成或者视觉处理。这三者之间的数据流是“PLC→HMI”和“PLC→工控机”两条独立链路。问题出在三个地方。第一是数据一致性HMI上显示的温度值和工控机数据库里存的值可能因为采样时刻不同而对不上排查故障时经常扯皮。第二是通信延迟PLC的数据要经过协议转换才能到工控机做闭环控制根本来不及只能做事后分析。第三是硬件成本与空间三台设备三套电源三套外壳电柜尺寸小一点都不行。我去年做过一个包装机械的项目客户要求加视觉检测判断包装袋封口是否完整。原来的方案是PLC控制动作工控机加工业相机做视觉两者通过IO信号握手——相机检测到不良品输出一个开关量给PLCPLC再控制剔除气缸。这个方案能跑但问题是相机检测结果只有“好/坏”两个状态具体缺陷类型、缺陷位置、置信度这些信息全丢了没法做质量追溯。而且IO握手有延迟高速产线上偶尔会漏剔。2.2 DC-Pi的融合思路共享内存实时任务调度宏集DC-Pi的做法我理解是在一个硬件平台上跑两个操作系统域或者一个经过实时补丁的Linux内核把PLC运行时、HMI运行时和AI推理引擎都跑在上面。关键不在于“跑在一起”而在于任务调度和内存共享。PLC的实时任务优先级最高保证扫描周期稳定HMI的刷新任务优先级中等允许一定抖动AI推理任务优先级最低但可以利用PLC任务的空闲时间片。三者之间通过共享内存交换数据PLC采集的IO状态、寄存器值AI推理的结果、置信度HMI的按钮事件、参数修改全部在一张内存表里读写延迟在微秒级。这个架构的好处是AI推理可以直接读取PLC的实时数据不需要经过任何协议转换AI的输出也可以直接写回PLC的寄存器参与控制逻辑。比如视觉检测到封口不良不再是简单的开关量而是把缺陷类型、位置坐标、置信度直接写进PLC的DB块PLC根据置信度决定是立即剔除还是报警提示。HMI上也能实时显示这些信息操作工能看到具体是什么缺陷。2.3 边缘AI在工业控制中的定位这里要澄清一个概念边缘AI不是要把云端的大模型塞进控制器。工业场景下的边缘AI更多是轻量级的推理任务——目标检测、分类、异常检测、时序预测。模型大小通常在几MB到几十MB推理延迟要求在几十毫秒以内。DC-Pi这类控制器的算力我推测在几个TOPS级别足够跑YOLO系列的目标检测或者轻量级的时序模型。关键是它和PLC运行时共享时钟AI推理的结果可以打上精确的时间戳和PLC的IO数据对齐。这在做故障分析时特别有用——你知道AI是在哪个扫描周期、哪个工位、哪个动作阶段检测到异常的。注意边缘AI的模型部署不是一劳永逸的。产线换型、光照变化、产品迭代都会导致模型精度下降。我在实际项目中见过太多“上线时准得很三个月后天天误报”的案例。模型更新机制必须提前设计好。3. 核心细节拆解PLC、HMI、AI三者的协同机制3.1 PLC运行时确定性不能丢不管上面跑多少AI任务PLC的实时性是底线。DC-Pi的PLC运行时我判断是基于CODESYS或者类似的软PLC方案。CODESYS在工业界用得很多支持IEC 61131-3标准梯形图、结构化文本、功能块图都能写。它的实时性通过Linux的PREEMPT_RT补丁或者Xenomai双内核来实现扫描周期可以做到1毫秒甚至更低。这里有个关键点AI任务不能阻塞PLC任务。如果AI推理占用了CPU资源导致PLC扫描周期抖动那就是生产事故。所以DC-Pi的任务调度策略应该是PLC任务独占一个CPU核心AI任务跑在另一个核心上通过共享内存通信。如果硬件是四核处理器可能两个核给PLC一个核给HMI一个核给AI。我在测试类似架构时会特别关注一个指标最坏情况下的扫描周期抖动。平均值好看没用要看99.9%分位数。如果标称1毫秒扫描周期实际抖动超过200微秒那高速IO控制就会出问题。3.2 HMI运行时不只是显示HMI在DC-Pi里的角色比传统触摸屏要重。传统HMI就是显示和输入逻辑都在PLC里。但在融合架构下HMI运行时可以直接访问AI推理的结果显示缺陷图片、置信度曲线、历史趋势。它也可以直接调用AI接口比如操作工点击“重新检测”按钮HMI直接触发一次AI推理不需要经过PLC中转。HMI的开发工具我推测是支持Web技术的比如HTML5JavaScript或者基于Qt的框架。这样开发效率高界面灵活还能远程访问。但工业现场对HMI的要求是稳定、响应快、断电不丢数据。Web技术的HMI在低端硬件上可能会有卡顿需要做好资源隔离。3.3 AI推理引擎模型怎么进去结果怎么出来AI推理引擎在DC-Pi上的部署方式常见的有几种ONNX Runtime、TensorRT、OpenVINO或者厂商自研的推理框架。模型训练通常在PC或服务器上完成导出成ONNX格式再转换成目标平台支持的格式。推理的输入来源可以是工业相机通过USB或GigE接口也可以是PLC采集的时序数据振动、温度、电流。推理的输出可以写回PLC寄存器也可以直接显示在HMI上或者上传到数据库。这里有个实操细节图像预处理的时间往往比推理本身还长。工业相机采集的原始图像要做去噪、裁剪、缩放、归一化这些操作如果放在CPU上做可能比模型推理还慢。DC-Pi如果有GPU或NPU预处理也应该尽量放在加速器上做。3.4 三者之间的数据流设计我画一个典型的数据流工业相机采集图像→AI推理引擎做缺陷检测→结果写入共享内存→PLC运行时读取结果→根据置信度决定剔除或报警→HMI运行时读取结果→显示缺陷图片和统计信息。这个链路里PLC和AI之间的数据交换是关键。共享内存的读写要加锁吗如果AI写的时候PLC正在读会不会读到半截数据通常的做法是双缓冲或者环形缓冲区AI写一个缓冲区PLC读另一个通过原子操作切换。这些细节在文档里不一定写但实际开发时必须考虑。4. 实操过程从零搭建一个融合控制方案4.1 硬件选型与接线要点假设我们要用DC-Pi做一个视觉分拣工作站。硬件清单DC-Pi控制器一台、工业相机一台GigE接口、光电传感器若干、气缸和电磁阀一套、24V开关电源、触摸屏如果DC-Pi本身不带显示。接线时要注意相机的网口最好独立走一个网段不要和PLC的EtherCAT或Modbus TCP混在一起避免带宽争抢。光电传感器的信号进DC-Pi的DI端口电磁阀的控制线从DO端口出。如果DC-Pi的IO点数不够可以通过EtherCAT扩展模块。实操心得工业相机的触发信号最好由PLC的DO直接给出而不是软件触发。硬件触发的时间精度在微秒级软件触发受操作系统调度影响可能差几毫秒。在高速产线上几毫秒的偏差就可能导致图像模糊或者位置偏移。4.2 PLC程序框架设计PLC程序我习惯分几个任务主任务负责逻辑控制周期1毫秒通信任务负责和AI引擎交换数据周期5毫秒HMI交互任务负责处理按钮和显示刷新周期50毫秒。主任务的逻辑等待光电传感器信号→触发相机→等待AI结果→根据结果控制气缸。这里有个同步问题AI推理需要时间比如20毫秒主任务不能干等。我的做法是状态机触发相机后进入“等待AI结果”状态主任务继续扫描其他逻辑等AI结果写入共享内存后通过一个标志位通知主任务。4.3 AI模型训练与部署模型训练在PC上做。收集产线上的缺陷样本标注好类别和位置用YOLOv5或YOLOv8训练。训练完后导出ONNX再用DC-Pi支持的转换工具转成目标格式。部署时要注意输入尺寸和归一化参数。训练时的输入是640x640部署时也要保持一致。归一化的均值方差训练和推理必须一样否则精度会掉。推理代码通常是一个独立的进程通过共享内存和PLC运行时通信。代码框架大概是初始化推理引擎→循环读取相机图像→预处理→推理→后处理→写入共享内存。# 伪代码示例AI推理进程 import shared_memory import camera import inference_engine shm shared_memory.open(ai_result) engine inference_engine.load(defect_model.onnx) cam camera.open(gige0) while True: img cam.capture() input_tensor preprocess(img, size(640,640)) output engine.infer(input_tensor) boxes, scores, classes postprocess(output) shm.write({boxes: boxes, scores: scores, classes: classes, timestamp: time.now()})4.4 HMI界面开发HMI界面至少要有几个区域实时图像显示、检测结果统计、参数设置、报警记录。实时图像可以用MJPEG流或者直接显示推理后的标注图。统计信息从共享内存读取每秒刷新一次。参数设置里要能调整置信度阈值、IO触发延时、剔除延时这些关键参数。这些参数存在PLC的保持寄存器里断电不丢。4.5 联调与性能测试联调分三步先单独测试PLC逻辑用模拟IO信号验证状态机再单独测试AI推理用静态图片验证精度最后联调用实际产线跑。性能测试要记录几个指标PLC扫描周期的最坏值、AI推理的平均延迟和95分位延迟、从触发相机到气缸动作的总延迟。总延迟如果超过产线节拍方案就不可行。5. 常见问题与排查技巧实录5.1 PLC扫描周期抖动大怎么办现象PLC程序跑着跑着扫描周期从1毫秒跳到5毫秒。排查思路先看CPU占用率如果AI推理进程占了太多CPU把AI任务绑到另一个核心上。再看内存如果共享内存频繁读写导致缓存失效优化数据交换频率。最后看中断网卡中断如果太频繁会打断PLC任务可以调整中断亲和性。5.2 AI推理结果和PLC数据对不上现象HMI上显示的缺陷位置和实际位置差了几毫米。原因通常是时间戳不对齐。AI推理的结果要打上相机触发时刻的时间戳PLC读取时根据时间戳匹配对应的编码器位置。如果时间戳精度不够用硬件触发信号同时锁存编码器值。5.3 模型精度下降怎么排查先看输入图像有没有变化光照、焦距、产品颜色。再看预处理参数有没有被改动。如果都没问题可能是模型过拟合了需要补充新样本重新训练。我通常会在产线上保留一个“影子模式”AI推理结果不参与控制只记录用来监控精度变化。5.4 HMI界面卡顿HMI卡顿通常是资源争抢。把HMI进程的优先级调低但保证它不会被饿死。图像显示用硬件加速不要用CPU软渲染。刷新率不要设太高人眼看到25帧就够了设60帧纯属浪费。5.5 常见问题速查表问题现象可能原因排查方法解决措施PLC扫描周期抖动AI任务占CPUtop查看CPU占用绑核、限制AI任务CPU配额AI结果与PLC数据不一致时间戳未对齐检查时间戳来源硬件触发同步锁存模型精度下降输入分布变化对比训练和推理输入补充样本重新训练HMI卡顿资源争抢查看内存和CPU调整优先级、硬件加速相机丢帧网络带宽不足检查网口流量独立网段、降低分辨率推理延迟大预处理在CPUprofile各阶段耗时预处理放到加速器避坑技巧DC-Pi这类融合控制器散热是个容易被忽视的问题。PLC任务和AI任务同时跑CPU满载如果电柜通风不好夏天很容易过热降频。我一般会在电柜里加一个温度传感器接到PLC的AI通道超过45度就降载或者报警。6. 融合控制架构的适用场景与选型建议6.1 什么场景适合用融合控制器不是所有项目都适合上DC-Pi这种融合架构。我总结了几类适合的场景第一类是空间受限的设备比如小型包装机、桌面级自动化设备电柜里塞不下三台设备。第二类是数据闭环要求高的场景比如视觉伺服、力控打磨AI结果要实时参与控制。第三类是分布式产线每个工位一个控制器本地做AI推理只把统计结果上传减少网络依赖。不适合的场景也很明确超高速产线扫描周期要求100微秒以下的还是老老实实用专用PLCAI模型特别大的比如跑Transformer的边缘控制器算力不够对功能安全有认证要求的融合架构的认证成本很高。6.2 选型时的关键参数选DC-Pi这类产品时我关注几个硬指标CPU核心数和主频、NPU或GPU的算力TOPS、内存大小至少4GB、存储eMMC或SSD、IO接口类型和数量、支持的通信协议EtherCAT、Modbus TCP、OPC UA、Profinet。软件方面看PLC运行时的品牌和授权方式、AI推理框架的支持列表、HMI开发工具的上手难度。6.3 成本对比融合方案 vs 传统方案粗略算一笔账传统方案PLC3000元HMI2000元工控机5000元相机3000元电柜空间和接线2000元合计约15000元。融合方案DC-Pi8000元相机3000元电柜1000元合计约12000元。硬件成本省了20%左右但更大的价值在于调试时间和故障点的减少。传统方案三套软件三套通信调试至少一周融合方案一套工具链调试两三天。6.4 从传统架构迁移的注意事项如果现有产线要改造不要一次性全换。我的建议是分步走第一步保留原有PLC和HMI只加一个边缘AI控制器做视觉检测通过IO和原PLC握手。第二步把HMI功能迁移到边缘控制器上原HMI作为备用。第三步把PLC逻辑也迁移过去原PLC退役。每一步都要有回退方案产线不能停。7. 我在实际项目中的几点体会做工业控制和AI融合的项目最大的挑战不是技术本身而是思维方式的转变。做PLC的人习惯确定性输入决定输出时序严格做AI的人习惯概率性模型有置信度有误报漏报。这两拨人坐在一起开会经常鸡同鸭讲。我的经验是在系统设计阶段就要明确边界。哪些逻辑必须用PLC做保证确定性哪些判断可以交给AI允许一定误差。比如安全相关的急停、限位必须走PLC硬逻辑缺陷检测、质量分级可以走AI但要有置信度阈值和人工复核机制。另一个体会是数据比模型重要。很多项目失败不是因为模型不好而是因为训练数据不代表实际产线分布。我在项目前期会花大量时间做数据采集把各种工况、各种缺陷、各种光照条件都覆盖到。上线后还要持续收集数据做增量训练。最后不要迷信端到端。有些方案鼓吹从相机到控制全部用AIPLC只做执行器。这在实验室可以在工业现场风险太大。AI负责感知和判断PLC负责逻辑和安全这个分工在可预见的未来都不会变。DC-Pi这类融合控制器价值在于让两者之间的数据流动更顺畅而不是让AI取代PLC。最后分享一个小技巧在DC-Pi上跑AI推理时把模型的输入尺寸设成32的倍数比如640x640或者416x416。很多推理引擎对非32倍数的尺寸会做padding浪费算力。另外如果相机分辨率是500万像素不要直接缩放到640先裁剪ROI再缩放能保留更多细节。
