1. 工单拼接场景下字符串函数的选型逻辑工单拼接这件事听起来简单做起来全是细节。我在产线做数据采集和设备联调那几年最常遇到的场景就是PLC 要把产品型号、批次号、时间戳、工位编号拼成一条完整的工单字符串然后通过串口或者以太网发给上位机或者 MES 系统。三菱的 ST 语言里字符串处理函数不算多但每一个都有自己的脾气用错了轻则拼接结果多出空格重则直接触发字符串溢出报警产线停在那里等你排查。先说说为什么工单拼接这个需求会频繁出现在三菱 PLC 的项目里。很多老产线用的是 FX 系列或者 Q 系列本身不具备直接和数据库交互的能力只能把数据整理成一条格式化的字符串通过无协议通信或者 MC 协议往外发。上位机收到这条字符串之后再按分隔符拆开写入数据库。所以 PLC 端的字符串拼接质量直接决定了整条数据链路的可靠性。那为什么要在 CONCAT 和 REPLACE 之间做对比因为工单拼接有两种典型思路。第一种是“从零开始拼”把各个字段依次追加到一个空字符串后面这时候 CONCAT 是主力。第二种是“先搭模板再填坑”先定义一个带占位符的模板字符串然后用 REPLACE 把占位符替换成实际值。两种思路各有适用场景选错了不是不能跑而是维护起来会让你想砸键盘。我见过不少项目一开始用 CONCAT 拼得好好的后来工单格式要加一个可变长度的备注字段结果整个拼接逻辑推倒重来。也见过用 REPLACE 做模板替换的模板里占位符长度没对齐替换之后字符串长度变了后面的字段全部错位。这些坑我都踩过所以这篇文章不打算只讲函数怎么用而是把工单拼接这个场景拆开从选型、参数、边界条件到实测避坑一条线讲透。提示三菱 ST 里的字符串函数不同 CPU 型号的支持程度有差异。FX3U 和 Q 系列在字符串处理上的指令集不完全一样写代码之前先确认你的硬件手册里有没有对应的函数。下面讲的内容以常见 Q/L 系列和 FX3U 的 ST 编程环境为参考具体以你手头的编程手册为准。2. CONCAT 与 REPLACE 的底层行为差异2.1 CONCAT 的追加逻辑与长度陷阱CONCAT 这个函数顾名思义就是把两个字符串首尾相接。在三菱 ST 里它的典型调用形式是CONCAT(IN1, IN2, OUT)或者作为表达式返回结果。看起来人畜无害但它有一个非常关键的行为特征它不检查目标字符串的剩余空间。什么意思假设你定义了一个STRING[20]的变量用来存工单当前里面已经有 15 个字符了你再 CONCAT 一个 10 个字符的字段进去理论上需要 25 个字符的空间但变量只有 20。这时候不同 CPU 的表现不一样有的会截断有的会报错有的会默默把后面的内容覆盖掉。我在一个 FX3U 的项目里就遇到过拼接之后字符串末尾莫名其妙多了几个乱码字符查了半天才发现是长度溢出导致相邻变量被覆盖。所以用 CONCAT 做工单拼接第一件事不是写代码而是算账。把你所有要拼接的字段的最大可能长度列出来加上分隔符的长度再留至少 10% 的余量最后确定工单字符串变量的长度。这个计算过程不能拍脑袋我一般会做一个简单的表格来核对。字段名称最大长度说明产品型号12字母数字组合固定 12 位批次号8日期加流水号时间戳14YYYYMMDDHHMMSS工位编号4数字编号分隔符3三个竖线或逗号备注20可变长度最坏情况合计61加上余量取 70这张表看起来简单但很多项目出问题就出在“备注”这种可变长度字段上。你按平均长度 5 来算结果某天操作员输入了一个 18 个字符的备注直接溢出。所以我的习惯是只要工单里有可变长度字段字符串变量长度一律按最坏情况再加 20% 来定义。2.2 REPLACE 的定位替换与占位符设计REPLACE 的行为和 CONCAT 完全不同。它不是追加而是“在指定位置用新字符串替换掉指定长度的旧内容”。在三菱 ST 里REPLACE 通常需要你指定起始位置和替换长度比如REPLACE(源字符串, 替换字符串, 起始位置, 替换长度, 结果)。这个函数用好了非常优雅用不好就是灾难。用 REPLACE 做工单拼接的典型做法是先定义一个模板字符串比如MODEL:__________|BATCH:________|TIME:______________|STATION:____下划线就是占位符。然后依次用 REPLACE 把实际值填进去。这样做的好处是工单格式一目了然改格式的时候只需要改模板不需要动拼接逻辑。但这里有一个非常隐蔽的坑占位符的长度必须和实际值的长度严格一致。如果你模板里 MODEL 后面留了 10 个下划线但实际型号只有 8 个字符替换之后字符串总长度会缩短 2 位后面所有字段的位置全部前移。如果你后面的 REPLACE 用的是绝对位置那就全乱了。我见过一个项目就是因为型号从 10 位变成 8 位导致时间戳字段被截断上位机解析出来的时间全是错的。解决这个问题的办法有两个。第一个办法是替换时用空格补齐保证替换前后长度不变。第二个办法是不要用绝对位置而是每次替换后重新查找下一个占位符的位置。第一种办法实现简单但字符串里会多出空格上位机解析时需要 trim。第二种办法更灵活但代码复杂度上升。我个人的选择是如果工单格式固定用第一种如果字段长度经常变用第二种。2.3 两种函数在工单拼接中的性能对比性能这块很多人觉得字符串处理不耗时间但在高速产线上每个扫描周期都很宝贵。我实测过一组数据在 Q 系列 CPU 上拼接一条 60 字符左右的工单CONCAT 连续调用 5 次大概消耗 0.8 到 1.2 毫秒REPLACE 连续调用 5 次大概消耗 1.5 到 2.0 毫秒。单次差异不大但如果你的产线节拍是 10 毫秒一个工件这个差异就需要考虑了。对比项CONCATREPLACE单次调用耗时约 0.15-0.25ms约 0.3-0.4ms5 次拼接总耗时约 0.8-1.2ms约 1.5-2.0ms长度检查无需自行控制有位置参数但需自行控制长度格式可读性拼接逻辑分散模板集中可读性好字段长度变化适应性好追加即可差需重新对齐占位符维护难度字段增减需改多处改模板即可从表里能看出来CONCAT 在性能和灵活性上占优REPLACE 在可读性和格式集中管理上占优。所以我的建议是如果工单字段数量少、格式稳定用 CONCAT 直接拼简单高效。如果工单字段多、格式复杂、后期可能频繁调整用 REPLACE 做模板替换前期多花点时间设计模板后期维护省心。注意不管用哪个函数拼接完成之后一定要做一次长度校验。我通常会在拼接逻辑后面加一段判断如果结果字符串长度超过预设上限就触发一个报警位同时把工单标记为异常不让它发出去。这个校验花不了几个扫描周期但能避免大量脏数据流入上位机。3. 工单拼接的完整实现步骤3.1 数据准备与变量定义动手写代码之前先把数据准备好。工单拼接的输入通常来自几个地方产品型号可能来自配方数据或者扫码枪批次号可能来自上位机下发或者 PLC 内部生成时间戳来自 CPU 的时钟寄存器工位编号可能是拨码开关或者参数设置。这些数据在拼接之前需要先转换成字符串格式。三菱 ST 里数字转字符串常用的是INT_TO_STRING、DINT_TO_STRING或者REAL_TO_STRING。这里有一个细节转换之后的字符串长度是不固定的。比如整数 5 转成字符串是5长度 1整数 12345 转成字符串是12345长度 5。如果你后面用 REPLACE 做模板替换这个长度变化会直接导致错位。所以我在做模板替换之前会先用RIGHT或者LEN配合补齐函数把数字字符串补到固定长度。变量定义这块我习惯把工单相关的变量集中放在一个结构体或者一组连续的 D 寄存器里方便管理和监控。下面是一个典型的变量定义示例VAR sModel : STRING[12]; // 产品型号 sBatch : STRING[8]; // 批次号 sTime : STRING[14]; // 时间戳 sStation : STRING[4]; // 工位编号 sRemark : STRING[20]; // 备注 sWorkOrder : STRING[70]; // 最终工单字符串 sTemplate : STRING[70]; // 模板字符串 nLen : INT; // 长度校验用 bOverflow : BOOL; // 溢出报警 END_VAR变量长度我特意留了余量sWorkOrder 定义 70实际最坏情况 61多出来的 9 个字符就是缓冲。别小看这个缓冲现场调试的时候操作员临时在备注里多敲几个字是常有的事。3.2 用 CONCAT 实现追加式拼接追加式拼接的思路很直接先把 sWorkOrder 清空然后依次把各个字段 CONCAT 进去字段之间插入分隔符。代码大概长这样// 清空工单字符串 sWorkOrder : ; // 依次拼接 CONCAT(sWorkOrder, sModel, sWorkOrder); CONCAT(sWorkOrder, |, sWorkOrder); CONCAT(sWorkOrder, sBatch, sWorkOrder); CONCAT(sWorkOrder, |, sWorkOrder); CONCAT(sWorkOrder, sTime, sWorkOrder); CONCAT(sWorkOrder, |, sWorkOrder); CONCAT(sWorkOrder, sStation, sWorkOrder); CONCAT(sWorkOrder, |, sWorkOrder); CONCAT(sWorkOrder, sRemark, sWorkOrder); // 长度校验 nLen : LEN(sWorkOrder); IF nLen 65 THEN bOverflow : TRUE; ELSE bOverflow : FALSE; END_IF;这段代码看起来没问题但实际跑起来有几个地方要注意。第一CONCAT的第三个参数是输出三菱 ST 里有些版本要求输出变量不能和输入变量是同一个否则行为不确定。我上面写的CONCAT(sWorkOrder, sModel, sWorkOrder)在部分 CPU 上会出问题稳妥的做法是用一个临时变量中转。第二分隔符的拼接会额外增加调用次数。5 个字段加 4 个分隔符一共 9 次 CONCAT 调用。如果节拍紧张可以把分隔符直接附在字段后面比如把 sModel 和|先拼好再整体追加这样能减少调用次数。第三清空字符串用sWorkOrder : 在大多数三菱 ST 环境里是可行的但有些老版本需要用FILL或者逐个字符清零。这个细节查一下你的编程手册就能确认。3.3 用 REPLACE 实现模板填充式拼接模板填充的思路是先定义一个完整的工单格式模板然后用实际值替换占位符。模板设计的时候占位符我用下划线长度和字段最大长度一致。代码大概长这样// 定义模板 sTemplate : MODEL:__________|BATCH:________|TIME:______________|STATION:____|REMARK:____________________; // 复制模板到工单变量 sWorkOrder : sTemplate; // 依次替换 REPLACE(sWorkOrder, sModel, 7, 10, sWorkOrder); REPLACE(sWorkOrder, sBatch, 24, 8, sWorkOrder); REPLACE(sWorkOrder, sTime, 40, 14, sWorkOrder); REPLACE(sWorkOrder, sStation, 62, 4, sWorkOrder); REPLACE(sWorkOrder, sRemark, 74, 20, sWorkOrder);这里的起始位置需要精确计算。MODEL:占 6 个字符所以型号从第 7 位开始。|BATCH:占 7 个字符型号占 10 个所以批次从 710724 位开始。以此类推。这个计算过程很容易出错我一般会在纸上画一个位置表确认无误再写进代码。REPLACE 的替换长度参数也很关键。如果你写的是 10但实际 sModel 只有 8 个字符替换之后字符串会缩短 2 位。所以我在替换之前会先把 sModel 补齐到 10 位。补齐可以用循环加空格也可以用三菱的字符串填充指令。补齐之后替换前后长度一致后面的位置就不会乱。提示REPLACE 的起始位置是从 1 开始计数的不是从 0。这一点和很多高级语言不一样写代码的时候容易搞混。我第一次用的时候就因为这个问题替换结果整体偏移了一位查了半个小时才反应过来。3.4 拼接结果的验证与异常处理拼接完成之后不能直接发出去一定要做验证。验证分两步长度验证和内容验证。长度验证就是检查最终字符串长度是否在预期范围内。内容验证是检查关键字段是否为空、分隔符数量是否正确。我通常会在拼接逻辑后面加一段验证代码// 长度验证 nLen : LEN(sWorkOrder); IF nLen 50 OR nLen 65 THEN bOverflow : TRUE; END_IF; // 分隔符数量验证 IF COUNT(sWorkOrder, |) 4 THEN bOverflow : TRUE; END_IF; // 关键字段非空验证 IF LEN(sModel) 0 OR LEN(sBatch) 0 THEN bOverflow : TRUE; END_IF;COUNT这个函数不是所有三菱 CPU 都支持如果不支持可以用循环逐个字符判断。验证不通过的时候除了置位报警我还会把异常工单写入一个单独的缓冲区方便后续排查。这个缓冲区不需要很大存最近 10 条就够了但关键时刻能帮你快速定位问题。4. 实测中遇到的典型问题与排查过程4.1 字符串末尾出现乱码字符的排查这个问题我在一个 FX3U 的项目里遇到过。现象是工单字符串发到上位机之后末尾偶尔会多出几个乱码字符不是每次都有大概十几次出现一次。一开始怀疑是通信干扰换了屏蔽线、加了磁环问题依旧。后来把 PLC 里的工单字符串直接监控出来看发现乱码在 PLC 内部就已经存在了。排查过程是这样的先确认乱码出现的规律发现都是在备注字段比较长的时候出现。然后检查备注字段的赋值逻辑发现备注是从触摸屏输入的触摸屏那边没有做长度限制操作员有时候会输入超过 20 个字符的内容。虽然 PLC 里 sRemark 定义的是 STRING[20]但触摸屏写入的时候如果输入了 25 个字符多出来的 5 个字符会覆盖到相邻的变量区域而 sWorkOrder 正好紧挨着 sRemark。找到原因之后解决办法有两个一是在触摸屏端加输入长度限制二是在 PLC 端做截断处理。我两个都做了触摸屏端限制 20 位PLC 端用LEFT(sRemark, 20)做一次截断双保险。这个问题给我的教训是只要涉及外部输入永远不要相信输入的长度是合法的一定要在 PLC 端做二次校验。4.2 REPLACE 替换后字段错位的定位另一个项目用的是模板替换方案工单格式是SN:__________|CODE:________|DATE:__________。上线跑了一个月没问题后来产品型号从 10 位升级到 12 位模板里的占位符没改结果替换之后 DATE 字段整体前移了 2 位上位机解析出来的日期全是错的。这个问题的排查相对直接因为现象很明确所有工单的日期都少了前两位。先检查模板发现 SN 的占位符还是 10 个下划线但实际型号已经是 12 位了。REPLACE 的时候替换长度写的是 10所以只替换了前 10 位后面 2 位被挤到了 CODE 字段里。CODE 字段的起始位置是按模板算的模板没变所以 CODE 的替换位置也没变但实际字符串已经变长了导致后续所有字段错位。修复方案是把模板里 SN 的占位符改成 12 个下划线同时更新所有后续字段的起始位置。这个改动涉及 5 个 REPLACE 调用的位置参数改完之后我写了一个小测试程序用固定值跑了一遍确认每个字段的位置都正确才下载到 PLC。这件事之后我在模板替换方案里加了一条规则模板里所有占位符的长度必须等于对应字段的最大可能长度不能按当前实际长度来设。4.3 拼接耗时影响产线节拍的优化有一个高速产线项目节拍是 8 毫秒一个工件PLC 需要在每个工件经过时拼接工单并发送。最初用 CONCAT 方案9 次调用加上验证逻辑总共耗时大概 1.5 毫秒。单独看没问题但产线跑起来之后发现偶尔会丢工件排查发现是拼接逻辑占用了太多扫描周期导致输入采样错过了信号。优化过程分三步。第一步减少 CONCAT 调用次数。把分隔符预先拼到字段后面比如 sModel 和|先拼成一个临时字符串这样 9 次调用减少到 5 次。第二步把拼接逻辑从主循环里拿出来放到一个单独的任务或者定时中断里每 20 毫秒执行一次而不是每个扫描周期都执行。第三步把长度校验和内容校验简化只保留长度校验内容校验放到上位机做。优化之后拼接逻辑的耗时降到 0.6 毫秒左右而且因为放到了定时任务里不再影响主循环的输入采样。这个项目给我的经验是字符串拼接本身不慢但如果在高速场景下每个扫描周期都做累积起来就很可观。合理使用定时任务和中断能有效降低对主循环的影响。4.4 不同 CPU 型号对字符串函数支持的差异三菱的 CPU 型号很多FX 系列、Q 系列、L 系列、iQ-R 系列不同系列对字符串函数的支持程度不一样。我在一个项目里从 Q 系列换到 FX3U发现原来用的REPLACE函数在 FX3U 的 ST 环境里不支持只能用CONCAT和MID组合来实现类似功能。具体差异我整理了一个表函数Q/L 系列FX3UiQ-R 系列CONCAT支持支持支持REPLACE支持部分版本不支持支持MID支持支持支持LEFT/RIGHT支持支持支持COUNT支持不支持支持LEN支持支持支持如果 FX3U 不支持 REPLACE可以用LEFT 新字符串 MID的方式手动拼接。比如要把第 7 位开始的 10 个字符替换成新值可以写成LEFT(sWorkOrder, 6) sNewValue MID(sWorkOrder, 17, LEN(sWorkOrder) - 16)。这样虽然麻烦一点但效果一样。所以选型的时候先确认你的 CPU 支持哪些函数再决定用哪种拼接方案。5. 工单拼接的进阶技巧与维护建议5.1 用结构体管理工单字段当工单字段比较多的时候用一堆独立的字符串变量管理起来很乱。我后来改用结构体把所有工单相关的字段打包在一起代码可读性提升很多。三菱 ST 支持结构体定义可以这样写TYPE T_WorkOrder : STRUCT sModel : STRING[12]; sBatch : STRING[8]; sTime : STRING[14]; sStation : STRING[4]; sRemark : STRING[20]; sResult : STRING[70]; END_STRUCT END_TYPE然后用WorkOrder.sModel这种方式访问。这样做的好处是拼接逻辑可以写成一个通用的函数块传入结构体返回拼接好的字符串。以后工单格式变了只需要改函数块不需要在每个调用点改代码。5.2 拼接逻辑的模块化封装把拼接逻辑封装成函数块是我强烈推荐的做法。函数块的好处是一次编写多处调用参数化配置不同产线可以用不同的格式便于测试可以单独模拟输入验证输出。函数块的接口大概这样设计输入是各个字段的字符串输出是拼接好的工单字符串和异常标志。内部实现可以用 CONCAT 也可以用 REPLACE根据配置参数切换。这样即使以后换 CPU 型号只要函数块内部适配好上层调用代码不用动。封装的时候有一个细节要注意函数块内部的临时字符串变量长度要按最坏情况定义不能按当前字段长度定义。因为函数块可能被多个地方调用每个地方的字段长度可能不一样临时变量不够长就会出问题。5.3 工单格式变更时的维护策略工单格式变更是常态今天加一个字段明天改一个分隔符后天调整字段顺序。如果没有好的维护策略每次变更都是一次冒险。我的做法是把工单格式定义成一个配置数据存在 D 寄存器或者文件寄存器里拼接逻辑从配置数据里读取格式信息动态生成工单。具体来说配置数据里存每个字段的名称、起始位置、长度、是否必填。拼接逻辑根据这些信息自动计算每个字段的替换位置。这样格式变更的时候只需要改配置数据不需要改代码。这个方案前期投入大一点但对于长期维护的项目来说非常值得。如果项目规模不大不值得做动态配置那至少要做到一点把模板字符串和位置计算逻辑集中放在一个地方不要散落在代码各处。我见过一个项目模板字符串在三个不同的函数块里各写了一遍改格式的时候漏改了一个结果那条产线的工单格式和其他产线不一致查了一天才发现。5.4 现场调试的实用技巧现场调试字符串拼接有几个技巧能帮你省时间。第一个技巧是在 PLC 里加一个调试模式调试模式下把中间拼接结果写到固定的 D 寄存器里用编程软件直接监控。这样不用连上位机就能看到拼接过程。第二个技巧是准备一组测试用例覆盖正常情况、边界情况和异常情况。正常情况就是所有字段都有值且长度正常边界情况是字段长度达到最大值或者为空异常情况是字段包含特殊字符或者超长。每次修改拼接逻辑先用测试用例跑一遍确认无误再上线。第三个技巧是如果上位机解析工单出问题先在 PLC 端把工单字符串原样打印出来和上位机收到的内容做对比。如果 PLC 端是对的上位机端是错的那就是通信或者解析的问题如果 PLC 端就是错的那就是拼接逻辑的问题。这个对比能帮你快速定位问题在哪一侧。注意调试模式下写中间结果到 D 寄存器要注意不要覆盖正常的生产数据。我一般会专门划出一段 D 寄存器作为调试区和生产区隔开避免误操作。6. 从工单拼接延伸出去的思考工单拼接这件事表面上是字符串函数的选用问题往深了看其实是数据流设计的问题。PLC 作为数据源头它输出的数据质量直接决定了整条链路的质量。我见过太多项目上位机端做了各种容错和清洗就是因为 PLC 端的数据不规范。如果 PLC 端能把工单拼接做扎实上位机端能省很多事。另一个延伸点是字符串处理在 PLC 里的定位。很多人觉得 PLC 就是做逻辑控制的字符串处理是上位机的事。但实际上随着产线智能化程度提高PLC 需要处理的数据越来越多字符串拼接、解析、校验这些操作会越来越常见。把字符串函数用熟把拼接逻辑设计好是 PLC 工程师的一项基本功。最后说一个我自己的习惯每次做完一个工单拼接的项目我都会把拼接逻辑和踩过的坑整理成一份文档下次遇到类似项目直接参考。这份文档里不只有代码还有当时为什么这么选、遇到问题怎么排查、最后怎么解决的。时间久了这份文档就成了我自己的经验库比任何教程都管用。
1. 工单拼接场景下字符串函数的选型逻辑工单拼接这件事听起来简单做起来全是细节。我在产线做数据采集和设备联调那几年最常遇到的场景就是PLC 要把产品型号、批次号、时间戳、工位编号拼成一条完整的工单字符串然后通过串口或者以太网发给上位机或者 MES 系统。三菱的 ST 语言里字符串处理函数不算多但每一个都有自己的脾气用错了轻则拼接结果多出空格重则直接触发字符串溢出报警产线停在那里等你排查。先说说为什么工单拼接这个需求会频繁出现在三菱 PLC 的项目里。很多老产线用的是 FX 系列或者 Q 系列本身不具备直接和数据库交互的能力只能把数据整理成一条格式化的字符串通过无协议通信或者 MC 协议往外发。上位机收到这条字符串之后再按分隔符拆开写入数据库。所以 PLC 端的字符串拼接质量直接决定了整条数据链路的可靠性。那为什么要在 CONCAT 和 REPLACE 之间做对比因为工单拼接有两种典型思路。第一种是“从零开始拼”把各个字段依次追加到一个空字符串后面这时候 CONCAT 是主力。第二种是“先搭模板再填坑”先定义一个带占位符的模板字符串然后用 REPLACE 把占位符替换成实际值。两种思路各有适用场景选错了不是不能跑而是维护起来会让你想砸键盘。我见过不少项目一开始用 CONCAT 拼得好好的后来工单格式要加一个可变长度的备注字段结果整个拼接逻辑推倒重来。也见过用 REPLACE 做模板替换的模板里占位符长度没对齐替换之后字符串长度变了后面的字段全部错位。这些坑我都踩过所以这篇文章不打算只讲函数怎么用而是把工单拼接这个场景拆开从选型、参数、边界条件到实测避坑一条线讲透。提示三菱 ST 里的字符串函数不同 CPU 型号的支持程度有差异。FX3U 和 Q 系列在字符串处理上的指令集不完全一样写代码之前先确认你的硬件手册里有没有对应的函数。下面讲的内容以常见 Q/L 系列和 FX3U 的 ST 编程环境为参考具体以你手头的编程手册为准。2. CONCAT 与 REPLACE 的底层行为差异2.1 CONCAT 的追加逻辑与长度陷阱CONCAT 这个函数顾名思义就是把两个字符串首尾相接。在三菱 ST 里它的典型调用形式是CONCAT(IN1, IN2, OUT)或者作为表达式返回结果。看起来人畜无害但它有一个非常关键的行为特征它不检查目标字符串的剩余空间。什么意思假设你定义了一个STRING[20]的变量用来存工单当前里面已经有 15 个字符了你再 CONCAT 一个 10 个字符的字段进去理论上需要 25 个字符的空间但变量只有 20。这时候不同 CPU 的表现不一样有的会截断有的会报错有的会默默把后面的内容覆盖掉。我在一个 FX3U 的项目里就遇到过拼接之后字符串末尾莫名其妙多了几个乱码字符查了半天才发现是长度溢出导致相邻变量被覆盖。所以用 CONCAT 做工单拼接第一件事不是写代码而是算账。把你所有要拼接的字段的最大可能长度列出来加上分隔符的长度再留至少 10% 的余量最后确定工单字符串变量的长度。这个计算过程不能拍脑袋我一般会做一个简单的表格来核对。字段名称最大长度说明产品型号12字母数字组合固定 12 位批次号8日期加流水号时间戳14YYYYMMDDHHMMSS工位编号4数字编号分隔符3三个竖线或逗号备注20可变长度最坏情况合计61加上余量取 70这张表看起来简单但很多项目出问题就出在“备注”这种可变长度字段上。你按平均长度 5 来算结果某天操作员输入了一个 18 个字符的备注直接溢出。所以我的习惯是只要工单里有可变长度字段字符串变量长度一律按最坏情况再加 20% 来定义。2.2 REPLACE 的定位替换与占位符设计REPLACE 的行为和 CONCAT 完全不同。它不是追加而是“在指定位置用新字符串替换掉指定长度的旧内容”。在三菱 ST 里REPLACE 通常需要你指定起始位置和替换长度比如REPLACE(源字符串, 替换字符串, 起始位置, 替换长度, 结果)。这个函数用好了非常优雅用不好就是灾难。用 REPLACE 做工单拼接的典型做法是先定义一个模板字符串比如MODEL:__________|BATCH:________|TIME:______________|STATION:____下划线就是占位符。然后依次用 REPLACE 把实际值填进去。这样做的好处是工单格式一目了然改格式的时候只需要改模板不需要动拼接逻辑。但这里有一个非常隐蔽的坑占位符的长度必须和实际值的长度严格一致。如果你模板里 MODEL 后面留了 10 个下划线但实际型号只有 8 个字符替换之后字符串总长度会缩短 2 位后面所有字段的位置全部前移。如果你后面的 REPLACE 用的是绝对位置那就全乱了。我见过一个项目就是因为型号从 10 位变成 8 位导致时间戳字段被截断上位机解析出来的时间全是错的。解决这个问题的办法有两个。第一个办法是替换时用空格补齐保证替换前后长度不变。第二个办法是不要用绝对位置而是每次替换后重新查找下一个占位符的位置。第一种办法实现简单但字符串里会多出空格上位机解析时需要 trim。第二种办法更灵活但代码复杂度上升。我个人的选择是如果工单格式固定用第一种如果字段长度经常变用第二种。2.3 两种函数在工单拼接中的性能对比性能这块很多人觉得字符串处理不耗时间但在高速产线上每个扫描周期都很宝贵。我实测过一组数据在 Q 系列 CPU 上拼接一条 60 字符左右的工单CONCAT 连续调用 5 次大概消耗 0.8 到 1.2 毫秒REPLACE 连续调用 5 次大概消耗 1.5 到 2.0 毫秒。单次差异不大但如果你的产线节拍是 10 毫秒一个工件这个差异就需要考虑了。对比项CONCATREPLACE单次调用耗时约 0.15-0.25ms约 0.3-0.4ms5 次拼接总耗时约 0.8-1.2ms约 1.5-2.0ms长度检查无需自行控制有位置参数但需自行控制长度格式可读性拼接逻辑分散模板集中可读性好字段长度变化适应性好追加即可差需重新对齐占位符维护难度字段增减需改多处改模板即可从表里能看出来CONCAT 在性能和灵活性上占优REPLACE 在可读性和格式集中管理上占优。所以我的建议是如果工单字段数量少、格式稳定用 CONCAT 直接拼简单高效。如果工单字段多、格式复杂、后期可能频繁调整用 REPLACE 做模板替换前期多花点时间设计模板后期维护省心。注意不管用哪个函数拼接完成之后一定要做一次长度校验。我通常会在拼接逻辑后面加一段判断如果结果字符串长度超过预设上限就触发一个报警位同时把工单标记为异常不让它发出去。这个校验花不了几个扫描周期但能避免大量脏数据流入上位机。3. 工单拼接的完整实现步骤3.1 数据准备与变量定义动手写代码之前先把数据准备好。工单拼接的输入通常来自几个地方产品型号可能来自配方数据或者扫码枪批次号可能来自上位机下发或者 PLC 内部生成时间戳来自 CPU 的时钟寄存器工位编号可能是拨码开关或者参数设置。这些数据在拼接之前需要先转换成字符串格式。三菱 ST 里数字转字符串常用的是INT_TO_STRING、DINT_TO_STRING或者REAL_TO_STRING。这里有一个细节转换之后的字符串长度是不固定的。比如整数 5 转成字符串是5长度 1整数 12345 转成字符串是12345长度 5。如果你后面用 REPLACE 做模板替换这个长度变化会直接导致错位。所以我在做模板替换之前会先用RIGHT或者LEN配合补齐函数把数字字符串补到固定长度。变量定义这块我习惯把工单相关的变量集中放在一个结构体或者一组连续的 D 寄存器里方便管理和监控。下面是一个典型的变量定义示例VAR sModel : STRING[12]; // 产品型号 sBatch : STRING[8]; // 批次号 sTime : STRING[14]; // 时间戳 sStation : STRING[4]; // 工位编号 sRemark : STRING[20]; // 备注 sWorkOrder : STRING[70]; // 最终工单字符串 sTemplate : STRING[70]; // 模板字符串 nLen : INT; // 长度校验用 bOverflow : BOOL; // 溢出报警 END_VAR变量长度我特意留了余量sWorkOrder 定义 70实际最坏情况 61多出来的 9 个字符就是缓冲。别小看这个缓冲现场调试的时候操作员临时在备注里多敲几个字是常有的事。3.2 用 CONCAT 实现追加式拼接追加式拼接的思路很直接先把 sWorkOrder 清空然后依次把各个字段 CONCAT 进去字段之间插入分隔符。代码大概长这样// 清空工单字符串 sWorkOrder : ; // 依次拼接 CONCAT(sWorkOrder, sModel, sWorkOrder); CONCAT(sWorkOrder, |, sWorkOrder); CONCAT(sWorkOrder, sBatch, sWorkOrder); CONCAT(sWorkOrder, |, sWorkOrder); CONCAT(sWorkOrder, sTime, sWorkOrder); CONCAT(sWorkOrder, |, sWorkOrder); CONCAT(sWorkOrder, sStation, sWorkOrder); CONCAT(sWorkOrder, |, sWorkOrder); CONCAT(sWorkOrder, sRemark, sWorkOrder); // 长度校验 nLen : LEN(sWorkOrder); IF nLen 65 THEN bOverflow : TRUE; ELSE bOverflow : FALSE; END_IF;这段代码看起来没问题但实际跑起来有几个地方要注意。第一CONCAT的第三个参数是输出三菱 ST 里有些版本要求输出变量不能和输入变量是同一个否则行为不确定。我上面写的CONCAT(sWorkOrder, sModel, sWorkOrder)在部分 CPU 上会出问题稳妥的做法是用一个临时变量中转。第二分隔符的拼接会额外增加调用次数。5 个字段加 4 个分隔符一共 9 次 CONCAT 调用。如果节拍紧张可以把分隔符直接附在字段后面比如把 sModel 和|先拼好再整体追加这样能减少调用次数。第三清空字符串用sWorkOrder : 在大多数三菱 ST 环境里是可行的但有些老版本需要用FILL或者逐个字符清零。这个细节查一下你的编程手册就能确认。3.3 用 REPLACE 实现模板填充式拼接模板填充的思路是先定义一个完整的工单格式模板然后用实际值替换占位符。模板设计的时候占位符我用下划线长度和字段最大长度一致。代码大概长这样// 定义模板 sTemplate : MODEL:__________|BATCH:________|TIME:______________|STATION:____|REMARK:____________________; // 复制模板到工单变量 sWorkOrder : sTemplate; // 依次替换 REPLACE(sWorkOrder, sModel, 7, 10, sWorkOrder); REPLACE(sWorkOrder, sBatch, 24, 8, sWorkOrder); REPLACE(sWorkOrder, sTime, 40, 14, sWorkOrder); REPLACE(sWorkOrder, sStation, 62, 4, sWorkOrder); REPLACE(sWorkOrder, sRemark, 74, 20, sWorkOrder);这里的起始位置需要精确计算。MODEL:占 6 个字符所以型号从第 7 位开始。|BATCH:占 7 个字符型号占 10 个所以批次从 710724 位开始。以此类推。这个计算过程很容易出错我一般会在纸上画一个位置表确认无误再写进代码。REPLACE 的替换长度参数也很关键。如果你写的是 10但实际 sModel 只有 8 个字符替换之后字符串会缩短 2 位。所以我在替换之前会先把 sModel 补齐到 10 位。补齐可以用循环加空格也可以用三菱的字符串填充指令。补齐之后替换前后长度一致后面的位置就不会乱。提示REPLACE 的起始位置是从 1 开始计数的不是从 0。这一点和很多高级语言不一样写代码的时候容易搞混。我第一次用的时候就因为这个问题替换结果整体偏移了一位查了半个小时才反应过来。3.4 拼接结果的验证与异常处理拼接完成之后不能直接发出去一定要做验证。验证分两步长度验证和内容验证。长度验证就是检查最终字符串长度是否在预期范围内。内容验证是检查关键字段是否为空、分隔符数量是否正确。我通常会在拼接逻辑后面加一段验证代码// 长度验证 nLen : LEN(sWorkOrder); IF nLen 50 OR nLen 65 THEN bOverflow : TRUE; END_IF; // 分隔符数量验证 IF COUNT(sWorkOrder, |) 4 THEN bOverflow : TRUE; END_IF; // 关键字段非空验证 IF LEN(sModel) 0 OR LEN(sBatch) 0 THEN bOverflow : TRUE; END_IF;COUNT这个函数不是所有三菱 CPU 都支持如果不支持可以用循环逐个字符判断。验证不通过的时候除了置位报警我还会把异常工单写入一个单独的缓冲区方便后续排查。这个缓冲区不需要很大存最近 10 条就够了但关键时刻能帮你快速定位问题。4. 实测中遇到的典型问题与排查过程4.1 字符串末尾出现乱码字符的排查这个问题我在一个 FX3U 的项目里遇到过。现象是工单字符串发到上位机之后末尾偶尔会多出几个乱码字符不是每次都有大概十几次出现一次。一开始怀疑是通信干扰换了屏蔽线、加了磁环问题依旧。后来把 PLC 里的工单字符串直接监控出来看发现乱码在 PLC 内部就已经存在了。排查过程是这样的先确认乱码出现的规律发现都是在备注字段比较长的时候出现。然后检查备注字段的赋值逻辑发现备注是从触摸屏输入的触摸屏那边没有做长度限制操作员有时候会输入超过 20 个字符的内容。虽然 PLC 里 sRemark 定义的是 STRING[20]但触摸屏写入的时候如果输入了 25 个字符多出来的 5 个字符会覆盖到相邻的变量区域而 sWorkOrder 正好紧挨着 sRemark。找到原因之后解决办法有两个一是在触摸屏端加输入长度限制二是在 PLC 端做截断处理。我两个都做了触摸屏端限制 20 位PLC 端用LEFT(sRemark, 20)做一次截断双保险。这个问题给我的教训是只要涉及外部输入永远不要相信输入的长度是合法的一定要在 PLC 端做二次校验。4.2 REPLACE 替换后字段错位的定位另一个项目用的是模板替换方案工单格式是SN:__________|CODE:________|DATE:__________。上线跑了一个月没问题后来产品型号从 10 位升级到 12 位模板里的占位符没改结果替换之后 DATE 字段整体前移了 2 位上位机解析出来的日期全是错的。这个问题的排查相对直接因为现象很明确所有工单的日期都少了前两位。先检查模板发现 SN 的占位符还是 10 个下划线但实际型号已经是 12 位了。REPLACE 的时候替换长度写的是 10所以只替换了前 10 位后面 2 位被挤到了 CODE 字段里。CODE 字段的起始位置是按模板算的模板没变所以 CODE 的替换位置也没变但实际字符串已经变长了导致后续所有字段错位。修复方案是把模板里 SN 的占位符改成 12 个下划线同时更新所有后续字段的起始位置。这个改动涉及 5 个 REPLACE 调用的位置参数改完之后我写了一个小测试程序用固定值跑了一遍确认每个字段的位置都正确才下载到 PLC。这件事之后我在模板替换方案里加了一条规则模板里所有占位符的长度必须等于对应字段的最大可能长度不能按当前实际长度来设。4.3 拼接耗时影响产线节拍的优化有一个高速产线项目节拍是 8 毫秒一个工件PLC 需要在每个工件经过时拼接工单并发送。最初用 CONCAT 方案9 次调用加上验证逻辑总共耗时大概 1.5 毫秒。单独看没问题但产线跑起来之后发现偶尔会丢工件排查发现是拼接逻辑占用了太多扫描周期导致输入采样错过了信号。优化过程分三步。第一步减少 CONCAT 调用次数。把分隔符预先拼到字段后面比如 sModel 和|先拼成一个临时字符串这样 9 次调用减少到 5 次。第二步把拼接逻辑从主循环里拿出来放到一个单独的任务或者定时中断里每 20 毫秒执行一次而不是每个扫描周期都执行。第三步把长度校验和内容校验简化只保留长度校验内容校验放到上位机做。优化之后拼接逻辑的耗时降到 0.6 毫秒左右而且因为放到了定时任务里不再影响主循环的输入采样。这个项目给我的经验是字符串拼接本身不慢但如果在高速场景下每个扫描周期都做累积起来就很可观。合理使用定时任务和中断能有效降低对主循环的影响。4.4 不同 CPU 型号对字符串函数支持的差异三菱的 CPU 型号很多FX 系列、Q 系列、L 系列、iQ-R 系列不同系列对字符串函数的支持程度不一样。我在一个项目里从 Q 系列换到 FX3U发现原来用的REPLACE函数在 FX3U 的 ST 环境里不支持只能用CONCAT和MID组合来实现类似功能。具体差异我整理了一个表函数Q/L 系列FX3UiQ-R 系列CONCAT支持支持支持REPLACE支持部分版本不支持支持MID支持支持支持LEFT/RIGHT支持支持支持COUNT支持不支持支持LEN支持支持支持如果 FX3U 不支持 REPLACE可以用LEFT 新字符串 MID的方式手动拼接。比如要把第 7 位开始的 10 个字符替换成新值可以写成LEFT(sWorkOrder, 6) sNewValue MID(sWorkOrder, 17, LEN(sWorkOrder) - 16)。这样虽然麻烦一点但效果一样。所以选型的时候先确认你的 CPU 支持哪些函数再决定用哪种拼接方案。5. 工单拼接的进阶技巧与维护建议5.1 用结构体管理工单字段当工单字段比较多的时候用一堆独立的字符串变量管理起来很乱。我后来改用结构体把所有工单相关的字段打包在一起代码可读性提升很多。三菱 ST 支持结构体定义可以这样写TYPE T_WorkOrder : STRUCT sModel : STRING[12]; sBatch : STRING[8]; sTime : STRING[14]; sStation : STRING[4]; sRemark : STRING[20]; sResult : STRING[70]; END_STRUCT END_TYPE然后用WorkOrder.sModel这种方式访问。这样做的好处是拼接逻辑可以写成一个通用的函数块传入结构体返回拼接好的字符串。以后工单格式变了只需要改函数块不需要在每个调用点改代码。5.2 拼接逻辑的模块化封装把拼接逻辑封装成函数块是我强烈推荐的做法。函数块的好处是一次编写多处调用参数化配置不同产线可以用不同的格式便于测试可以单独模拟输入验证输出。函数块的接口大概这样设计输入是各个字段的字符串输出是拼接好的工单字符串和异常标志。内部实现可以用 CONCAT 也可以用 REPLACE根据配置参数切换。这样即使以后换 CPU 型号只要函数块内部适配好上层调用代码不用动。封装的时候有一个细节要注意函数块内部的临时字符串变量长度要按最坏情况定义不能按当前字段长度定义。因为函数块可能被多个地方调用每个地方的字段长度可能不一样临时变量不够长就会出问题。5.3 工单格式变更时的维护策略工单格式变更是常态今天加一个字段明天改一个分隔符后天调整字段顺序。如果没有好的维护策略每次变更都是一次冒险。我的做法是把工单格式定义成一个配置数据存在 D 寄存器或者文件寄存器里拼接逻辑从配置数据里读取格式信息动态生成工单。具体来说配置数据里存每个字段的名称、起始位置、长度、是否必填。拼接逻辑根据这些信息自动计算每个字段的替换位置。这样格式变更的时候只需要改配置数据不需要改代码。这个方案前期投入大一点但对于长期维护的项目来说非常值得。如果项目规模不大不值得做动态配置那至少要做到一点把模板字符串和位置计算逻辑集中放在一个地方不要散落在代码各处。我见过一个项目模板字符串在三个不同的函数块里各写了一遍改格式的时候漏改了一个结果那条产线的工单格式和其他产线不一致查了一天才发现。5.4 现场调试的实用技巧现场调试字符串拼接有几个技巧能帮你省时间。第一个技巧是在 PLC 里加一个调试模式调试模式下把中间拼接结果写到固定的 D 寄存器里用编程软件直接监控。这样不用连上位机就能看到拼接过程。第二个技巧是准备一组测试用例覆盖正常情况、边界情况和异常情况。正常情况就是所有字段都有值且长度正常边界情况是字段长度达到最大值或者为空异常情况是字段包含特殊字符或者超长。每次修改拼接逻辑先用测试用例跑一遍确认无误再上线。第三个技巧是如果上位机解析工单出问题先在 PLC 端把工单字符串原样打印出来和上位机收到的内容做对比。如果 PLC 端是对的上位机端是错的那就是通信或者解析的问题如果 PLC 端就是错的那就是拼接逻辑的问题。这个对比能帮你快速定位问题在哪一侧。注意调试模式下写中间结果到 D 寄存器要注意不要覆盖正常的生产数据。我一般会专门划出一段 D 寄存器作为调试区和生产区隔开避免误操作。6. 从工单拼接延伸出去的思考工单拼接这件事表面上是字符串函数的选用问题往深了看其实是数据流设计的问题。PLC 作为数据源头它输出的数据质量直接决定了整条链路的质量。我见过太多项目上位机端做了各种容错和清洗就是因为 PLC 端的数据不规范。如果 PLC 端能把工单拼接做扎实上位机端能省很多事。另一个延伸点是字符串处理在 PLC 里的定位。很多人觉得 PLC 就是做逻辑控制的字符串处理是上位机的事。但实际上随着产线智能化程度提高PLC 需要处理的数据越来越多字符串拼接、解析、校验这些操作会越来越常见。把字符串函数用熟把拼接逻辑设计好是 PLC 工程师的一项基本功。最后说一个我自己的习惯每次做完一个工单拼接的项目我都会把拼接逻辑和踩过的坑整理成一份文档下次遇到类似项目直接参考。这份文档里不只有代码还有当时为什么这么选、遇到问题怎么排查、最后怎么解决的。时间久了这份文档就成了我自己的经验库比任何教程都管用。
