欧姆龙CJ1W-SCU协议宏：通配符+结束码实现不定长报文接收

做自动化项目最怕碰到什么？不是设备不转，而是上位机、仪表、扫码枪给你甩过来一段长度不固定的数据。固定长度接收吧，条码一会儿12位一会儿20位，数据总是错位；纯靠结束码接收吧，又怕报文中间混进和结束码一样的字节。这台设备用的是欧姆龙CJ系列PLC，配了一块CJ1W-SCU串行通信单元，正好支持协议宏。协议宏里有一个非常实用的组合——通配符加结束码，专门解决这种“长度不确定、但帧头帧尾有规律”的数据接收问题。这篇内容就把我实际配置这套方案的过程、踩过的坑、常见问题的排查思路完整记录下来，给同样被不定长报文折磨过的同行参考。

1. 先说清楚：非固定长度数据接收到底难在哪

1.1 现场设备的“任性”通信格式

工业现场的设备通信格式远比教科书里写的复杂。最常见的几类不定长数据源：

• 扫码枪：条码长度随编码规则变化，EAN-13是13位，Code128可能是8到32位不等，而且很多扫码枪默认会在数据后面追加回车换行符。
• 电子秤/地磅：重量数值位数不固定，比如0.5kg和1234.5kg的长度就差很多，通常以CR LF结尾。
• 温湿度传感器、流量计：不少仪表支持ASCII命令，返回的十六进制数据长度取决于测量精度和报警状态位。
• 某些老式检测设备：报文内自带长度字节，但不同设备对长度字段的定义方式五花八门，有的算头不算尾，有的算尾不算头。

如果用CPU自带的串口做无协议接收，你需要在程序里写一个状态机，一个字节一个字节地判断，还要处理接收超时、数据错位、缓冲溢出。工作量大不说，换一台带不同帧格式的设备，代码基本要重写。用SCU的协议宏就不一样，它把帧格式的定义从梯形图里剥离出来，用图形化工具配置，改设备格式时只改配置，梯形图基本不动。

1.2 三种常见接收方式对比

串行通信接收数据，本质上就三种判定“这帧数据结束”的方式：

我的经验是，单独用任意一种都有明显短板。固定长度接收最怕长度变化；纯结束码接收最怕数据里出现和结束码相同的字节；超时接收最怕设备发送节奏不稳定。真正可靠的方案是把通配符和结束码结合起来，让帧头帧尾的固定字符和结束码各司其职，这就是本文要讲的核心思路。

1.3 通配符+结束码为什么能“一招通吃”

协议宏里的通配符，作用是在帧格式里占一个“任意内容可长可短”的位置。比如扫码枪返回的数据格式是STX（0x02）+ 条码内容 + ETX（0x03）+ CR LF，其中条码内容长度不固定。普通结束码方案只盯着最后的CR LF，一旦条码内容里意外出现0D 0A，数据就被拦腰截断。通配符方案会先在帧头匹配STX，然后用通配符吞掉中间所有内容，直到匹配到ETX再配合结束码确认收尾。这样即使数据中间出现和结束码相同的字节，只要它不在帧头STX和帧尾ETX的约束区间内，就不会误判。

说得直白一点，通配符解决的是“中间这段到底有多长不知道”的问题，结束码解决的是“这一帧到底在哪结束”的问题。两者配合，一帧数据的头、中、尾都有了明确的判定规则，不定长接收就变成了一件可配置的事，而不是靠梯形图里小心翼翼的状态机去猜。

这里要提一句，很多人一看到“通配符”就想到网络ACL里的反掩码。协议宏里的通配符和那个完全是两码事。网络ACL的反掩码是一串二进制掩码，配合IP地址精确匹配；协议宏里的通配符更像正则表达式里的“.*”，表示此处可匹配零个或多个任意字符。做网络出身的同行不要混淆。

2. CJ1W-SCU和协议宏：实现方案的两个基础

2.1 SCU模块到底干了什么

