C#/VB与三菱FX5U PLC通过SLMP协议实现以太网通讯交互-北京尧图网络

简介这套源码采用C#与VB.NET编写面向三菱FX5U可编程控制器的上位机通讯交互专为需要将个人电脑与控制器对接的开发者打造尤其适用于自动化设备的调试与数据采集场景。方案基于TCP协议支持整数、双整数与浮点数的读写并提供ASCII和二进制两种报文格式能适配不同现场设备的通讯习惯降低集成难度方便不同经验水平的开发人员快速上手。压缩包内共有95个文件以VB与C#源文件、动态链接库组件、可执行程序为主另含项目解决方案、配置文件以及接口说明文档整个压缩包只有681KB结构清晰各类型文件用途明确。目前已有1544人学习下载内容获得用户初步验证。两个工程版本均可直接复制到项目中使用省去安装配置借助配套的接口说明开发者可以快速理解FX5U的通讯机制显著缩短报文格式调试与系统联调周期。1. 为什么 C#/VB 与 FX5U 的通讯交互先看 SLMP 而不是 Modbus三菱 FX5U 作为当前中小型项目里出现频率极高的 PLC上位机要跟它建立通讯交互选协议是第一道坎。很多人一上来就问“FX5U 支持 Modbus TCP 吗”支持FX5U 内置以太网口确实可以配置成 Modbus TCP 从站但实际做项目时你会发现 Modbus 能读到的数据范围受限而且保持寄存器和线圈的地址映射要按三菱的缓冲存储区规则重新算一遍绕了一圈还不如直接用三菱自家的 SLMP 协议Seamless Message Protocol即 MC 协议以太网版。SLMP 是 FX5U 原生支持的以太网通讯协议不需要额外配置 Modbus 映射表直接按软元件编号D、M、X、Y、R、ZR 等读写。C# 和 VB 作为 .NET 平台的两门语言写 TcpClient 连接 PLC 的端口号 1024FX5U 默认的 SLMP 端口组帧发命令、收响应、解析返回数据整个流程下来代码量不大但细节非常多。字节序、帧头、CPU 编号、双字节和校验、批量读写的点数限制这些才是真正决定能不能一次跑通的关键。本文适合已经在做或者准备做上位机开发的人尤其是 C#/VB 和 PLC 之间的通讯交互总是出现“能连上但数据不对”“读写偶尔超时”这类问题的场景。下面从协议选型开始给出可直接套用的 C# 和 VB 源码再展开数据转换和排错手段。2. 通讯交互的协议与参数FX5U 的 SLMP 帧和寻址规则2.1 FX5U 的以太网通讯交互方式有哪些FX5U 本体带一个以太网口支持 SLMP、Modbus TCP、Socket 通讯和 CC-Link IE Field Basic。做上位机时SLMP 是效率最高的选择因为它直接面向软元件不需要在 PLC 侧做专门的通讯程序只要在 GX Works3 里启用“简单 CPU 通讯”功能并开放端口即可。重要概念是 FX5U 实际上分 TCP 服务器模式和 TCP 客户端模式。上位机主动连接时PLC 作为服务器监听 1024 端口这是最常见的“C#/VB 主动连接”方式。反过来如果 PLC 做客户端主动上报就用不上 SLMP 的请求-响应模型需要走 Socket 通讯自己定报文这个不在本文范围内。SLMP 帧格式有两种三菱传统的 3E 帧二进制帧和 4E 帧ASCII 帧。上位机几乎都用 3E 帧因为长度短、解析快。需要特别注意的是FX5U 的 3E 帧和 Q 系列 PLC 的 3E 帧在寻址上是兼容的但请求数据长度的计算方式略有差异这点在写代码时要注意。2.2 SLMP 3E 帧格式逐字节拆解3E 帧请求报文格式如下字段长度说明帧头1 字节0x50请求数据长度2 字节低位在前从“子帧头”开始到报文末尾的字节数子帧头2 字节0x00 0xFF网络编号1 字节通常 0x00PC 编号1 字节通常 0xFF请求目标模块 IO 编号2 字节0x03 0xFFFX5U 固定值请求目标模块站号1 字节通常 0x00请求数据长度2 字节低位在前从“命令”开始到末尾的字节数命令2 字节0x01 0x04 读0x01 0x14 写子命令2 字节0x00 0x00按字访问软元件编号3 字节见 2.3 节软元件点数2 字节低位在前1~960字访问时数据写时不定每个字 2 字节低位在前读命令没有“数据”字段。写命令要在这个位置把要写入的数值带上。有一个高频踩坑点是“请求数据长度”这个字段它包含子帧头到末尾的所有字节但不包含帧头和它自己这 3 个字节。很多第一次写的人会把整个报文长度算进去导致 PLC 返回错误码。另外 FX5U 的请求目标模块 IO 编号固定填 0x03 0xFF这是 FX5U 和 Q 系列不一样的地方Q 系列用的是 0x00 0x00。需要注意这个报文的帧头以0x50开头这也是为什么网上很多文章直接用“50 00 FF FF FF 03 00”开头来识别 SLMP 报文。知道了这个规则用 Wireshark 抓包时就能快速确认报文的正确性。2.3 三菱 FX5U 软元件编号的 24 位编码规则SLMP 报文中的软元件编号是 3 字节24 位不是简单的十进制转十六进制。它把十进制编号按位拆分每个十进制数字占 4 位二进制再加上软元件代码填充到高字节。以 D100 为例D 类软元件代码是 0xA8。100 的每个十进制位分别是 1、0、0对应二进制 0001 0000 0000组合成 24 位低 16 位是 0x0100注意这个 0x0100 不是十六进制 100而是十进制的百位、十位、个位各自编码的结果高字节是软元件代码 0xA8。所以报文里 3 字节为 A8 00 01发送时按字节序 A8 00 01 排列。这个规则对刚接触 SLMP 的人非常不友好因为和三菱编程口协议的 BCD 编号还不太一样。FX5U 实际的 D 区范围是 D0 到 D7999 以及扩展的 D10000 以上编号都在 65535 以内但编码规则不变。M 软元件的代码是 0x90X 是 0x9CY 是 0x9DR 是 0xAFZR 是 0xB0。实操层面建议写一个通用的软元件编码函数把“D100”或“M50”字符串解析成 24 位寻址字节。网上很多现成的 C# SLMP 类库就是这么实现的比如 PduLayer 里的 PlcDevice 类但直接用库会掩盖细节出了问题根本不知道是寻址错还是帧格式错所以下面第 3 章的示例代码会从底层开始写。3. C# 实现 FX5U 通讯交互读 D 区和写 M 区的可运行源码3.1 先解决连接TcpClient 连接 FX5U 的 1024 端口连接部分用 System.Net.Sockets.TcpClient设置 ReceiveTimeout 和 SendTimeout。FX5U 作为 TCP 服务器上位机连上后要维持长连接因为 SLMP 没有类似 Modbus 的“断开重连”机制频繁断开重连会导致 PLC 侧的资源释放延迟可能触发“设备忙碌”错误。public class Fx5uClient : IDisposable { private TcpClient _client; private NetworkStream _stream; private readonly byte[] _buffer new byte[4096]; private int _sequenceNumber; public bool Connect(string ip, int port 1024) { _client new TcpClient(); _client.ReceiveTimeout 3000; _client.SendTimeout 3000; _client.Connect(ip, port); _stream _client.GetStream(); return _stream.CanRead _stream.CanWrite; } }这段代码里有几个参数值得说明。ReceiveTimeout 建议设 3000 毫秒低于 1000 毫秒时 FX5U 在忙的时候容易误报超时高于 5000 毫秒时上位机 UI 会明显卡顿。另外 Connect 方法本身没有超时控制如果 PLC 没开机TcpClient.Connect 会阻塞很久建议用BeginConnect配合WaitOne实现连接超时这块在工业现场比在办公室重要得多。连接成功不代表通讯交互就绪。FX5U 默认最多允许 4 个 TCP 连接如果之前有异常断开的连接没释放新连接会失败。这时需要在 PLC 侧重启或等待超时释放也可以在程序里主动先关闭旧的 socket。3.2 构造 SLMP 读请求帧并解析响应下边是读取 D 区字数据的核心方法。注意使用BinaryWriter处理字节序SLMP 里多字节整数的字节序统一是“低位在前”。public byte[] BuildReadFrame(string device, ushort count) { byte[] address EncodeDevice(device); int dataLength 12 address.Length 2; using var ms new MemoryStream(); using var bw new BinaryWriter(ms); bw.Write((byte)0x50); bw.Write((ushort)(dataLength 2)); bw.Write((byte)0x00); bw.Write((byte)0xFF); bw.Write((byte)0x00); bw.Write((byte)0xFF); bw.Write((byte)0x03); bw.Write((byte)0xFF); bw.Write((byte)0x00); bw.Write((ushort)(dataLength)); bw.Write((ushort)0x0401); bw.Write((ushort)0x0000); bw.Write(address); bw.Write((ushort)count); return ms.ToArray(); }代码中的bw.Write((ushort)0x0401)需要注意0x01 0x04 是读命令但 SLMP 报文里是先传低位所以ushort值写作 0x0401写到流里输出了 01 04。同理最后bw.Write((ushort)count)输出的是点数低位在前。帧构造好后调用ReadDWords等待响应public int[] ReadDWords(string device, ushort count) { byte[] frame BuildReadFrame(device, count); _stream.Write(frame, 0, frame.Length); _stream.Flush(); int header 0; while (header 9) { int n _stream.Read(_buffer, header, 9 - header); if (n 0) throw new TimeoutException(PLC 未响应); header n; } ushort bodyLen (ushort)(_buffer[3] | (_buffer[4] 8)); int total 9 bodyLen; while (header total) { int n _stream.Read(_buffer, header, total - header); if (n 0) throw new TimeoutException(读取响应中断); header n; } int resultCode _buffer[9] | (_buffer[10] 8); if (resultCode ! 0) throw new Exception($PLC 返回错误码 0x{resultCode:X4}); int[] values new int[count]; for (int i 0; i count; i) { values[i] BitConverter.ToUInt16(_buffer, 11 i * 2); } return values; }这里注意响应帧的结构前 9 个字节是帧头1加响应数据长度2加子帧头2加网络号加 PC 号加模块 IO3然后 2 字节结束代码0x0000 表示成功之后才是数据。代码里读取完第 9 个字节后再从_buffer[9]开始取结束码顺序是对的。这个方法的容错处理有个细节_stream.Read在 TCP 下不保证一次能读满请求的字节数所以必须用循环累计读取。很多简化版代码直接一个Read到位局域网下碰巧能跑但遇到 PLC 响应被拆成两个 TCP 包时就会卡死或读错位。这个问题在真实项目里几乎一定会出现所以循环读取是必须写的。3.3 写单个 D 字或批量写 M 区的封装写 D 区和写 M 区在底层的帧格式差异只体现在软元件编码上。M 区的位数据在 SLMP 按字访问时每一个 M 是一个位但字访问模式下 M0 到 M15 组成第一个字第 0 位对应 M0。批量写 M 区时要把布尔数组打包成 ushort 数组每个元素 16 个位。public void WriteDWord(string device, ushort value) { byte[] address EncodeDevice(device); int dataLength 12 address.Length 2 2; using var ms new MemoryStream(); using var bw new BinaryWriter(ms); bw.Write((byte)0x50); bw.Write((ushort)(dataLength 2)); bw.Write((byte)0x00); bw.Write((byte)0xFF); bw.Write((byte)0x00); bw.Write((byte)0xFF); bw.Write((byte)0x03); bw.Write((byte)0xFF); bw.Write((byte)0x00); bw.Write((ushort)dataLength); bw.Write((ushort)0x1401); // 写命令 0x01 0x14 bw.Write((ushort)0x0000); bw.Write(address); bw.Write((ushort)1); bw.Write(value); _stream.Write(ms.ToArray(), 0, (int)ms.Length); _stream.Flush(); ReadResponse(); } private ushort[] PackBits(bool[] bits) { int len (bits.Length 15) / 16; ushort[] words new ushort[len]; for (int i 0; i bits.Length; i) if (bits[i]) words[i / 16] | (ushort)(1 (i % 16)); return words; }PackBits方法处理位打包逻辑。M0 对应第 0 位M1 对应第 1 位以此类推。FX5U 的 M 区通过字方式访问时是 LSB 在前写入时1 (i % 16)就是按照这个规则排列。批量写 M 区时FX5U 对位软元件按字访问有点数上限单帧最大 960 个字也就是最多写 15360 个 M 位。超过这个值必须分帧。实际上建议控制在 512 点以内因为超过后 PLC 的响应时间会明显变长。3.4 循环数据采集和 UI 刷新卡顿的处理方式通讯交互代码写好后下一个绕不过去的问题是循环采集数据时 UI 卡顿。很多 C# 上位机在定时器里直接调用ReadDWords然后往 TextBox 上赋值PLC 响应 50 毫秒就卡 50 毫秒多个控件就卡成幻灯片。常见的做法是用一个独立的后台线程循环采集数据放到ConcurrentQueue或直接用System.Threading.TimerUI 层用BeginInvoke批量刷新。采集频率控制在 100 毫秒以上太快的频率意义不大因为 FX5U 的以太网响应通常在 10 到 30 毫秒但频繁的小报文会占满 PLC 的通讯处理时间。更好的做法是 200 毫秒批量读一次一次读 20 个 D 字和 64 个 M 位这样报文数量少吞吐反而更高。4. VB 实现 FX5U 通讯交互字节拼接、布尔转换和字符串乱码处理4.1 VB 版 SLMP 帧构造用 Byte 数组代替 BinaryWriterVB.NET 写法和 C# 在底层完全一样只是语法差异。VB 里没有BinaryWriter写起来那么顺手多数人直接用 Byte 数组拼接。要注意 VB 的数组下标从 0 开始和旧 VB6 不一样。Public Function BuildReadFrame(device As String, count As UShort) As Byte() Dim addr() As Byte EncodeDevice(device) Dim dataLength As UShort 12 addr.Length 2 Dim frame(27 addr.Length) As Byte Dim idx As Integer 0 frame(idx) H50 : idx 1 frame(idx) CByte(dataLength And HFF) : idx 1 frame(idx) CByte((dataLength 8) And HFF) : idx 1 frame(idx) H0 : idx 1 frame(idx) HFF : idx 1 frame(idx) H0 : idx 1 frame(idx) HFF : idx 1 frame(idx) H3 : idx 1 frame(idx) HFF : idx 1 frame(idx) H0 : idx 1 frame(idx) CByte(dataLength And HFF) : idx 1 frame(idx) CByte((dataLength 8) And HFF) : idx 1 frame(idx) H1 : idx 1 frame(idx) H4 : idx 1 frame(idx) H0 : idx 1 frame(idx) H0 : idx 1 Array.Copy(addr, 0, frame, idx, addr.Length) idx addr.Length frame(idx) CByte(count And HFF) : idx 1 frame(idx) CByte((count 8) And HFF) Return frame End FunctionVB 的手工字节拼接容易出现在frame数组长度上算错的问题建议在写完帧后加一个断言检查Debug.Assert(idx frame.Length)。凡是手工构造报文都建议加这个检查等号两端对不上立刻就暴露数组长度计算错误。另外一个 VB 专属陷阱是Byte类型溢出。CByte((dataLength 8) And HFF)这个写法不会溢出因为先做了And HFF。如果写CByte(dataLength 8)编译器会报错因为UShort转Byte是收缩转换VB 默认开启Option Strict时会拒绝编译。4.2 从响应帧提取位状态把字节还原成 M 区布尔值读 M 区时 PLC 返回的数据每个 M 只占 1 位16 个 M 位合一个字节字访问时按字返回但每个字含 16 个连续 M。上位机要还原成布尔数组核心代码是位测试。Public Function DecodeBits(data() As Byte, count As Integer) As Boolean() Dim result(count - 1) As Boolean For i As Integer 0 To count - 1 Dim byteIndex As Integer i \ 8 Dim bitIndex As Integer i Mod 8 result(i) ((data(byteIndex) bitIndex) And H1) 1 Next Return result End Function这里有个关键点容易搞错SLMP 返回的 M 区数据如果起始地址正好对齐到 16 的倍数比如 M0、M16、M32那么每个字从第一个字节的低位开始位序 LSB 在前上面的DecodeBits就是对的。但如果起始地址不是 16 的倍数比如从 M5 开始读返回的数据是从 M5 开始连续排列的第一个字节位 0 是 M5这时按上面的DecodeBits解析会整体错位。实际通讯交互时如果确实需要从任意 M 地址开始读建议永远是按 16 的倍数对齐后整块读取再在业务层做偏移。比如要读 M5 到 M10就读取 M0 到 M15然后取第 5 到第 10 位。这个策略可以避免所有非对齐解析的坑代价是多读一点数据在 FX5U 上完全可以接受。4.3 VB 读取 D 区 32 位整数和浮点数的字节顺序调整D 区按字读回来的是 16 位无符号整数D 和 D1 两个连续寄存器组成 32 位数据时三菱的默认规则是 D 存放低 16 位D1 存放高 16 位小端序。FX5U 没有像 Q 系列那样可以全局设置字节序的选项所以 C#/VB 上位机重组 32 位数据时必须按小端处理。Public Function ReadDWord32(device As String, isFloat As Boolean) As Double Dim raw() As UShort ReadDWords(device, 2) Dim bytes(3) As Byte bytes(0) CByte(raw(0) And HFF) bytes(1) CByte((raw(0) 8) And HFF) bytes(2) CByte(raw(1) And HFF) bytes(3) CByte((raw(1) 8) And HFF) If isFloat Then Return BitConverter.ToSingle(bytes, 0) Else Return BitConverter.ToInt32(bytes, 0) End If End Function这段代码先读出两个连续字再将这两个 16 位值按“第一个字在低地址”的规则拼成 4 字节小端然后用 BitConverter 转换。如果 PLC 程序里用的是结构化文本的DINT或REALGX Works3 的设置默认和这里相同可以直接用。需要特别小心的是如果 PLC 程序是别人写的他可能用了MOV指令把一个 32 位值直接搬到 D0没有拆高低字这时候上位机按 D0低字、D1高字解析出来的结果会差 65536 的倍数。排查方法很简单给 D0 写一个已知值 65539看上位机读出来是 65539 还是 4后者说明高地位反了。4.4 字符串读取Shift-JIS 解码和末尾 00 截断FX5U 的 D 区存字符串通常是 16 位一个字符一个 D 字放一个 Shift-JIS 编码的字符。如果 PLC 程序里用$MOV指令写入的字符串读取时按每个字两个字节重组再用 Shift-JIS 编码转成 Unicode。Public Function ReadString(device As String, wordCount As Integer) As String Dim raw() As UShort ReadDWords(device, wordCount) Dim bytes(wordCount * 2 - 1) As Byte For i As Integer 0 To wordCount - 1 bytes(i * 2) CByte(raw(i) And HFF) bytes(i * 2 1) CByte((raw(i) 8) And HFF) Next Dim enc As Encoding Encoding.GetEncoding(932) Dim text As String enc.GetString(bytes) Dim idx As Integer text.IndexOf(ChrW(0)) If idx 0 Then text text.Substring(0, idx) Return text.TrimEnd() End Function中文字符在 Shift-JIS 里占两个字节所以会跨两个 D 字。读取时先按字取出所有字节再统一用编码 932 解码不要逐字解码否则双字节字符会被拆开变成乱码。末尾的ChrW(0)截断对应三菱字符串的终止符PLC 里没有显式写入 0 的字符串读出来会有尾部垃圾字符截断是必须的。如果乱码问题依旧考虑 PLC 用的是 UTF-8 写入FX5U 的$MOV支持 Unicode 字符串写入但那是另一套数据布局不在本文的通讯交互范围内。5. FX5U 通讯交互的排错矩阵连接失败、错误码和 Wireshark 抓包核对5.1 连不上 1024 端口时的排查顺序FX5U 通讯交互最让人头疼的不是协议本身而是“连不上”。现场最常见的现象是 C# 程序在办公室连模拟器正常到现场连真机就超时。排查顺序一般是这样先 ping 通 PLC 的 IP确认网线没问题再在 GX Works3 的“简单 CPU 通讯设置”里确认端口号是 1024并且勾选了“允许 RUN 中写入”最后检查 PLC 侧做的以太网配置有没有和别的功能冲突例如以太网模块同时做了 Socket 通讯和 SLMP端口会互相占用。另外一个被忽略的点是FX5U 的 SLMP 服务器只允许 4 个并发连接。如果调试时多次跑程序没正常释放 socket占满之后新的连接会被拒。检查方法是在 Windows 命令行执行netstat -an | findstr 1024如果看到大量ESTABLISHED或者TIME_WAIT状态的连接说明程序没有正确释放资源。C# 程序里必须写在finally里调Dispose或者Close尽量不用using块包裹长连接。因为using在块结束时会释放流但不会主动发送 RST 包PLC 侧需要等 TCP 超时才能感知断开。5.2 SLMP 错误码解读表和响应超时的常见原因PLC 返回的结束代码不为 0 时通讯交互逻辑上已经走通只是请求本身被拒绝。下表是 FX5U 相较常用到的几个错误码错误码含义常见原因0xC051点数超限一次请求超过 960 个字0xC05C软元件地址错误软元件编号编码错误或超出范围0xC056不支持的命令命令号写反了读写了 0x14 0x010xC059数据长度错误请求数据长度字段计算不正确0xC0A0通讯模块繁忙PLC 正在处理大量请求稍后重试超时问题的定位比错误码麻烦。ReadTimeout抛出时不要急着加大超时时间先用 Wireshark 看请求有没有到 PLC。如果抓包只有 SYN 没有 ACK是网络层问题有请求帧但没响应帧是 PLC 配置问题有响应但程序还是超时那是解析逻辑问题说明响应帧读不完整或者长度判断错误。5.3 用 Wireshark 核对双字节和校验与数据对齐很多 SLMP 实现里会加一个双字节和校验字段从帧头到数据末尾的累加和三菱的 MC 协议在串口版里是必须的以太网版 3E 帧其实可以不带FX5U 默认不带校验也能通讯。但有些三菱兼容设备比如部分国产 PLC 模仿 SLMP会强制要求校验所以稳妥的做法是自研的时候带上免得到现场发现对方设备需要校验而源码里完全没这块逻辑。双字节和校验的算法是从帧头字节开始两字节一组作为一个 16 位整数累加溢出回卷最后取反加一。在 Wireshark 里核对时找到报文末尾的校验字段手工按这个规则算一遍就能确认。如果计算的校验和和报文里不一致果断定位是组帧逻辑的问题不要去查 PLC 配置。数据对齐的核对比校验更常用。Socket 通讯时抓包看到的响应数据区如果是读 D 区 10 个字每个字 2 字节第 0 个 D 字在数据区最开始的两字节而且低字节在前。用 Wireshark 抓到一串0x2A 0x00 0x01 0x00这样的数据对应 D042D11。如果程序读出来的 D010752那肯定是字节序取反了把数据区的两字节高低位调换即可。调换位置是解析层唯一要处理的地方不要改动通讯层的解码逻辑。6. 通讯交互压测用自检报文验证 FX5U 响应时间和数据正确性写完通讯交互代码后不建议直接接设备全流程调先在 FX5U 的 D0 到 D9 写入已知测试值具体操作用 GX Works3 的监视功能在线改值。注意写入时区分数据类型D0 写成 16 位整数测试数、D2 起写 32 位浮点测试数、D4 起写字符串测试数、M0 到 M15 写入即位模式注意 FX5U 的位元件从 M0 开始 16 个一组。然后写一个压测小程序循环 1000 次读 D0 到 D9 和 M0 到 M15记录每次的耗时和错误数。正常情况下 FX5U 单次响应在 10 到 30 毫秒1000 次全部成功平均耗时在 15 毫秒左右。如果发现偶发超时检查程序是不是在 UI 线程里同步调用或者在同一连接上并发发了多个请求。SLMP 是请求-应答模型一个连接上同时发多个请求会导致响应错位这是“有时读对有时读错”的头号原因。压测时额外验证一次连续地址读取。FX5U 批量读 D0 到 D19和分 20 次单读 D0 到 D19数据必须完全一致。批量读返回数据的第 i 个值必须和单读 Di 的值相等IO 编号和 CPU 编号不一致时的数据也有可能在批量读时被错误排序这类问题属于 GX Works3 侧的网络配置不是上位机代码能绕开的。最后说调试完收尾时的技巧通讯交互代码里保留一个“原始报文开关”的配置项压测时把它打开每次收发都记录到日志文件或者输出到 Debug 窗口。等实际部署到现场出现偶发问题时直接看这个开关打出来的原始帧用 Hex 工具逐个字节对照第 2 章的帧格式表80% 的问题能在五分钟内定位到是组帧的问题还是解析的问题。这个习惯比任何调试器都管用。本文还有配套的精品资源点击获取

