帖子分类
最新帖子
- V20变频器带一个高惯性的搅拌机。 因为减速总是报过压，特意配了一个原装的制动单元和制动电阻（电阻阻值和功率都是严格按照手册选型的）。 参数也改了：P1240（直流母线电压控制器）设为了 0（关闭），
- 求助各位师傅：现场用富士 Alpha5 Smart 伺服走位置模式。 参数里设置了外部转矩限制功能。 在手动点动（JOG）或者用软件试运行的时候，转矩限制很正常，用力顶住机构，到设定的转矩（比如 5
- 精调求助：S120 驱动器，CU320-2PN 控制。轴走 EPOS 模式。 设置了主动回零，寻找参考点开关（接近开关）。 轴以 100mm/s 的速度往回走，当机械滑块刚刚压到接近开关（信号从 0
- 求助！200Smart PLC 走 Modbus RTU 控一台安川 V1000 变频器。 写入频率的寄存器地址是 0002H。 平时给它写 2500（对应 25.00Hz），运行都很正常。 偶尔（大
- 请教老师傅：富士 FRENIC-MEGA 变频器带一台永磁同步电机（矢量控制模式）。 工艺需要用到多段速：X1端子对应 15Hz，X2端子对应 45Hz。 单独跑 15Hz 或者单独跑 45Hz 的
找个 MCGS 的隐藏大坑： 用昆仑通态的屏做配方管理，配方名称由操作员在屏幕上输入。 发现一个规律：只要配方名字里带有汉字的‘十’（比如：‘三十号配方’、‘十字接头工艺’），点击保存按钮时，后台脚本
联系人:15619493275731
电话/手机:联系客服
发布时间:2026-05-29 09:29
浏览:250次
找个 MCGS 的隐藏大坑：
用昆仑通态的屏做配方管理，配方名称由操作员在屏幕上输入。
发现一个规律：只要配方名字里带有汉字的‘十’（比如：‘三十号配方’、‘十字接头工艺’），点击保存按钮时，后台脚本就会报错，提示文件写入失败。
如果把‘十’改成阿拉伯数字‘10’或者大写的‘拾’，就能完美保存。
全局搜索过脚本，没有对‘十’这个字做任何过滤。
难道 MCGS 底层字符串转码（Unicode/GBK）的时候，把‘十’字当成了某种特殊的终止符或者控制代码？
用昆仑通态的屏做配方管理，配方名称由操作员在屏幕上输入。
发现一个规律：只要配方名字里带有汉字的‘十’（比如：‘三十号配方’、‘十字接头工艺’），点击保存按钮时，后台脚本就会报错，提示文件写入失败。
如果把‘十’改成阿拉伯数字‘10’或者大写的‘拾’，就能完美保存。
全局搜索过脚本，没有对‘十’这个字做任何过滤。
难道 MCGS 底层字符串转码（Unicode/GBK）的时候，把‘十’字当成了某种特殊的终止符或者控制代码？
上一条: NX1P2 控制器，通过 EtherCAT 带 3 个安川伺服轴。 软件里设置的正向软限位（Software Limit）是 1000.00mm。 最近遇到一个奇葩 Bug： 轴在走到 520.13m 2026-05-28 15:51
下一条: 请教各位大佬，现场一台富士电机的 FRENIC-MEGA（G1S系列）变频器控制 30KW 搅拌机。 旁边有一个托利多称重模块（4-20mA 进 PLC）。 变频器不启动，称重数字非常准。 变频器 2026-05-30 07:12
对不起，请登录后再发表评论！
真正的 C 字符串终止符是 0x00，汉字“十”本身不可能天然等于终止符。
更像是 MCGS 的配方名被拿去做了文件名、索引名或脚本参数，然后在某一层文件操作/配方操作里发生了编码兼容或二次解析错误。
MCGS 配方本来就支持“配方数据存储于 PLC”和“配方数据存储于 HMI”两种方式；如果你现在是屏内配方或脚本文件保存，配方名很可能会参与 HMI 内部文件读写流程。 另外，MCGS 脚本可以在事件或运行策略中执行，用来处理常规组态难实现的逻辑，所以按钮保存时的脚本、配方构件和文件函数之间很容易形成“名字传参”。
先给结论
这个问题不要继续按“是不是搜索漏了某个过滤脚本”去查。
更可能是：
操作员输入的配方名
↓
被脚本拼成文件名 / 配方名 / 查询条件 / 保存参数
↓
MCGS 运行环境或文件函数做字符串解析
↓
遇到“十”这个字时，内部编码/解析异常
↓
文件写入失败
尤其你已经验证：
三十号配方 失败
十字接头工艺 失败
三10号配方 成功
拾字接头工艺 成功
这说明问题不是“中文都不行”，也不是“文件名太长”，而是某个特定字符触发了兼容坑。
为什么不像 Unicode/GBK 把“十”当终止符？
“十”是普通汉字。
如果是编码问题，一般表现是：
乱码
保存后名字变成问号
某些中文全部失败
中英文混合长度异常
导入导出失败
但你这里是只要包含“十”就失败，而且换成“拾”就正常，这更像 MCGS 某个版本、某个配方函数或文件函数对这个字符处理有 bug。
不是你写的脚本里有过滤，而是可能在这些地方：
配方保存函数内部
文件写入函数内部
路径拼接函数内部
字符串比较函数内部
配方名称查询函数内部
导入导出 CSV / TXT 的内部解析
最危险的写法：直接用配方名当文件名
如果你现在类似这样做：
文件名 = "\Recipe\" + 配方名称 + ".csv"
保存文件(文件名)
或者：
配方保存(配方名称)
就很容易踩坑。
工业屏里最稳的做法是：
配方名称只给人看，不要直接当文件名、主键、索引名。
正确做法：内部编号，外部显示名称
建议改成这种结构：
内部文件名：RCP_0001.dat
显示名称：三十号配方
也就是说，屏内部保存时永远用安全字符：
RCP_0001
RCP_0002
RCP_0003
操作员看到的名称可以还是：
三十号配方
十字接头工艺
30号配方
客户A工艺
保存时不要让“显示名称”参与真实文件路径。
推荐配方表结构
可以做成这样：
配方编号：1
配方文件：RCP_0001.dat
配方名称：三十号配方
创建时间：2026-05-29
参数1：……
参数2：……
参数3：……
实际保存文件：
RCP_0001.dat
文件内部或配方记录里再保存显示名：
Name=三十号配方
这样即使名字里有：
十
空格
括号
中文标点
客户名
特殊符号
也不会影响文件写入。
临时解决办法
如果项目马上要交付，可以先加一个保存前检查：
如果配方名包含“十”
提示：配方名暂不支持使用“十”，请改用“10”或“拾”
但这只是止血。
更稳的是做字符替换：
保存文件名 = 配方编号
显示名称 = 操作员输入的原始名称
不要真的把“十”替换掉作为客户看到的名称。
怎么确认是不是 MCGS 内部坑？
你可以做 4 个小测试。
1. 单独保存一个最小文件名
测试这些名字：
十
A十
十A
三十
拾
10
士
干
千
什
如果只有“十”失败，基本就是特定字符触发。
2. 不用配方函数，只用文件函数保存
比如保存一个普通 TXT 文件：
十.txt
三十号配方.txt
如果普通文件也失败：
文件操作函数 / 文件系统路径处理有问题
如果普通文件成功，只有配方保存失败：
配方构件或配方名称索引有问题
3. 固定文件名，内容里写“十”
比如：
文件名：test.txt
内容：三十号配方
如果这样成功，说明：
“十”作为内容没问题
“十”作为文件名/配方名/索引名有问题
这一步最关键。
4. 换同工程到不同型号/不同版本屏测试
如果换版本后正常，基本就是 MCGS 运行版或固件兼容问题。
这时可以考虑升级运行环境或固件，但现场项目不建议只靠升级解决，还是应该把配方名和文件名解耦。
最可能的真实原因
亲，我会这样判断：
不是脚本搜索漏了“十”
不是“十”天然是控制字符
不是 Unicode/GBK 必然错误
而是：
MCGS 配方/文件操作内部，对含“十”的字符串做文件名、配方名或查询键处理时，触发了某个版本的解析兼容问题。
最终建议：
不要让操作员输入的中文配方名直接参与文件保存路径。
用这个方案最稳：
配方编号作为真实保存键：RCP_0001
中文名称作为显示字段：三十号配方
保存、读取、删除、导入、导出全部按编号操作
列表显示时再显示中文名称
一句话：
“十”不是终止符，真正的大坑是把“人看的配方名”当成了“系统保存用的文件名/主键”。