原生tcp+自定义3e帧最可控轻量易调试；mx component依赖com和特定运行时，跨平台不兼容且调试困难；modbus/tcp需plc手动启用并注意地址映射差异；串口通信对参数、接线和模式设置要求严苛。
直接用原生 TCP + 自定义 3E 帧是最可控、最轻量、最容易调试的方式；MX Component 是官方封装但依赖 COM 和特定运行时，部署麻烦；Modbus/TCP 通用但 FX5U 默认不启用，需额外配置；串口（RS-485）仅适合老设备或无网口场景，速率和稳定性都差一截。
为什么别急着用 MX Component
MX Component 看起来省事，但它本质是 COM 组件，必须注册、依赖 mxcom32.dll 和 mxcom64.dll，在 .NET 6+ 的跨平台项目里根本跑不起来。即使在 WinForms 里用，也会遇到“类未注册”“找不到入口点”这类错误——不是代码写错了，是环境没配对。它还强制要求 PLC 开启“MX Component 专用端口”，和标准 MC 协议端口（5007）不兼容，容易和现场其他上位机冲突。
更实际的问题是：一旦通信出错，你只能看日志里的模糊错误码（比如 0x0000000A），没法直接抓包比对帧内容。而自己组 3E 帧，Wireshark 一抓，00 00 00 01 00 00 00 00 00 00 00 00 00 00 对不对，一眼就清楚。
3E 帧二进制通信怎么发第一条读指令
以读取 FX5U 的 D0（字寄存器）为例，目标是构造一个合法的 TCP 请求帧。关键不是背格式，而是理解每个字段的物理意义：
-
00 00：固定头部，不能改 -
00 01：站号（PLC 的站号，不是 IP），默认是00 00，但很多现场设为00 01 -
00 00：网络号/节点号/单元号，FX5U 多数填00 00 -
00 00：CPU 监视定时器，填00 00表示不限时 -
04 00：功能码 + 子功能码，04表示“批量读”，00是子功能（3E 帧固定） -
00 00：软元件类型编码，D区是00 00 -
00 00：起始地址高位/低位，D0就是00 00 -
00 01：读取点数，这里是 1 个字
拼完就是 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 01，共 18 字节。用 TcpClient 发出去，收到响应后从第 10 字节开始取 2 字节，用 BitConverter.ToUInt16(response, 10) 解析即可。
串口通信最容易栽在参数和接线上
FX 系列串口通信不是插上线就能通。常见失败原因全是硬件和配置层面的：
- 波特率必须是
9600，数据位7，停止位2，校验Even——少一个都不行，不是“差不多就行” - RS-485 必须在 A/B 线末端加
120Ω终端电阻，否则信号反射导致偶发丢帧 - PLC 的 RS-485 模块（如
FX2N-485BD）要设置成“MC 协议模式”，不是“MODBUS/RTU” - 串口指令里地址要用 ASCII 编码，
D0不是直接发0x00 0x00，而是发字符串"4000"对应的 ASCII 字节0x34 0x30 0x30 0x30
如果你看到 02 30 30 34 30 30 30 03 30 36 这种十六进制指令流，说明你在走 ASCII 模式，那整个帧结构、校验方式（累加和低 2 位 ASCII 表示）都和二进制 3E 帧完全不同，不能混用。
Modbus/TCP 要先在 PLC 里手动开闸
FX5U 支持 Modbus/TCP，但默认是关闭的。你得进 GX Works3，在“参数设置 → 模块参数 → 以太网模块 → Modbus/TCP 设置”里把“启用”勾上，并指定端口（默认 502）。否则 C# 用 ModbusTcpMaster 去连，TCP 握手都成功，但一发读请求就超时——因为 PLC 根本没监听那个端口。
而且注意：Modbus 地址映射和 MC 协议不一致。40001 在 Modbus 里对应 D0，但在 MC 协议里 D0 是软元件类型 00 00 + 地址 00 00。别指望同一套地址逻辑能跨协议复用。
真正容易被忽略的是：PLC 的 IP 和 PC 必须在同一子网，且防火墙要放行对应端口。很多调试失败，不是代码问题，是 ping 不通或者 telnet 192.168.1.10 5007 直接拒绝连接——这种基础连通性验证，永远比写第一行 C# 代码优先。
