欧姆龙CJ1W-SCU协议宏实战：通配符+结束码搞定非固定长度串口数据

先讲一个现场故事。

车间新上了一条半自动包装线，让我去处理通讯部分。PLC是欧姆龙CJ2M，CPU自带两个串口一个给了触摸屏，一个给了变频器，剩下的扫码枪和电子秤就没地方接了。本想着扫码枪输出的是条码，电子秤输出的是重量字符串，一个短一个长，算不上复杂。结果实际接上去才发现，同一条产线会切换不同规格的产品，条码从12位到20位都有，电子秤那边偶尔还会多出几位状态字符。之前用的固定长度接收方式直接失效，程序里试了各种长度判断，改来改去还是丢数据。

后来同事给了个方向：用欧姆龙CJ1W-SCU模块，开协议宏，配合通配符和结束码，非固定长度数据随便收。这句话听起来简单，但真正把通配符、结束码和不定长接收这套组合搞清楚，还是花了不少功夫。这篇文章就把我整个踩坑过程、配置逻辑和最终能直接照抄的方案完整拆开讲，送给同样被不定长串口数据折磨的工控同行。

1. 项目背景与方案选型：为什么是SCU模块的协议宏

1.1 这个需求到底难在哪

先说清楚“非固定长度数据”在工业现场的真实样子。以我这次接的扫码枪为例，它走RS-232，输出的是ASCII条码字符串，末尾带CR LF两个字节。条码本身可能是12位、14位、16位，甚至20位，完全取决于产品编码规则。电子秤那边更典型，输出类似“ST,GW,+000.500kg”这样的字符串，中间数字的位数会因为重量大小变化，末尾同样是CR LF。

这类数据用“固定长度接收”去处理，本质上是死路。因为CPU根本不知道对方这次会发多少个字节，你设成20字节接收，它发12字节时程序就得等着超时，或者把下一帧的数据拼进来；你设成12字节，它发20字节时直接截断，后面8个字节丢失。所以问题的核心不是“能不能收到”，而是“怎么判断一条数据什么时候算结束”。

可能有朋友会说，欧姆龙CPU自带的串口不是也有“结束码接收”功能吗？确实有，但CPU内置串口的无协议模式只支持简单的字节数+结束码判断，结束码只能设一个或两个固定字节，不能处理帧中间某些字节可变的情况，更不能在同一个端口上灵活定义多条接收规则。而CJ1W-SCU模块的协议宏功能，相当于在SCU内部做了一个小型的可编程串行解析器，你可以自己定义帧头、通配符数据段、结束码、校验码，CPU只需要发一条PMCR指令把协议宏跑起来，剩下的串口解析全部由SCU硬件完成。

1.2 三种接收方式对比，为什么协议宏最省心

我梳理一下欧姆龙平台上处理串口不定长数据常见的三种路线，大家可以对照自己的项目条件选型。

从我实际体会来看，只要项目里出现了两种以上不同协议的串口设备，或者设备数据长度会变动，直接上SCU模块协议宏是最省心的选择。配置一次，后面全系列项目都能复用同一套协议模板。尤其是CJ1W-SCU41-V1这种带四路串口的模块，一路接扫码枪、一路接电子秤、一路接变频器，全都在同一块SCU上做协议宏，CPU压力几乎为零，调试时也方便隔离问题。

2. 通配符和结束码的原理：非固定长度接收的核心机制

2.1 协议宏消息格式中的通配符到底是什么

协议宏里定义一条接收消息，并不是简单写一个“接收多少字节”，而是像画表格一样，把一帧数据的结构拆成若干字段。每个字段可以指定类型，比如起始码、数据区、结束码、校验码。对非固定长度接收起关键作用的就是数据区里的“通配符”。

在CX-Protocol中，通配符有两种，一种星号“”，代表匹配任意多个字节，数量可以是0到指定最大长度；另一种问号“?”，代表匹配一个任意字节。所以当你在接收消息的数据区填一个“”时，等于是告诉SCU：这里的数据我不管它是什么、也不管它有多少个，全部收下来。这就像一个填空题，你只需要知道空格的边界在哪，里面内容随便填。

再配合结束码，帧的解析逻辑就是：从收到第一个字节开始，SCU不断把数据放进缓冲区，直到在数据流中匹配到预先定义好的结束码，比如0D 0A，就认为这一帧完整结束，把“*”匹配到的数据保存到PLC指定的存储区。这样条码发12位就收12位，发20位就收20位，收完自动结束，不需要CPU参与长度判断。