C#/VB与三菱FX5U PLC通过SLMP协议实现以太网通讯交互

相关推荐

T型NPC光伏并网系统设计与仿真实践

紧急车辆警报器声音数据集构建：采集、清洗与识别模型训练

Android代码混淆技术：R8核心机制与Gradle配置详解

更多资讯

用朴素贝叶斯做豆瓣短评情感分析：从原理到实战

Tkinter与Qt混合架构：汽车制造数据看板与监控平台实战

基于Dijkstra与时间窗的AGV调度MATLAB实现与冲突避免

学术文献综述的系统化方法与技术工具应用

LangChain Agent记忆系统设计与优化实践

Astra Prompt工程：Async Tool Calling与Mid-turn Steering实战

今日更新

AI驱动的自动化专利分析平台技术解析

LeetCode-Go 题解：1252. Cells with Odd Values in a Matrix（奇数值单元格计数）双解法剖析

在线答疑系统Java毕设实战：Spring Boot前后端分离与状态流转

本周精选

AI驱动的自动化专利分析平台技术解析

LeetCode-Go 题解：1252. Cells with Odd Values in a Matrix（奇数值单元格计数）双解法剖析

在线答疑系统Java毕设实战：Spring Boot前后端分离与状态流转

本月热门

基于YOLO的焊缝缺陷检测：从数据标注到工业部署全流程实践

分布式服务的决策记录

创业产品的首版范围

读完文章，想聊聊您的网站？