1. 项目缘起与整体架构拆解
车间里那台老PLC还在吭哧吭哧跑着产线逻辑，扫描枪往工位上一架，操作员“滴”一声扫完条码，数据就得往MES系统里送。这个场景听起来简单，但真正落地的时候，麻烦事一堆：扫描枪是串口还是网口？PLC怎么拿到数据？MES那边要的是HTTP接口还是消息队列？中间要不要加一台工控机做中转？这些问题我在过去几年里被问过不下几十次，每次都得从头解释一遍。今天索性把这个方案完整拆开讲透，从硬件接线到软件配置，从协议转换到接口暴露，一步一步来。
这个方案的核心思路是：用一台运行Edge网关的边缘计算设备作为中枢，向下通过串口或以太网口采集扫描枪数据，同时通过OPC UA协议与PLC进行数据交互，向上再提供一个标准的HTTP接口供MES系统调用。整个链路的关键在于Edge网关同时扮演了三个角色——数据采集器、协议转换器和接口服务器。为什么选择Edge网关而不是传统工控机？因为Edge网关通常预装了边缘计算运行时环境，支持容器化部署，功耗低、体积小、稳定性好，而且很多型号自带多路串口和网口，天生就是干这个活的。
先把这个架构的逻辑理清楚。扫描枪本质上是一个输入设备，它读到一个条码后，会通过某种物理接口把字符串吐出来。常见的接口有三种：RS232串口、USB接口（模拟键盘或虚拟串口）、以太网口（TCP客户端或服务端模式）。PLC这边呢，大多数中高端型号都支持OPC UA Server功能，但老一些的型号可能只支持Modbus TCP或者专有协议。MES系统则通常期望一个RESTful API或者WebService接口，用JSON或XML格式交换数据。所以Edge网关要做的，就是把扫描枪的“方言”翻译成PLC能听懂的“普通话”，再把PLC的数据包装成MES能接受的“公文格式”。
这个方案适合谁呢？如果你是工厂的自动化工程师，正在做产线数据采集项目；或者你是MES实施顾问，需要打通车间底层设备与上层系统之间的数据通道；又或者你是刚入行的工控小白，想了解边缘计算在智能制造中的实际应用——这篇文章都能给你一个可以直接抄作业的参考。我下面会按照实际项目的推进顺序，从硬件选型、网络规划、软件配置到联调测试，把每个环节的细节和坑都讲清楚。
2. 硬件选型与现场准备
2.1 Edge网关的选型要点
Edge网关的选型直接决定了后续开发的难易程度。我在实际项目中用过好几个品牌的网关，踩过的坑包括：串口数量不够、网口只有百兆、CPU性能太弱跑不动容器、系统封闭无法安装第三方库等等。所以选型的时候，我一般会盯住这几个参数：CPU至少四核ARM Cortex-A55或同等x86架构，内存不低于2GB，存储不低于16GB eMMC，串口至少两路RS232/RS485可配置，网口至少两路百兆（千兆更好），支持Docker或Podman容器运行时，工作温度范围覆盖-20℃到70℃。
为什么串口要两路？因为实际现场经常遇到扫描枪走一路串口，PLC走另一路串口的情况。虽然OPC UA通常走以太网，但有些老PLC的OPC UA功能是通过串口转以太网的模块实现的，这时候多一路串口就多一份灵活性。网口两路的原因也很简单：一路接车间内网与PLC通信，一路接办公网与MES通信，物理隔离更安全，也避免广播风暴互相影响。
注意：选网关的时候一定要确认它的串口电平标准。RS232和RS485的电气特性完全不同，接错了轻则通信失败，重则烧毁接口芯片。扫描枪通常是RS232电平，PLC的串口可能是RS485，中间需要加转换器或者选择支持两种电平的网关。
2.2 扫描枪的接口确认与配置
扫描枪这个设备看起来简单，但里面的门道不少。首先你得确认它的通信接口类型。我见过最多的三种情况：第一种是USB接口模拟键盘输入，这种最简单，插上电脑就能用，但问题是数据直接进了光标焦点，PLC拿不到；第二种是USB转虚拟串口，需要装驱动，然后在系统里识别为一个COM口；第三种是纯RS232串口，直接输出TTL或RS232电平信号。
对于这个方案，我强烈建议使用RS232串口输出的扫描枪，或者把USB扫描枪配置成虚拟串口模式。为什么呢？因为串口通信在工业现场最稳定，抗干扰能力强，传输距离远（RS232可达15米，RS485可达1200米），而且编程接口简单，打开串口、设置波特率、读数据就行。USB模拟键盘的方式虽然即插即用，但数据流向不可控，没法直接送给PLC。
扫描枪的配置通常通过扫描特定的配置条码来完成。你需要设置这几个参数：波特率（常见9600或115200）、数据位（8位）、停止位（1位）、校验位（无）、结束符（通常是CR或CR+LF）。结束符特别重要，因为Edge网关需要靠它来判断一条码是否读取完整。我一般会把结束符设为CR+LF，这样在代码里用readline()就能直接读到完整的一行数据。
2.3 PLC侧的OPC UA服务启用
PLC这边，我假设你用的是一台支持OPC UA Server功能的中高端型号。不同品牌的PLC开启OPC UA服务的方式不太一样，但大体流程是相似的：首先在编程软件里找到OPC UA相关的配置选项，启用服务器功能，然后设置端口号（默认4840）、安全策略（初期调试可以用None，生产环境建议用Basic256Sha256）、用户认证方式（用户名密码或证书）。接着你需要定义好PLC内部用于接收扫描枪数据的变量，比如一个字符串数组或者一个结构体，并把这些变量暴露给OPC UA地址空间。
这里有个关键点：PLC的字符串变量长度要设够。扫描枪读到的条码长度通常在8到32个字符之间，但有些特殊条码可能长达64个字符。我一般会把接收缓冲区设为128字节，留足余量。另外，PLC的扫描周期和OPC UA的刷新率要匹配。如果PLC扫描周期是10ms，OPC UA的发布间隔设成100ms，那数据延迟就在可接受范围内。如果设成10ms，可能会造成网络拥塞和CPU负载过高。
提示：调试阶段先把OPC UA的安全策略设为None，等通信调通后再逐步启用加密和认证。这样可以把网络问题和配置问题分开排查，省得两头抓瞎。
3. Edge网关软件环境搭建
3.1 操作系统与运行时准备
Edge网关到手后，第一件事是确认它的操作系统和软件环境。常见的Edge网关操作系统有基于Linux的定制发行版（如Ubuntu Core、Yocto）和Windows IoT。我个人更倾向于Linux系统，因为开源工具链丰富，容器支持好，远程管理方便。如果你拿到的网关是Windows系统，那也没问题，Python和Node.js在Windows上跑得也很好，只是资源占用会高一些。
系统确认之后，需要安装几个核心组件。首先是容器运行时，Docker或者Podman都行。我习惯用Docker，因为生态最成熟，遇到问题好查资料。然后是Python 3.8以上版本，用来写数据采集和协议转换的逻辑。为什么用Python？因为它的串口库pyserial和OPC UA库opcua-asyncio都非常成熟，代码量少，调试方便。如果你更熟悉Node.js，也可以用node-opcua和serialport库，效果类似。
安装Docker的命令很简单，以Ubuntu为例：
sudo apt update sudo apt install -y docker.io docker-compose sudo systemctl enable docker sudo systemctl start dockerPython环境我建议用系统自带的，或者用pyenv管理多版本。关键是安装两个核心库：
pip install pyserial asyncuapyserial负责串口通信，asyncua负责OPC UA客户端和服务端操作。这两个库的文档都很全，社区活跃，遇到问题基本都能搜到答案。
3.2 串口权限与设备识别
Linux系统下串口设备通常以/dev/ttyUSB0或/dev/ttyS0的形式出现。插上扫描枪后，用dmesg | grep tty命令可以查看系统识别到了哪个串口。如果是USB转串口线，通常会显示ttyUSB0；如果是板载串口，可能是ttyS0或ttyAMA0。
这里有个常见的坑：普通用户没有串口设备的读写权限。你会看到/dev/ttyUSB0的权限是crw-rw----，属主是root，属组是dialout。解决办法是把运行程序的用户加入dialout组：
sudo usermod -a -G dialout $USER然后重新登录使权限生效。如果你是在Docker容器里跑程序，那还需要在启动容器时加上--device=/dev/ttyUSB0参数，把串口设备映射进容器。或者更简单的方式是用--privileged参数，但这样安全性差一些，生产环境不推荐。
注意：有些Edge网关的串口在系统启动时会被控制台占用。你需要修改内核启动参数，把console=ttyS0改成console=tty1，释放串口给应用程序使用。这个坑我踩过好几次，明明代码没问题，就是读不到数据，最后发现是系统控制台把串口占了。
3.3 网络配置与防火墙规则
Edge网关通常有两个网口，我建议这样规划：eth0接车间设备网，IP地址设为192.168.1.x网段，与PLC同网段；eth1接办公网或MES网，IP地址由IT部门分配。如果网关只有一个网口，那就用VLAN或者直接走同一个网络，但要注意OPC UA端口4840和HTTP接口端口的防火墙规则。
Linux下用ufw或者iptables配置防火墙。我一般会开放这几个端口：4840（OPC UA）、8080（HTTP接口）、22（SSH远程管理）。其他端口一律关闭，减少攻击面。配置命令如下：
sudo ufw allow 4840/tcp sudo ufw allow 8080/tcp sudo ufw allow 22/tcp sudo ufw enable如果你的MES系统要求HTTPS，那还需要配置SSL证书，把8080改成8443。证书可以用自签名的，也可以从企业CA申请。自签名证书在MES侧需要导入信任链，稍微麻烦一点，但安全性有保障。
4. 扫描枪数据采集与PLC写入
4.1 串口数据读取的完整实现
串口数据读取看起来简单，但要做到稳定可靠，需要考虑不少细节。下面是我在实际项目中反复打磨过的一段Python代码，基于pyserial和asyncio实现异步读取：
import asyncio import serial import serial.tools.list_ports class ScannerReader: def __init__(self, port, baudrate=9600, timeout=1): self.port = port self.baudrate = baudrate self.timeout = timeout self.serial_conn = None self.buffer = b'' def open(self): self.serial_conn = serial.Serial( port=self.port, baudrate=self.baudrate, bytesize=serial.EIGHTBITS, parity=serial.PARITY_NONE, stopbits=serial.STOPBITS_ONE, timeout=self.timeout ) if not self.serial_conn.is_open: raise RuntimeError(f"无法打开串口 {self.port}") async def read_barcode(self): loop = asyncio.get_event_loop() while True: data = await loop.run_in_executor( None, self.serial_conn.read, 128 ) if data: self.buffer += data if b'\r\n' in self.buffer: line, self.buffer = self.buffer.split(b'\r\n', 1) return line.decode('utf-8', errors='ignore').strip() await asyncio.sleep(0.01) def close(self): if self.serial_conn and self.serial_conn.is_open: self.serial_conn.close()这段代码的关键点有几个：第一，用run_in_executor把阻塞的串口读取放到线程池里执行，避免阻塞事件循环；第二，用缓冲区累积数据，直到遇到结束符才返回完整条码，防止数据被截断；第三，解码时用errors='ignore'忽略非法字符，避免因为个别乱码导致程序崩溃。
4.2 OPC UA客户端连接与变量写入
拿到条码数据后，下一步是通过OPC UA协议写入PLC。这里用asyncua库实现客户端连接和变量写入：
from asyncua import Client class OpcUaWriter: def __init__(self, endpoint, node_id): self.endpoint = endpoint self.node_id = node_id self.client = None self.node = None async def connect(self): self.client = Client(url=self.endpoint) await self.client.connect() self.node = self.client.get_node(self.node_id) async def write_barcode(self, barcode): if self.node is None: raise RuntimeError("OPC UA节点未初始化") await self.node.write_value(barcode) async def disconnect(self): if self.client: await self.client.disconnect()endpoint的格式通常是opc.tcp://192.168.1.10:4840，node_id的格式取决于PLC的地址空间设计，比如ns=2;s=ScannerBarcode。这里有个细节：PLC的字符串变量类型要和Python写入的数据类型匹配。如果PLC定义的是String类型，Python写入str就行；如果PLC定义的是CharArray或ByteArray，那需要做相应的编码转换。
提示：写入PLC之前，最好先读取一下变量的当前值，确认通信正常。如果读取都失败，那写入肯定也不行。这个简单的检查步骤能帮你快速定位是网络问题还是权限问题。
4.3 数据校验与异常处理
工业现场的数据采集，最怕的就是脏数据和通信中断。我在代码里加了这几层保护：第一，条码格式校验，用正则表达式检查条码是否符合预期格式（比如长度、字符集），不符合的直接丢弃并记录日志；第二，写入确认，写入PLC后立即回读一次，确认数据确实写进去了；第三，断线重连，OPC UA连接断开后自动重试，重试间隔采用指数退避策略，避免频繁重连导致网络拥塞。
import re import logging logger = logging.getLogger(__name__) BARCODE_PATTERN = re.compile(r'^[A-Z0-9]{8,32}$') async def process_barcode(reader, writer): while True: try: barcode = await reader.read_barcode() if not BARCODE_PATTERN.match(barcode): logger.warning(f"条码格式异常，已丢弃: {barcode}") continue await writer.write_barcode(barcode) readback = await writer.node.read_value() if readback != barcode: logger.error(f"写入校验失败: 期望 {barcode}, 实际 {readback}") else: logger.info(f"条码写入成功: {barcode}") except Exception as e: logger.error(f"处理异常: {e}") await asyncio.sleep(1)这段代码看起来简单，但每一行都是实际踩坑之后加上的。比如那个正则校验，就是因为有一次扫描枪误扫了一个残缺条码，结果PLC里存了个半截数据，MES那边解析报错，查了半天才找到源头。
5. MES交互接口的设计与暴露
5.1 HTTP接口的框架选型
MES系统通常期望一个RESTful API来获取数据。在Edge网关上暴露HTTP接口，我推荐用FastAPI框架。为什么选FastAPI？第一，性能好，基于Starlette和Pydantic，异步处理能力强；第二，自动生成OpenAPI文档，MES开发人员可以直接在浏览器里看接口说明；第三，代码简洁，类型提示友好，不容易写错。
安装FastAPI和Uvicorn：
pip install fastapi uvicorn一个最简的接口服务长这样：
from fastapi import FastAPI, HTTPException from pydantic import BaseModel app = FastAPI(title="扫描枪数据接口", version="1.0") class BarcodeData(BaseModel): barcode: str timestamp: str station: str latest_barcode = None @app.get("/api/barcode/latest") async def get_latest_barcode(): if latest_barcode is None: raise HTTPException(status_code=404, detail="暂无数据") return latest_barcode @app.post("/api/barcode") async def push_barcode(data: BarcodeData): global latest_barcode latest_barcode = data.dict() return {"status": "ok"}这个接口提供了两个端点：GET /api/barcode/latest用于MES主动拉取最新条码，POST /api/barcode用于Edge网关主动推送条码给MES。两种模式各有适用场景：拉取模式适合MES定时轮询，推送模式适合实时性要求高的场景。
5.2 接口安全与认证机制
生产环境的接口不能裸奔，至少得加个API Key认证。FastAPI里实现很简单，用一个依赖注入就行：
from fastapi import Depends, Header API_KEY = "your-secret-key-here" async def verify_api_key(x_api_key: str = Header(...)): if x_api_key != API_KEY: raise HTTPException(status_code=403, detail="Invalid API Key") return x_api_key @app.get("/api/barcode/latest", dependencies=[Depends(verify_api_key)]) async def get_latest_barcode(): ...如果MES系统支持，还可以加上IP白名单、请求频率限制、HTTPS加密。IP白名单在Uvicorn层面可以通过--forwarded-allow-ips参数配合Nginx实现，频率限制可以用slowapi库。这些措施看起来繁琐，但一旦接口暴露在办公网上，没有防护就等于把车间数据大门敞开。
注意：API Key不要硬编码在代码里，用环境变量或者配置文件管理。我见过有项目把Key写在GitHub公开仓库里，结果被人扫到，往接口里灌了一堆垃圾数据，产线直接停了半天。
5.3 数据格式与MES对接细节
MES系统对数据格式通常有明确要求。常见的字段包括：条码内容、扫描时间、工位号、设备编号、批次号等。时间格式我建议用ISO 8601标准，比如2025-01-15T14:30:00+08:00，这样跨系统解析不会出歧义。工位号和设备编号可以从Edge网关的配置文件里读取，不需要每次扫描都传。
如果MES要求XML格式而不是JSON，那可以用Python的xml.etree.ElementTree或者lxml库做转换。如果MES要求SOAP WebService，那就得用zeep库。这些转换逻辑虽然不复杂，但字段映射关系一定要和MES开发人员确认清楚，否则联调的时候会发现字段名对不上、日期格式解析失败、编码不一致等各种问题。
我一般会在项目初期就整理一份接口对照表，把Edge网关侧的字段和MES侧的字段一一对应，包括字段名、数据类型、长度限制、是否必填、示例值。这份表格在联调阶段能省下大量沟通成本。
| Edge网关字段 | MES字段 | 类型 | 长度 | 必填 | 示例 |
|---|---|---|---|---|---|
| barcode | BARCODE | String | 32 | 是 | ABC12345678 |
| timestamp | SCAN_TIME | String | 25 | 是 | 2025-01-15T14:30:00+08:00 |
| station | STATION_CODE | String | 10 | 是 | ST01 |
| device_id | EQUIPMENT_ID | String | 20 | 否 | EDGE-GW-001 |
6. 联调测试与常见问题排查
6.1 分阶段联调策略
联调的时候最忌讳一把抓，所有环节同时上，出了问题根本不知道是哪一段的毛病。我习惯把联调分成四个阶段：第一阶段，单独测试扫描枪，用串口调试助手确认能读到完整条码；第二阶段，单独测试OPC UA连接，用UaExpert之类的客户端工具确认能读写PLC变量；第三阶段，把扫描枪和OPC UA串起来，确认条码能从扫描枪流到PLC；第四阶段，把MES接口加上，确认MES能拿到数据。
每个阶段都有明确的验收标准。第一阶段的标准是：扫描枪每扫一次，串口调试助手能显示一行完整条码，没有乱码，没有截断。第二阶段的标准是：UaExpert能连接到PLC，能读取变量当前值，能写入新值并回读确认。第三阶段的标准是：扫描枪扫一次，PLC变量在1秒内更新。第四阶段的标准是：MES调用接口，能在2秒内拿到最新条码。
这种分阶段策略看起来慢，但实际上快。因为每个阶段的问题范围小，排查起来有的放矢。我见过有团队跳过前三个阶段直接上全链路，结果扫描枪没配好、OPC UA证书不对、MES接口字段不匹配，三个问题搅在一起，查了两天都没定位到根因。
6.2 常见问题速查表
下面这张表是我这些年遇到过的典型问题汇总，按现象、可能原因、排查方法、解决方案四个维度整理：
| 现象 | 可能原因 | 排查方法 | 解决方案 |
|---|---|---|---|
| 串口读不到数据 | 串口被占用或权限不足 | lsof /dev/ttyUSB0查看占用进程 | 释放串口或加入dialout组 |
| 条码截断或乱码 | 波特率不匹配 | 用串口调试助手对比扫描枪配置 | 统一波特率为9600或115200 |
| OPC UA连接超时 | 防火墙拦截或IP错误 | telnet PLC_IP 4840测试端口 | 开放防火墙端口或修正IP |
| 写入PLC失败 | 节点ID错误或权限不足 | 用UaExpert手动写入测试 | 修正节点ID或启用匿名写入 |
| MES接口返回404 | 路由路径不匹配 | 查看FastAPI自动生成的/docs页面 | 修正路由路径或方法 |
| 接口响应慢 | 同步阻塞操作 | 检查代码中是否有time.sleep | 改用异步操作或线程池 |
| 数据重复 | 扫描枪触发两次 | 查看串口日志确认 | 加去重逻辑或调整扫描枪触发模式 |
| 网关重启后失效 | 服务未设开机自启 | systemctl status查看服务状态 | 配置systemd服务开机自启 |
6.3 稳定性优化与长期运行建议
联调通过只是第一步，真正考验的是长期运行的稳定性。我在实际项目中总结了这几条经验：第一，所有服务都用systemd管理，配置Restart=always，进程挂了自动拉起；第二，日志用logrotate做轮转，避免日志文件把磁盘写满；第三，关键数据落盘备份，比如最近1000条扫描记录存到SQLite数据库，万一MES那边数据丢了还能补；第四，定期检查串口线和网线的接头，工业现场振动大，接头松动是常见故障。
systemd服务配置示例：
[Unit] Description=Scanner to OPC UA Gateway After=network.target [Service] Type=simple User=edgeuser WorkingDirectory=/opt/scanner-gateway ExecStart=/usr/bin/python3 main.py Restart=always RestartSec=5 StandardOutput=journal StandardError=journal [Install] WantedBy=multi-user.target把这个文件保存为/etc/systemd/system/scanner-gateway.service，然后执行systemctl enable scanner-gateway和systemctl start scanner-gateway，服务就会开机自启，崩溃自动重启。
提示：日志一定要打时间戳和日志级别，方便事后追溯。我习惯用Python的logging模块，格式设为%(asctime)s - %(levelname)s - %(message)s，输出到文件的同时也输出到标准输出，这样systemd的journalctl也能看到。
7. 实操心得与扩展思路
7.1 那些文档里不会写的经验
第一个经验：扫描枪的触发模式要选对。扫描枪通常有手动触发、自动感应、连续扫描三种模式。产线工位上一般用手动触发，操作员按一下扫一次，避免误扫。但如果工位是流水线自动传送，那就得用自动感应模式，配合光电传感器触发。这个配置在扫描枪的说明书里，但很多人不看，结果扫描枪一直在那闪，数据重复发送。
第二个经验：OPC UA的订阅模式比轮询模式更高效。如果PLC支持OPC UA Subscription，那Edge网关可以订阅变量变化事件，而不是定时轮询。这样数据延迟更低，网络负载更小。asyncua库支持订阅功能，代码稍微复杂一点，但效果明显。
第三个经验：MES接口的幂等性设计很重要。网络抖动可能导致Edge网关重复推送同一条码，MES侧如果不做去重，就会产生重复记录。解决办法是在接口里加一个唯一的扫描ID，MES侧根据扫描ID做幂等判断。扫描ID可以用时间戳+条码内容的哈希值生成。
第四个经验：Edge网关的时钟要同步。OPC UA证书验证、日志时间戳、MES数据记录都依赖准确的系统时间。建议配置NTP客户端，定期与厂内NTP服务器同步。如果厂里没有NTP服务器，可以用公网的NTP池，但要注意网络安全策略是否允许。
7.2 方案的可扩展方向
这个基础方案跑通之后，可以往几个方向扩展。第一个方向是增加数据预处理能力，比如在Edge网关上做条码格式校验、重复条码过滤、条码与工单的匹配检查，只有通过校验的数据才写入PLC和MES。这样能减轻MES的负担，也能提前拦截异常数据。
第二个方向是增加本地缓存和断网续传。车间网络偶尔会断，如果Edge网关能把扫描数据先存本地，等网络恢复后再补传给MES，那数据完整性就有保障了。用SQLite做本地队列，配合重传机制，实现起来不难。
第三个方向是接入多个扫描枪。一个工位可能有多个扫描枪，或者一条产线有多个工位。Edge网关可以同时管理多路串口，把不同扫描枪的数据写入PLC的不同变量，MES接口也可以按工位号区分数据来源。这时候代码结构要做调整，用多线程或异步任务分别处理每路串口。
第四个方向是增加可视化监控。在Edge网关上跑一个轻量级的Web界面，实时显示扫描枪状态、PLC连接状态、MES接口调用统计。这样运维人员不用SSH登录就能看到系统运行情况。用FastAPI的静态文件服务加上一点前端代码就能实现，不需要额外装Nginx。
7.3 最后分享几个实用技巧
串口调试的时候，我习惯先用minicom或screen手动连接串口，确认扫描枪数据能正常输出。命令是screen /dev/ttyUSB0 9600，退出按Ctrl+A然后按K。这个步骤能快速排除硬件和接线问题。
OPC UA调试的时候，UaExpert是必备工具。它能看到PLC的完整地址空间，能手动读写变量，能查看连接状态和错误信息。很多OPC UA的问题用UaExpert一测就清楚了，比看代码日志快得多。
MES接口调试的时候，Postman或者curl都行。我习惯用curl，因为可以直接复制到脚本里做自动化测试。比如curl -X GET http://192.168.1.100:8080/api/barcode/latest -H "X-API-Key: your-key"，简单直接。
代码版本管理一定要做。哪怕是个人项目，也用Git管起来。Edge网关上的代码改动频繁，没有版本管理，改错了想回滚都回不去。我一般会在网关上建一个裸仓库，开发机push上去，网关上pull下来，简单高效。
这个方案从硬件选型到软件实现，从单点调试到全链路联调，基本上覆盖了PLC获取扫描枪数据并暴露MES接口的完整流程。实际项目中可能还会遇到各种意想不到的问题，但只要把每个环节的边界划清楚，分阶段验证，大部分问题都能快速定位和解决。我在多个产线项目里用这套架构，最长的已经稳定运行了两年多，每天处理上万次扫描，没出过大故障。希望这些经验对你有帮助，少走一些我当年走过的弯路。