CJ1W-SCU是欧姆龙CJ系列PLC的串行通信单元，常见型号有SCU21-V1（RS-232C×1）、SCU31-V1（RS-422A/485×1）、SCU41-V1（RS-232C×2）等。它相当于给PLC外挂了一个独立的通信处理器，自带CPU和内存，负责串口数据的收发和协议解析。梯形图这边只要向SCU发一条执行命令，SCU就会按照预先下载好的协议宏自动发送、接收、解析报文，完成后把结果和状态告诉PLC。

这块板卡最大的价值在于它能跑“协议宏”。协议宏不是梯形图指令，而是用专用配置软件CX-Protocol定义的一组通信流程，类似脚本。流程里可以定义发送什么内容、接收什么内容、如何判断帧结束、收到数据放到PLC的哪个内存地址。SCU把整个流程固化在自身的Flash里，PLC上电后自动加载，运行时用一条指令触发。

2.2 协议宏里的通配符和结束码

在CX-Protocol的帧编辑界面里，通配符和结束码是这样起作用的：

• 发送帧：可以定义要发送的固定命令，支持通配符、变量、校验值。
• 接收帧：定义期望接收的帧格式。帧格式中的每个字节可以指定为固定值、通配符或变量。
• 结束码：在接收帧属性里指定，可以是1个字节也可以是2个字节，SCU收到结束码后认定这帧数据接收完成，结束码本身可配置是否要放入接收数据区。

通配符和结束码配合接收时，SCU内部接收状态机的工作逻辑是：先按帧格式里的固定字节逐段匹配，遇到通配符就持续接收直到遇到下一个固定字节或结束码，如果配了超时时间，超时也算一帧接收结束。关键参数有三个：通配符匹配规则、结束码类型、最大接收长度。最大接收长度是安全网，防止设备异常时SCU一直等结束码导致通信卡死。

2.3 匹配逻辑和边界情况

实际使用时，我认为最容易理解也最稳妥的做法，是把帧格式设计成“固定帧头 + 通配符 + 固定帧尾 + 结束码”。比如前面提到的扫码枪报文：02 30 31 32 33 03 0D 0A。接收帧格式就写：02 ** 03，结束码设为0D 0A。SCU收到0x02后开始匹配，遇到通配符后持续接收，直到收到0x03，说明条码内容结束，然后继续确认后面的0D 0A是结束码，整帧接收完成。

但有个边界情况必须注意：如果通配符后面跟着的固定字节是0x03，而条码内容里恰好也有0x03，通配符会在第一个0x03处提前停止，导致后续数据被当成多余内容，最终因为结束码对不上而报错。这种情况的处理办法是：尽量选择数据中不会出现的字节作为帧尾，或者改用“通配符 + 结束码”而没有中间固定字节的结构，靠结束码本身来终结匹配。具体怎么选，要对照设备厂家的协议文档仔细确认。

3. 实操配置：从零搭建一个不定长接收流程

3.1 组态前准备：单元号、DIP开关、通信参数

这块卡初始化时，最容易出问题的地方反而不是协议宏配置，而是最基础的硬件设置没搞对。SCU模块前面板上有两个旋转开关，用来设置单元号（0到F）。单元号一旦和别的特殊I/O单元重复，PLC上电直接报单元号重复错误，通信根本起不来。单元号还决定了SCU在CIO区和DM区的地址分配，比如单元号0时SCU占用哪个起始地址，CX-Programmer的IO表里会自动分配，以IO表显示为准。

安装好模块后，在CX-Programmer的IO表里双击该单元，把单元号、串口参数（端口1/2的通信协议要选择“协议宏”）、波特率、数据位、停止位、校验方式填进去。这里有个非常关键的点：通信协议必须从“Host Link”或“无协议”改成“协议宏”，哪怕你硬件上已经连好了设备，不把协议改过来，后面CX-Protocol下载的宏根本不会执行。很多第一次接触SCU的同行卡在这一步，半天找不出原因。