我插一句题外话。网上搜索“通配符”时，经常会把网络ACL里的反掩码、通配符掩码带出来。那个“反掩码通配符”是用来匹配IP地址位模式的，比如0.0.0.255表示只关心前24位，和协议宏里“*”匹配任意字符串完全是两码事。我做这个项目时就被搜索引擎带偏过，找了半天资料对不上号，后来才发现是两个不同领域的概念。大家在查资料时注意区分，别浪费时间。

2.2 结束码选型与最大长度计算

结束码的选择是整个方案里决定成败的细节。工业设备常见的结束码有CR（0D）、LF（0A）、CR LF（0D0A）、ETX（03）等。我的经验是，先拿串口助手抓一段设备的真实输出，用十六进制模式看末尾是什么，然后照着配。

这里有个非常重要的原则：结束码不能出现在数据正文中间。比如电子秤输出的是“ST,GW,+000.500kg\r\n”，那么数据正文里的逗号、小数点、加号都不会和0D0A冲突，用CR LF作为结束码就很稳。但如果某个设备的数据内容是二进制的，中间可能随机出现0D或者0A，再用CR LF当结束码就会导致提前截断，整帧数据错位。遇到这种情况，要么和设备厂商协商换一个正文中不会出现的控制字符，要么改用固定长度接收。

最大长度参数也要留够余量。假设扫码枪最长输出32个字节，加上结束码2个字节，我会把接收消息的最大长度设成40甚至50。设得大一点不会影响接收速度，SCU是收到结束码就结束，而不是等到最大长度才结束；但设得小于实际数据长度，SCU就会在缓冲区满时报错，导致接收失败。

参数计算很简单，无非是：最大接收长度 = 预期最长数据字节数 + 结束码字节数 + 5 ~ 10字节余量。这5到10字节的余量是给设备固件升级后可能多输出几位状态字符预留的，现场调试时就能感受到这个余量有多重要。

2.3 适配常见非固定长度协议的实际案例

为了让大家有更直观的感受，我整理了几种典型设备的帧结构参考。

这些帧的共同点是不管前面怎么变，末尾都有一个固定不变的结束码，而且正文中间不会出现和结束码相同的字节。只要这两个前提成立，通配符加结束码的接收方式就能稳定工作。

3. 硬件配置与协议宏实操步骤

3.1 硬件准备：SCU模块选型、单元号和通信参数

CJ1W-SCU系列模块常见的有几个型号：SCU21-V1是两路RS-232C，SCU31-V1是两路RS-422A/485，SCU41-V1是两路RS-232C加两路RS-422A/485共四路。做项目选型时，如果只是近距离接一台扫码枪，SCU21-V1就够；如果现场设备分布在几个位置需要走RS-485总线，那还得考虑SCU31或SCU41。我在这个项目里用的是SCU41-V1，一路232给扫码枪，一路232给电子秤，还有两路485预留给后续设备，比较灵活。

模块到手后，先看侧面的单元号旋转开关（UNIT No.），把它拨到0到F之间的一个唯一数值。这块SCU会在PLC的CPU总线上占用一段CIO继电器区，多个通信单元共存时单元号不能重复。拨好之后，把模块插到CPU机架的槽位上，上电后在CX-Programmer的IO表里执行一次单元注册，确认PLC能识别到这块SCU。

通信参数设置这一步经常有人忽略。双击IO表里的SCU模块，打开单元设置界面，把每个端口的操作模式选成“协议宏模式”（Protocol Macro Mode），然后根据设备说明书设置波特率、数据位、停止位、校验方式。比如扫码枪是115200，8位数据位，1位停止位，无校验；电子秤是9600，8位数据位，2位停止位，偶校验。这些参数必须和设备端完全一致，差一个校验位都收不到正确数据。

3.2 CX-Protocol中定义接收消息：通配符和结束码配置

协议宏的编辑软件是CX-Protocol，集成在CX-One里。打开后用起来有点像在画流程图，左边是协议列表，右边是步骤和消息的编辑区。

我的配置流程大概是这样的：

1. 新建一个Protocol，命名比如“SCAN_RECV”。
2. 在这个协议下新建一个Step，步骤编号从0开始。
3. 因为扫码枪是主动上传数据，不需要PLC先给它发命令，所以这个步骤里只建一条“接收消息”（Receive Message），不建发送消息。
4. 打开这条接收消息的消息格式编辑器，下面会出现一个帧格式表格，每一行代表一个字段。
5. 在这个表格里添加数据字段，类型选择“通配符”，值填入“*”，数据最大长度填50。
6. 再添加一个结束码字段，类型选“结束码”，值填十六进制0D0A，表示CR LF。
7. 在消息属性里设置接收数据保存到PLC侧的存储区起始地址，保存协议后下载到SCU模块。

