帖子分类
最新帖子
- 威纶通 EasyBuilder Pro 的穿透传输（Pass-Through）功能死穴： 威纶通 cMT 系列 HMI，网口接外网/局域网，串口（RS485）接三菱 FX3U PLC。 在 EBPr
- 松下 A6 伺服脉冲控制调到怀疑人生： A6 伺服驱动器（带 20 位高精编码器），接 PLC 发送差分脉冲（PULSE/DIR）控制定位。 电机低速（100 rpm）运转时，声音极度安静，定位也准
- 求助施耐德 Modicon M241 走 Ethernet/IP 控 ATV340 的抗干扰死坑： 软件使用 EcoStruxure Machine Expert。PLC 通过网线直接连接 3 台
- 台达 AS300 走 CANopen 控制自家 C2000 变频器求助： AS300 主机自带 CANopen 总线，通过台达官方软件（ISPSoft / CANopen Builder）配置了 DS
- 被欧姆龙 PLC 和第三方/自家 HMI 的 Modbus TCP 数据格式折腾炸了： OMRON NX1P2 PLC 作为 Modbus TCP Server，给触摸屏提供温度和压力数据（32 位
威纶通 EasyBuilder Pro 的穿透传输（Pass-Through）功能死穴： 威纶通 cMT 系列 HMI，网口接外网/局域网，串口（RS485）接三菱 FX3U PLC。 在 EBPr
联系人:15635859459462
电话/手机:联系客服
发布时间:2026-09-29 06:26
浏览:52次
威纶通 EasyBuilder Pro 的穿透传输（Pass-Through）功能死穴：
威纶通 cMT 系列 HMI，网口接外网/局域网，串口（RS485）接三菱 FX3U PLC。
在 EBPro 里开启‘穿透传输’，电脑安装虚拟串口工具（Virtual COM）。
打开三菱 GX Works2 软件，选择虚拟串口，通信测试显示‘已与 PLC 成功连接’！
崩溃故障： 从电脑端向 PLC 读取程序完全正常；但是只要点击‘写入 PLC’，下载进度条一路跑到 98%~99% 时，必定卡住不动，10 秒后 GX Works2 弹窗报错 通信超时 / 01802015，导致 PLC 内部程序损坏变 Blank！
能读程序、也能连通，为什么偏偏在下载写入的最后 1% 必定卡死超时？
威纶通 cMT 系列 HMI，网口接外网/局域网，串口（RS485）接三菱 FX3U PLC。
在 EBPro 里开启‘穿透传输’，电脑安装虚拟串口工具（Virtual COM）。
打开三菱 GX Works2 软件，选择虚拟串口，通信测试显示‘已与 PLC 成功连接’！
崩溃故障： 从电脑端向 PLC 读取程序完全正常；但是只要点击‘写入 PLC’，下载进度条一路跑到 98%~99% 时，必定卡住不动，10 秒后 GX Works2 弹窗报错 通信超时 / 01802015，导致 PLC 内部程序损坏变 Blank！
能读程序、也能连通，为什么偏偏在下载写入的最后 1% 必定卡死超时？
上一条: 松下 A6 伺服脉冲控制调到怀疑人生： A6 伺服驱动器（带 20 位高精编码器），接 PLC 发送差分脉冲（PULSE/DIR）控制定位。 电机低速（100 rpm）运转时，声音极度安静，定位也准 2026-09-28 10:30
下一条: 没有符合条件的记录
对不起，请登录后再发表评论！
威纶通官方对 Mitsubishi FX3U 的穿透通讯，专门写了一句：下载/上传 PLC 程序时，应把 LW-9903 设为 2。
因为默认 LW-9903=0 时，HMI 在 PC 穿透访问 PLC 的同时，自己仍然会继续轮询 PLC。威纶通明确说明 LW-9903=2 是 Stop Mode——穿透期间停止 HMI→PLC 通讯，并特别注明这样可提高 PLC program download/upload 的速度。dl.weintek.com
这和你现在“能读、写到99%才死”的现象非常吻合。
为什么读取正常，写程序最后1%却特别容易死？
默认状态实际上可能是：
GX Works2
↓
虚拟COM
↓
Ethernet
↓
cMT HMI
↓
──────── 串口 ────────
↓ ↑
GX Works2报文 HMI自己还在轮询
↓
FX3U
威纶通甚至明确说，FX3U 驱动支持 HMI与PLC在穿透模式下仍然同时通信。dl.weintek.com
读程序时主要是：
PC请求
↓
PLC返回数据
↓
PC继续请求下一块
偶尔被 HMI 插一帧，很多时候只是变慢，重试以后还能继续。
但“写入 PLC”不一样。它不是简单地一直发程序块，过程中还涉及写入、确认以及最后的结束处理。工程上可以把它理解成：
停止/准备PLC
↓
写参数
↓
写程序块1
↓
写程序块2
↓
……
↓
最后数据块
↓
结束写入/确认
↓
校验、状态确认
98%～99%附近恰好是链路最不能丢一次关键应答的时候之一。
这时候如果：
GX Works2：
发最后确认
↓
HMI：
刚好插入自己的D/M/X/Y读取
↓
串口响应被占用/延迟
↓
虚拟COM等待
↓
GX Works2 timeout
就会出现你这种特别诡异的：
前面几十KB都写得好好的，最后一下永远卡住。
所以这个案例我的第一刀非常明确：
LW-9903 = 2
然后再下载。
正确测试顺序我建议这样做
设备先处于安全状态，PLC STOP，避免程序中途写坏造成输出异常。
先把 HMI 的：
LW-9903 = 2
这意味着：
穿透期间 HMI 暂时停止自己与 FX3U 的通讯。
屏幕上的 PLC 数据暂停刷新是正常的。
然后：
启动 Weintek Pass-Through
↓
确认 Virtual COM 正常
↓
GX Works2 Communication Test
↓
Write to PLC
第一次只选：
Program
+
PLC Parameter
先不要把：
Device Memory
Comments
Symbolic Information
File Registers
全部一起写。
如果 Program + Parameter 能100%完成，再分别加其他内容。
写完以后：
停止 Pass-Through
↓
LW-9903 = 0
让 HMI 恢复正常 PLC 通讯。
威纶通最新版手册对 LW-9903 的定义就是：
0 = Normal Mode
穿透时允许 HMI ↔ PLC 通讯
2 = Stop Mode
穿透时禁止 HMI ↔ PLC 通讯
并特别说明，由于速度限制，PLC 程序 download/upload 时可设置为2。dl.weintek.com
这不是我的经验性猜测，是威纶通官方直接给 FX3U 的建议。
但还有第二个问题：你写的错误码 01802015 和“通信超时”对不上
这个我建议你特别注意。
我能查到的 GX Works2/FX3U 公开案例中：
ES:01802015
通常对应的是：
写入/读取的数据超过 Memory Cassette / PLC 参数中设置的存储容量。
而类似：
Cannot communicate with PLC
的公开案例更常见的是：
ES:01802007
``` :chatgpt-content-reference{index="3"}
所以这里存在两种可能。
### 如果你实际看到的是 `ES:01802007`
那和你描述的：
```text
Communication timeout
+
99%
是吻合的。
这时我把：
LW-9903 = 2
排第一嫌疑。
但如果屏幕上真的明确写的是 ES:01802015
那就不要把它当成穿透超时。
很可能同时存在第二个问题：
程序已经写入
↓
99%开始处理Comments / Symbolic Info / File Register等
↓
超过FX3U Memory Cassette容量
↓
ES:01802015
这反而特别能够解释：
为什么总是到98～99%才报错。
三菱官方 FX3U/FX3UC 手册明确说明，程序、comments、file registers、symbolic information 都涉及内存容量配置，而且总量不能超过 memory cassette 的可用容量；GX Works2 也提供 Confirm Memory Size 来核算程序和 symbolic information 使用量。三菱电机下载中心
所以：
99%失败
未必一定是“最后一个通信包没回来”。
也可能是：
最后才写到某一种额外数据，而那一类数据容量超限。
这也解释为什么 PLC 最后可能变成 Blank
这一点很危险。
做完整 Write to PLC 时，PLC 原有程序可能已经进入重写过程。
如果出现：
原程序已经清除/改写
↓
新程序正在写
↓
最后阶段失败
↓
整个写入流程没有正常完成
那么你最后留下来的 PLC 状态就可能不是原来的完整程序。
因此现在既然已经出现过：
“下载失败后 PLC 变 Blank”
我不建议继续一遍一遍用完整项目试。
先把链路问题和容量问题分开。
最漂亮的诊断其实只有3次测试
测试1：直连 PLC
暂时不用 HMI：
PC
↓
编程线
↓
FX3U
写同一个工程。
如果：
直连 → 100%正常
穿透 → 99%失败
基本锁定：
Pass-Through路径。
优先改 LW-9903=2、虚拟串口驱动、串口参数。
测试2：穿透 + LW-9903=2
PC
↓
cMT
↓
FX3U
LW-9903 = 2
仍然只写：
Program + Parameter
如果100%成功：
HMI并发轮询就是主因。
测试3：再把 Symbolic / Comments 等加回来
如果：
Program + Parameter → 100%
加 Comments/Symbolic → 99%失败
那就不要再怪穿透。
去 GX Works2：
Tool
→ Confirm Memory Size
检查：
Program Capacity
Comment Capacity
File Register Capacity
Symbolic Information Capacity
以及 CPU 上有没有：
FX3U-FLROM-16
FX3U-FLROM-64/64L
之类的 Memory Cassette。
三菱明确说明不同 FLROM 容量不同，而且 comments、file registers 等也会占用参数所划分的空间。三菱电机下载中心
串口参数也再核一次，但我不会把它排第一
威纶通当前 FX3U/FX3G/FX3GA Connection Guide 推荐的串口配置是：
38400 baud
7 data bits
Even parity
1 stop bit
同时支持相应的 RS232/RS485 接口配置。dl.weintek.com
当然具体要以你 PLC 当前通讯口实际参数为准。
因为：
能稳定读完整程序
已经说明：
波特率/校验位完全错的可能性很小。
但“读可以、长时间大量写不可靠”时，仍然要检查：
RS485/RS422接线
终端
接地
虚拟COM驱动
USB/网络延迟
尤其如果你接的是 FX3U 自带 8-pin Mini-DIN 编程口，要注意其物理接口是四线差分方式；不要把普通两线RS485的接线思路直接套过去。威纶通自己的 FX3U 接线页也是按 4-wire differential 方式给出的。dl.weintek.com
我现在给这个案子排嫌疑
第一名：LW-9903 仍然是默认 0。
也就是：
GX Works2正在写
+
HMI自己仍在轮询FX3U
而威纶通恰好对 FX3U 明确建议下载/上传程序时设：
LW-9903 = 2
这条证据最强。dl.weintek.com
第二名：你实际的错误码是 ES:01802015，根因不是超时，而是 Memory Cassette / Symbolic / Comment 容量。
特别是：
总在99%
非常值得查这个。
第三名：虚拟 COM / EBPro 版本较旧。
当前 Weintek 官方提供的 EasyBuilder Pro 已到 6.10.02.421（2026-08-27）；官方 Pass-Through 手册也要求虚拟串口驱动保持更新。Weintek
第四名：长报文条件下的串口线路质量。
但因为 read program 一直正常，所以先放后面。
所以这个案例一句话讲透：
威纶通的 Pass-Through 默认并不一定独占 HMI→PLC 串口。FX3U 驱动允许穿透时 HMI 自己继续访问 PLC，这在普通监控和读取时通常没问题，但长时间 PLC 下载尤其最后确认阶段更容易发生竞争和超时。威纶通官方因此明确要求 FX3U 下载/上传程序时把 LW-9903 设成 2，让 HMI 暂停自身 PLC 通讯，把串口完全让给 GX Works2。
但我还会特别强调一次：
如果你屏幕上的报码真的是 ES:01802015，先截图核准，因为它不像通信超时码，更像存储容量错误。
我会先做：
LW-9903 = 2
↓
只写 Program + Parameter
如果这次直接从 99% → 100%，这个“穿透写程序死穴”基本就破了。