我习惯在配置时把每个串口的传输参数单独记录成一张表，内容包括：端口号、波特率、数据位、停止位、校验位、起始码、结束码、协议模式。不要指望自己记忆力有多好，设备多了以后这张表就是救命稻草。

3.2 CX-Protocol里定义协议宏

CJ系列的协议宏配置用的是CX-Protocol，这个软件集成在CX-One安装包里，需要单独授权。打开后新建项目，选择对应的PLC型号和SCU单元，然后开始创建协议宏（Protocol Macro）。一个协议宏由若干步骤（Step）组成，每个步骤可以包含发送帧、接收帧、或者同时包含。典型的配置顺序是：步骤0发送查询命令，步骤1接收响应；或者步骤0只接收（主动上传型设备）。

三种主流设备通信模式对应的宏设计：

• 主从查询型（PLC发命令，设备回数据）：步骤0发送命令帧，步骤1接收响应帧，响应帧按通配符+结束码配置。
• 主动上传型（设备不断自发数据）：只需要一个步骤，接收帧用通配符+结束码，SCU反复执行即可。
• 双向多帧型（一次命令返回多帧数据）：步骤数量增多，每帧都单独定义接收帧，帧间用通配符和结束码区分。

定义接收帧的界面里，左侧是帧编辑区，右侧是属性区。帧编辑区里可以输入十六进制和ASCII字符。我常用的做法：先用ASCII模式把帧头、通配符、帧尾填进去，再切到十六进制模式核对字节。通配符在ASCII编辑模式下通常用两个连续的星号“**”表示，匹配任意长度的任意内容；如果只需要匹配单个任意字节，用两个问号“??”。不同版本软件可能有细微差异，配置前先看一下帮助文档里“Wildcard”关键词的说明。

3.3 接收帧编辑：通配符+结束码的具体写法

我以扫码枪数据接收为例，完整演示一遍接收帧的配置过程。假设设备返回的数据格式是：STX（0x02）+ 条码ASCII字符 + ETX（0x03）+ CR（0x0D）+ LF（0x0A）。条码长度8到24位不等。

第一步，在接收帧编辑区填入：02 ** 03。02是帧头，**表示中间任意长的条码内容，03表示帧尾。第二步，在接收帧的属性区，把“结束码类型”选择为“2字节”，填入0D 0A。第三步，把“最大接收长度”设成32字节（条码最长24位加上帧头帧尾结束码，留一点余量）。第四步，在存储区设置里，指定接收数据保存的起始地址，比如DM100，并指定接收数据长度保存的地址，比如DM0。

这里有个参数需要解释一下：最大接收长度。这个值不是越大越好，如果设得太大，设备异常时SCU要等很久才会报超时错误，影响故障响应速度；设得太小，正常的长报文会被截断。按设备协议给出的最大帧长度再加5到10个字节的裕量，是比较合理的做法。扫码枪最长24字节内容，加帧头帧尾结束码一共28字节，设32字节足够。

如果收到的数据里既没有STX也没有ETX，只有一串纯数据加CR LF结尾，那接收帧就更简单，只填“**”，结束码设0D 0A。这种情况适合电子秤那种一次性输出一行ASCII数据的设备。缺点是数据里不能出现0D 0A，一旦出现，数据会被截断。纯通配符方案的应用范围有限，但对简单设备确实够用。

3.4 梯形图侧启动和状态处理

协议宏下载到SCU后，梯形图这边需要用协议宏执行指令来触发。CJ系列里用的指令是TRSM，全称是Transmit Serial Macro，专门用于启动SCU上的协议宏步骤。TRSM指令需要指定控制参数，一般包含单元号、端口号、待执行步骤号等。具体操作数以CX-Programmer的指令帮助为准，因为不同CPU型号的控制字定义有区别。