需要注意一点：如果设备不是主动上传，而是PLC发一条命令才返回数据，协议宏步骤里需要先建一条发送消息，把要下发的命令帧编辑好，再建接收消息。发送消息也可以用到通配符，比如某些协议需要在命令中带可变地址，那个地址字段同样可以用“?”匹配或直接预留。整体逻辑仍然是按帧格式逐字段定义。

通配符“*”的数据段前面能不能放固定内容？可以。比如电子秤设备输出是以“ST,”开头，那我在通配符前面再加一个数据段，类型选“ASCII”，值填“ST,”，SCU就会先等待并确认收到这3个固定字符，才开始匹配通配符。这样做的好处是当总线噪声产生一些随机字符时，SCU不会误判为有效帧，因为固定前缀对不上。这也是提高接收抗干扰能力的一个实用手段。

3.3 PLC侧PMCR指令调用与控制数据分配

协议宏编辑好并且下载到SCU之后，PLC侧要做的事情就是执行PMCR指令来启动协议宏。PMCR是欧姆龙专门用于触发协议宏的指令，梯形图里调用一次，SCU就按照你定义好的协议去执行发送或接收操作。

PMCR指令在CX-Programmer里输入后会自动弹出辅助窗口，让你填写端口号、协议号、步骤号、控制数据首字、数据存储区首地址等信息。我这个项目的做法是按手册推荐的格式分配控制字：

然后梯形图上执行一句PMCR D100 0001 D0200，这里的第一个操作数是控制字首地址D100，第二个是端口号，第三个是数据区首地址。当PMCR运行后，SCU会按协议宏的流程开始等待串口数据，收到结束码后自动把通配符匹配到的内容写入D0200开始的连续区域，并把接收完成状态反馈给PLC。

这里我特别提醒：协议宏执行是异步的，PMCR指令发出后SCU在后台收数据，PLC程序不会停在那里等。如果你需要知道这次接收是否成功，可以通过SCU在CIO区对应的运行状态标志位来判断，或者给PMCR指令后面接一个“执行完成”的忙标志判断位。最常见的错误是PLC每个扫描周期都去触发PMCR，导致协议宏被重复启动，数据乱套。

3.4 触发逻辑与接收完成判断的梯形图设计

以扫描枪为例，正常的生产流程是扫码枪扫到条码后主动上传，PLC收到后判断数据是否有效，再执行后续动作。梯形图的设计思路是：用一个内部继电器作为扫描触发位，上升沿执行PMCR；执行过程中通过SCU的状态字判断协议宏是否空闲，空闲时才能再次触发；收到数据后把D0200中的数据读取出来处理。

一个简单的做法是使用一个执行完成标志位。PMCR指令有对应的执行完成标志，如果协议宏还在跑，这个标志不会置位，此时再触发PMCR会报错。所以我在程序里加了互锁：只有标志位复位了才允许新的PMCR触发。这样即使扫码枪连续扫描，程序也不会因为协议宏忙而丢命令。

接收完成后，SCU会把接收到的字节长度放到控制数据区指定的位置，同时把数据放到D0200起始区域。CPU这时要做的就是对D0200里的ASCII码进行解析，比如判断条码长度、比对前几位、换算重量值。注意协议宏接收的是原始字节，扫码枪输出的是ASCII字符串，所以D区里看的是十六进制ASCII码，比如数字“1”对应0x31。如果你要在触摸屏上直接显示条码，还得在程序里做一次ASCII转字符串，或者在触摸屏变量里按ASCII码对应的字符格式去解析。

4. 常见问题排查与避坑经验

4.1 接收失败类问题排查

协议宏这套配置，真正踩过坑的朋友都知道，大部分问题不是通配符不会写，而是配置细节对不上。我把项目调试中遇到的高频问题整理成一个速查表，大家可以直接对照排查。

实际排查时，最快的方法是先用串口助手模拟数据源。把扫码枪或电子秤接到串口助手上，手动发送一条同格式的数据，看看SCU在协议宏方式下能不能正常接收。如果能，说明SCU侧没问题，问题出在设备端或接线；如果不能，就用CX-Protocol自带的在线监视功能，看协议宏执行到哪一步、收了多少字节、在哪一步失败的。

4.2 数据内容与结束码冲突问题

