请问c的具体含义是什么?
- 内容介绍
- 文章标签
- 相关推荐
本文共计1237个文字,预计阅读时间需要5分钟。
直接使用原生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# 代码优先。
本文共计1237个文字,预计阅读时间需要5分钟。
直接使用原生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# 代码优先。