梯形图逻辑的骨架大致是这样：一个执行完成标志位作为触发条件，用微分指令触发TRSM；然后轮询SCU的状态区，判断协议宏是否执行完成，是成功完成还是错误完成；成功后再去把接收数据从DM区读走处理。SCU的状态区地址在IO表分配里可以看到，包含端口启动标志、端口完成标志、端口错误标志等固定定义。

我踩过的坑是：用普通线圈输出作为触发条件，没有加微分。结果TRSM在一个扫描周期内可能被连续触发多次，协议宏执行到一半又被重启，数据接收永远不完整。正确的做法是必须加一个上升沿微分，让TRSM在脉冲沿触发一次，执行完成后用复位线圈把触发位清掉，为下一次接收做准备。

状态轮询环节要特别注意：读完成标志的时候，要同时读错误标志。有些老工程师只判断完成标志，结果设备协议匹配失败时，SCU也会置位完成标志，但错误标志同时置位。如果程序不区分，会把错误数据当作正常数据用，这种问题在生产现场往往要隔很久才暴露，排查起来非常痛苦。

4. 数据提取与帧长判断

4.1 接收数据怎么进DM区

协议宏接收的数据，默认存放在SCU的接收缓冲区，然后根据你在CX-Protocol里配置的存储地址，复制到PLC的DM区或CIO区。配置界面里有“存储地址”和“接收数据长度存储地址”两个项目。前者保存整帧原始数据，后者保存这一帧实际接收了多少个字节。

这两个地址要规划好，不要和梯形图里其他数据混用。我一般习惯在DM区划出一个连续区域专门存串口接收数据，比如DM100到DM199，其中DM100到DM199存原始帧数据，DM0到DM9存每组数据的长度和状态字。这样规整的分配方式，后期程序维护和HMI监控都比较方便。

有一点要提醒：SCU接收的数据是原始字节，如果扫码枪返回的是ASCII编码的条码内容，DM区里存的是ASCII码，比如字符“1”对应0x31。使用前往往需要做ASCII转十六进制或者ASCII转字符串的转换。如果上位机或者HMI直接读PLC的DM区，可以在上位机侧处理；如果要在PLC内部做字符串比较或者拼接，就要用欧姆龙CJ系列自带的ASCII转换指令处理。别想当然认为DM区里直接就是数字。

4.2 换行结束码的数据裁剪

用结束码方式接收时，接收数据区里到底包不包含结束码本身，这是个需要实测确认的点。不同版本的SCU固件、不同的协议宏配置，结果不完全一样。我实测下来，常见的情况是：如果接收帧属性里的“扩展结束码”或“包含结束码”选项没有单独勾选，接收数据区只包含结束码之前的有效数据；但有些配置里结束码也会被存进来，导致DM区里数据后面多出0D 0A两个字节。

处理办法很简单：联调第一步，先把接收数据长度和原始内容通过上位机或调试软件打印出来，确认结束码是否在数据区内。如果在，梯形图里根据结束码长度把有效长度减去2或者3即可。这一步千万不要偷懒，我见过有人默认SCU“肯定不包含结束码”，结果数据尾部带着一截回车换行送去数据库，二维码识别率直线下降，查了很久才找到原因。

如果协议宏里用了“通配符 + 固定帧尾”的结构，比如02 ** 03加结束码0D 0A，那么接收数据区里通常包含帧头02和帧尾03。虽然包含帧头帧尾不影响核心数据提取，但后续处理时记得把首尾字节跳过。我一般会在梯形图里用索引寻址，直接从偏移1的位置开始读数据，读到长度减2的位置结束。

4.3 大报文和多次接收的技巧

非固定长度接收还有一种常见场景：设备一次返回的数据特别长，超过SCU单个接收缓冲区的容量。SCU的接收缓冲区大小因型号而异，CJ1W-SCU系列每端口通常在256字节到几千字节之间。如果设备一帧报文超过缓冲区大小，SCU可能报数据溢出错误。