这个坑比较隐蔽，但一旦碰上非常头疼。我处理过一台电子秤，它输出的数据中间偶尔会出现一个0D字节，而我把结束码设成了CR LF，结果SCU一碰到那个0D就把帧结束了，后半部分数据全丢掉，而且下一帧因为少了LF，也会解析错位。

排查方法是想办法抓几组真实数据，看正文里是否出现和结束码相同的字节序列。如果出现了，优先换结束码。比如设备可以设置输出格式，把帧尾改成“0D 0A 00”这种三个字节的格式，或者改为ETX作为结束码。如果设备端实在改不了，就得放弃结束码方案，改用固定长度接收，或者让设备端支持在帧头加一个固定前缀，SCU用“固定前缀+结束码”双条件收帧。

另外还要注意，协议宏里设置结束码时，如果数据正文本身包含中文、GBK编码或者二进制指令，正文里出现任何字节都是可能的，不能想当然认为0D0A不会出现在中间。所以我在每个新项目里都会强调：先抓帧，再定结束码。

4.3 协议宏稳定性设计：超时、重试与多设备互锁

工业现场最怕的不是一次收不到，而是设备偶尔掉线后再也回不来。协议宏在执行接收消息时，如果一直等不到结束码，会一直占着这个端口，后续所有数据都会被它吸收。所以我建议所有接收型协议宏都要设置合理的响应超时。

超时时间的计算方法很简单：根据设备正常发送周期，留出1.5到2倍的余量。比如电子秤每200毫秒上传一次，超时设到500毫秒绰绰有余。超时时间到了之后，SCU会返回一个超时状态，PLC程序检测到这个状态就可以重新触发PMCR，把端口恢复到监听状态。

如果多台设备共用同一个SCU的不同端口，或者同一端口走RS-485挂多台从站，协议宏步骤里通常会安排“发送命令→接收响应→跳转到下一个从站”的结构，这时每一条接收消息的超时时间都要单独算。从站没在线或响应特别慢时，超时时间太短会误判失败，太长又拖慢整个轮询周期。我的经验是把超时做成PLC侧的一个可调参数，现场调试时根据需要微调，而不是写死在协议宏里。

4.4 调试必备三件套：串口助手、协议监视、D区监控

最后分享一套我每次做SCU协议宏都会用到的调试方法，称之为调试三件套。

第一件是串口助手。设备端接不了PLC的时候，先用USB转串口接电脑，把设备的真实输出抓下来，十六进制模式逐帧分析。这一步能帮你确认波特率、数据位、结束码，还能顺便发现设备是否有多余的前缀字符。

第二件是CX-Protocol的在线协议监视功能。协议宏下载到SCU后，可以在CX-Protocol里点在线监视，看当前协议、步骤、消息的执行状态，以及接收缓冲区的实际字节。调试时如果PMCR触发了但SCU没反应，打开这个监视窗口，一眼就能看出卡在哪一步。

第三件是CX-Programmer的D区监控。协议宏接收完成后，PLC侧通过D区监视器看D0200起始的数据内容，确认接收结果是否正常。如果D区里的ASCII码和设备端输出的十六进制完全对上，说明整个链路已经通了。之后再去写数据解析和页面显示，心里就有底了。

这三件套配合使用，基本能定位99%的通信问题。而且这不需要什么特殊仪器，硬件上就是个USB转串口线，加上软件自带的监视功能就够了。

我在实际项目里还有一个习惯：在PLC程序里把每次PMCR的执行结果、接收数据长度、SCU状态字都记录下来，存到指定的D区。现场跑一段时间后翻出来看，能发现很多偶发问题，比如某个时段数据经常超时、某台设备偶尔会多发几个字节。这些数据是后续优化协议宏的重要依据。特别是那种一个现场挂十几台设备的项目，没有运行日志，出了问题只能靠猜。

其实回头看，这个“欧姆龙CJ1W-SCU模块使用通配符+结束码实现非固定长度数据的接收”方案，难点不在指令，也不在硬件，而在于你愿不愿意花时间去理解设备协议、抓真实数据、把帧结构定义清楚。只要帧结构对了，通配符和结束码的配置就是顺理成章的事。这几年我用这套组合接过扫码枪、电子秤、粘度计、变频器，大大小小几十台设备，已经形成一套固定的配置模板了。最后再分享一个小技巧：新项目调试时，拿到设备先别急着写PLC程序，用串口助手把真实数据录下来，打印成十六进制，一条一条核对帧头、数据段和帧尾，确认无误后再去配置CX-Protocol。前期多花半小时看协议，比现场抓一整天头发划算得多。