实际上，协议宏的接收帧定义里，一个步骤只能接收一帧完整数据。遇到超长报文时，一种策略是把一帧数据拆分成多个接收步骤，比如先接收前256字节，再继续接收后面的字节，每个步骤用固定长度或结束码判定。另一种策略是提高串口通信速度，比如从9600提到38400或115200，缩短同一帧数据的传输时间，间接降低缓冲区压力。

还有一种更稳健的做法：配合超时接收。协议宏里可以把结束码设为“无”，然后在帧属性里启用超时结束参数，比如连续两个字符间隔超过20毫秒就认为本帧结束。这样数据长度完全不受缓冲区限制，SCU收到超时信号后把当前缓冲区的数据整体提交。这种方案对那种不定长且没有固定结束符的老式设备特别好用，代价是超时参数要反复调试，波特率越低，超时阈值要留得越宽。

5. 常见问题与排查技巧实录

5.1 问题速查表

根据我在不同项目里反复踩过的坑，整理成一张速查表，适合在现场拿着对：

5.2 踩坑心得

再补充几个速查表里写不下的心得。

第一，协议宏联调前，务必用串口调试工具抓一段设备的真实报文。很多设备厂家提供的协议文档和实际出厂配置有出入，有的少了校验位，有的多了版本号。最可靠的办法就是用USB转串口线先截获原始字节流，然后再照着真实报文去配协议宏。我遇到过设备文档写STX开头、实际报文却以空格开头的情况，如果直接按文档配置，通配符怎么调都匹配不上。

第二，通配符匹配不到时报错信息要会看。CX-Protocol的调试界面里，执行协议宏后可以看到每一步的接收结果和错误码。错误码的完整含义在SCU操作手册的附录里有一张表。至少要把“接收超时”“校验错误”“帧格式错误”“缓冲区溢出”这几个常见错误码背下来。现场设备越复杂，越不能只看个大概。

第三，SCU的协议宏是固化在模块里的，下载后不会因为PLC断电丢失。修改协议宏后必须重新下载，并让PLC重新上电或对SCU执行一次重启，新的宏才会生效。我有一次改了结束码忘记下载，现场反复测试都不对，最后发现SCU跑的还是旧的宏，这属于低级的低级错误，希望各位别走我的弯路。

第四，多端口轮询设备时，要留意SCU同一时间只能在一个端口上执行一个协议宏。两个端口同时有数据上来时，如果没有合理的轮询策略，可能造成某一端口的接收被另一端口阻塞。解决方案是在梯形图里做好端口互斥控制，同一时刻只启动一个端口的协议宏，另一个端口的数据先靠SCU接收缓冲区兜底，完成后再切换处理。

第五，如果设备支持，优先让设备启用硬件流控（RTS/CTS），特别是数据量大的场景。没有流控时，SCU接收缓冲区一旦满了，设备还在发，数据就会丢弃。软件上能做的是适当调大帧间间隔和超时参数，但治本之策还是硬件流控。

这套方案的后续扩展空间也很大。同一个SCU上可以同时维护多套协议宏，一键切换适配不同厂家设备，换设备时不需要改动PLC梯形图。配合欧姆龙的Sysmac Studio，还可以把协议宏的触发、状态、数据映射做到更统一的数据类型管理里。如果项目里用的是NJ/NX系列PLC，串口通信的配置思路类似，但操作界面换成了Sysmac Studio，配置逻辑完全可以复用。

我个人在实际操作中的体会是：协议宏入门不难，难得是把现场设备的报文吃透。通配符加结束码不是银弹，但对绝大多数带帧头帧尾或结束符的串口设备来说，已经是简单可靠且容易维护的方案。刚开始学习这项技术时，不妨先用串口调试助手模拟一台不定长数据的设备，连上SCU，从单次接收开始测试，逐步加帧头帧尾、加通配符、加结束码，把每一步的匹配逻辑都跑通，再上真机联调。这种循序渐进的测试方法，能让你在真正面对现场问题时少很多焦虑。