企业官网建设流程全解析

简介：一套基于C#的上位机与库卡机器人TCP通讯实施方案，面向工业自动化开发者、机器人集成工程师及C#上位机学习者。资源完整演示了如何通过Socket建立客户端连接、设计带校验码的数据包格式，并实现实时位置反馈与运动控制指令下发；同时涵盖库卡KRL端服务器配置与响应逻辑。压缩包共39个文件，约18.59MB，主要包含C#工程源码（.cs/.csproj/.sln）、库卡端KRL程序（.src/.dat/.sub）、官方PDF文档、已编译可执行文件及调试日志等，PC端与KUKA端分目录存放，目录结构清晰，便于对照实践和快速定位所需模块。目前已有299人学习下载。通过该资源可掌握C#网络编程、自定义协议设计、KUKA Ethernet KRL接口调用等关键技能，并可直接基于工程进行二次开发，快速搭建机器人远程监控与调试系统，提高工业自动化项目落地效率。

1. 为什么「TCP能连上KUKA」不等于「实时拿到机器人坐标」

很多人第一次做 C# 上位机与库卡机器人对接时，都以为只要 TCP 一连上，屏幕上就能像示教器一样实时刷出机器人坐标，然后想让它动它就动。真实情况是：KUKA 默认的通讯接口和解释器执行周期决定了这个「实时」是打折的，连上了不等于能实时收位置，更不等于能随便发指令让它平滑运动。标题里这个方案真正解决的，是让你用 C# 上位机把机器人的位置数据变成干净可用的轨迹数据，同时把运动指令安全地送回 KRC4 控制器。适合正在做视觉引导、产线上下料、轨迹回放或者设备联动的集成商和上位机开发工程师。本文不会讲某个现成源码包的安装步骤，而是把这个方向最常用的工程路径——EthernetKRL 为主、RSI 为辅——从原理到代码到踩坑完整走一遍。

2. 接口选型：EthernetKRL 与 RSI 差在哪，三种路径怎么选

2.1 KUKA 对外 TCP 通讯的三条常见路径

KUKA KRC4 控制器对外提供 TCP 通讯能力，工程上最常遇到的是三条路。

第一条是EthernetKRL，全称 KUKA.EthernetKRL，是一个软件选件包。它允许 KRL 程序（KUKA Robot Language，库卡机器人编程语言）通过 XML 格式的数据包和外部设备交换数据，走的就是标准 TCP。它的优势是配置相对简单，不需要额外传感器硬件，写变量、读坐标都方便。但它本质上是挂在 KRL 解释器上的通讯，数据刷新率受程序执行周期限制，做不到真正意义的硬实时。

第二条是RSI（Robot Sensor Interface），这是 KUKA 的实时传感器接口选件，数据可以直接和机器人插补周期同步，常见可以在 4ms、8ms、12ms 的周期上收发数据。它才是标题里「实时位置返回及运动控制」的正主。RSI 的配置和开发比 EthernetKRL 复杂，启动停止都有安全限制，但做力控、视觉伺服、高精度运动同步这类项目，非它不可。

第三条是老一代的VarProxy / OPC UA 或工业以太网网关。VarProxy 读写机器人变量很方便，但速度慢，通常几十到几百毫秒甚至秒级；OPC UA 在新控制系统上有，但对于老 KRC4 或者在产线上已有的第三方网关，实时性也谈不上。做运动控制不建议从这条路径入手。

我一般会这样判断：如果你的需求只是「实时位置返回」用于监控、轨迹记录、视觉引导的下发目标位置，EthernetKRL 足够，成本低见效快。如果需求是「运动中持续控制、外部传感器闭环」，直接考虑 RSI，不要在 EthernetKRL 上强行做闭环，后面会讲为什么。

2.2 EthernetKRL 与 RSI 的对比：刷新率、选件、控制方式

这个对比决定了章节顺序：我先把 EthernetKRL 的方案讲透，因为它是多数项目里「先做起来」的那条路，代码可以直接抄；然后给出 RSI 的替代思路，你在真正需要硬实时时知道往哪走。

2.3 TCP 通讯的数据帧长什么样：XML 包和 RSI ASCII 包

EthernetKRL 的典型数据交换是 XML。常见形状如下：

<EKI> <Frame> <X>1234.5678</X> <Y>-234.4567</Y> <Z>890.1234</Z> <A>12.34</A> <B>-5.67</B> <C>88.90</C> </Frame> <Var Name="STATE" Type="INT">1</Var> </EKI>

这里<X>、<Y>、<Z>是笛卡尔坐标，单位毫米；<A>、<B>、<C>是姿态欧拉角，单位度。<Var>节点是自定义变量区域，用于传工具号、状态字、目标速度等。注意不同版本 EKI 的 XML 结构有差异，有的版本包裹节点不叫<Frame>，字段顺序也可能变化，所以第一件事是拿 WorkVisual 里导出的样例 XML 来核对节点名，不要照抄任何网上模板。

RSI 走 TCP 时，每帧是定长的 ASCII 字符串，字段之间用空格或分号分隔，字段顺序和你配置的 RSI 对象顺序一致。例如你定义了输入六个速度值，上位机每次就发一行：

1 0.00 0.00 0.00 0.00 0.00 0.00

最前面的1通常是帧计数器或者触发字，机器人侧用它判断数据是否是新帧。RSI 这点很关键：字段个数、顺序、分隔符完全由你机器人侧的配置决定，没有统一标准，上位机程序必须跟着机器人侧走。

2.4 数据流与坐标系：拿到 X/Y/Z/A/B/C 之后先别急着用

KUKA 反馈的 X/Y/Z/A/B/C 不是凭空生成的。它基于当前激活的$BASE（基坐标系）和$TOOL（工具坐标系）计算。同一台机器人，你把工具坐标换成长杆，反馈的 X/Y/Z 就会变；切换了 BASE，姿态角也会整体变化。

所以上位机拿到坐标后第一件事，不是画轨迹，而是确认这套坐标是相对于哪个 BASE 和 TOOL 算出来的。常见做法是：在机器人程序里把位置换算到项目统一基准坐标系再发出来，比如用 KRL 的几何运算把$POS_ACT转换到 WORLD 坐标系下。这样上位机永远只认一套坐标参考系，不会因为现场谁改了个工具号，轨迹就整体便宜几十毫米。

另一个容易忽略的点是 A/B/C 欧拉角的连续性。KRC 控制器输出的角度范围有限制，当机器人姿态跨越边界时，角度会发生大幅跳变，比如从 179 度跳到 -179 度。这个问题我在第 4 章会给具体处理代码，这里先记住：坐标和姿态必须做归一化和基准确认，再做运动控制逻辑。

3. 机器人端准备：EKI 的 XML 配置与 KRL 程序样例

3.1 在 WorkVisual 里配置 EthernetKRL 通讯器

EthernetKRL 的配置入口是 KUKA 的 WorkVisual 软件。常见做法是：在项目里添加 EthernetKRL 通讯器，配置连接名称、端口号和通讯模式。机器人端作为服务器时，要设置监听端口，比如 7911；作为客户端时，要填上位机的 IP 和端口。

这里有几个参数值得注意。通讯模式我一般选服务器模式，机器人开机后程序起来就监听，上位机随时可以连入，便于上位机做重连。数据长度和缓冲区只有在传输异常时才需要调，先保持默认。扫描周期决定了数据刷新率，但扫描周期设短了，KRL 解释器负载会上去，可能导致程序其他逻辑卡顿。我的习惯是先按默认周期跑通，再逐步调短，别一上来就追求极限。

注意：EthernetKRL 选件需要在 KUKA 侧授权并激活，WorkVisual 只是配置界面，实际运行依赖控制器里的选项状态。如果你在 WorkVisual 里配完发现机器人程序里调用不了 EKI 函数，先去查选件是否激活。

3.2 一个能按周期发位置、收指令的最简 KRL 程序

有了通讯器配置之后，机器人侧需要写一段 KRL 程序来建立连接、周期发送位置帧、接收指令。下面是常见写法的骨架：

; 初始化通讯 EKI_Init("INI_XML") EKI_Open("INI_XML") ; 主循环：周期性发送位置帧 LOOP ; 发送当前位置数据到上位机 EKI_SendXML("INI_XML", "POS_FRAME", $POS_ACT) ; 读取上位机下发的目标速度或控制字 EKI_ReadXML("INI_XML", "CTRL_VAR", "VEL_X") ; 根据控制字执行运动逻辑 IF flag_move THEN ; 这里的运动控制逻辑可以是 LIN_REL 或速度控制 ENDIF WAIT SEC 0.05 ENDLOOP EKI_Close("INI_XML")

这段 KRL 的逻辑是：先初始化并打开通讯连接，进入循环后周期发送当前位置$POS_ACT，同时读取上位机写入的变量。WAIT SEC 0.05是循环等待 50 毫秒，实际周期取决于通讯配置和解释器负载，不是精确的 50ms。

要注意的点是EKI_SendXML发送的数据内容由你定义的 XML 模板决定，模板里要先把$POS_ACT的六个分量和一个状态字包进去，上位机才能解析出坐标。EKI_ReadXML读取的是上位机写过来的变量，比如目标速度VEL_X、使能字ENABLE这些。循环里不能只做通讯，不做运动判断，否则控制指令没有被消费，上位机那边写再快也没用。

3.3 要求更高实时性时，RSI 的配置路径简述

如果你的项目最终要上 RSI，机器人侧的工作量比 EKI 大不少。常见路径是：在 WorkVisual 里新建 RSI 项目，添加RSI_Read和RSI_Write对象，把外部输入的速度值连接到机器人轴速度叠加对象上，位置数据通过RSI_Write周期性送出。机器人侧的程序是 SRV 类型，启动后进入 RSI 监控循环，外部输入每一帧数据都会被插补周期消费。

RSI 上线最大的坑是安全逻辑。位置或速度叠加量过大会触发安全监控直接停机，所以调试时叠加量要从小往大加，先让机器人在小范围内动，确认方向正确再放开限幅。这里不做完整 RSI 教程，你只要知道：RSI 才是真正的实时方案，EKI 适合前期开发和大部分非闭环场景，后面第 4 章的 C# 代码里我会给出两种数据格式的解析写法，上位机侧其实可以提前按 RSI 的帧格式准备好。

3.4 机器人侧发送的坐标系基准：在 KRL 里先做好再发

前面提到上位机要统一坐标系基准。KRL 侧的做法是，不要直接发$POS_ACT，而是先做坐标系变换再发送。比如把当前位姿从当前 BASE 转换到项目约定的机器人 WORLD 坐标系：

DECL E6POS CURRENT_POS CURRENT_POS = $POS_ACT ; 用几何算子将当前位置转换到 WORLD 坐标系 CURRENT_POS = INV_POS(CURRENT_POS)

INV_POS是 KRL 里常用的逆变换函数，但它返回的具体含义要看你变换的对象。更保险的方式是用GEOMETRY类型的变量和 KUKA 的几何运算规则做矩阵变换，把$POS_ACT和当前$BASE、$TOOL相乘，得到 WORLD 系坐标。这个逻辑我一般放在机器人程序里，因为 KRL 做这种变换是基于原始坐标，比上位机拿欧拉角反算靠谱得多。

提示：不要在 C# 侧用一个固定公式去把各个 BASE 下的坐标换算成 WORLD 系，因为你无法总是拿到现场的 BASE 和 TOOL 定义，而且欧拉角反算很容易出现顺序歧义。把坐标系问题留在 KRL 侧解决，上位机只处理已经统一的数据。

4. C# 上位机拿到位置并控制运动：核心代码与调参

4.1 用 TcpClient 建立连接：NoDelay、超时与断线重连

C# 上位机连接 KUKA 机器人，技术栈很简单，就是System.Net.Sockets.TcpClient，但有几个参数会影响通讯质量，尤其是 Nagle 算法。Nagle 算法会把小数据包合并发送，在机器人通讯这种高频小包场景下会造成额外延迟，必须关掉。

下面的代码展示了建立连接的基础写法：

using System.Net.Sockets; public class KukaTcpClient { private TcpClient _client; private NetworkStream _stream; public bool Connect(string ip, int port, int timeoutMs = 5000) { _client = new TcpClient(); // 关键：关闭 Nagle 算法，避免小数据包延迟合并 _client.NoDelay = true; IAsyncResult result = _client.BeginConnect(ip, port, null, null); // 连接超时控制 bool success = result.AsyncWaitHandle.WaitOne(timeoutMs); if (success) { _client.EndConnect(result); _stream = _client.GetStream(); _stream.ReadTimeout = 2000; // 读超时，防止阻塞 _stream.WriteTimeout = 2000; // 写超时 return true; } return false; } }

这段代码的逻辑是先创建TcpClient，把NoDelay设为true，这样每次 Send 的数据都会立即发出，不会被 Nagle 算法攒在缓冲区里。连接超时用的是BeginConnect+WaitOne的方式，避免 UI 线程卡死。读超时和写超时都设了 2 秒，防止机器人端链路异常后程序一直阻塞。

实际项目中，机器人程序可能随时重启，TCP 连接一定会断开。断开后上位机不能只报错，要有重连机制。重连的常见做法是指数退避：第一次失败等 1 秒，第二次 2 秒，第三次 4 秒，最多到 10 秒，避免机器人端还没有完全启动时，上位机疯狂重连把端口占满。

4.2 解析 KUKA 的 XML 位置帧：用 XDocument 而不是字符串 Split

从 EthernetKRL 收到的数据是 XML 文本，解析方式很多人第一反应是string.Split，但这样写不仅难看，还极易出错。正确的做法是用System.Xml.Linq.XDocument来解析。下面是解析位置帧的代码：

using System.Xml.Linq; public class KukaPosition { public double X, Y, Z, A, B, C; public DateTime Timestamp; } public static KukaPosition ParsePositionFrame(string xmlText) { XDocument doc = XDocument.Parse(xmlText); KukaPosition pos = new KukaPosition(); // 取 <X>、<Y> 等子节点，空值返回 0 pos.X = (double?)doc.Descendants("X").FirstOrDefault() ?? 0.0; pos.Y = (double?)doc.Descendants("Y").FirstOrDefault() ?? 0.0; pos.Z = (double?)doc.Descendants("Z").FirstOrDefault() ?? 0.0; pos.A = (double?)doc.Descendants("A").FirstOrDefault() ?? 0.0; pos.B = (double?)doc.Descendants("B").FirstOrDefault() ?? 0.0; pos.C = (double?)doc.Descendants("C").FirstOrDefault() ?? 0.0; pos.Timestamp = DateTime.UtcNow; return pos; }

这里用Descendants("X")的好处是，不管 XML 里有多少层嵌套节点，都能直接找到名为 X 的元素。?? 0.0是空值保护，当机器人某一帧数据缺失某个坐标分量时，程序不会抛异常，而是返回 0，后续可由上层逻辑判断。

一个隐藏的坑是数字格式。机器人端发送的坐标用的是英文小数点，比如1234.5678。如果上位机系统区域设置是中文，Convert.ToDouble遇到小数点可能解析失败或解析出完全错误的值。C# 里处理这个问题必须显式指定文化：

double x = Convert.ToDouble(xmlText, CultureInfo.InvariantCulture);

4.3 把 A/B/C 角度的跳变拉回来：角度归一化

KUKA 反馈的 A/B/C 欧拉角，在跨越 ±180 度边界时会跳变。比如前一条数据 A=178 度，下一条可能是 -179 度，实际变化只有 3 度，但直接做差值计算会得出 357 度，导致运动控制里出现一个巨大的假速度。这就是标题里「实时位置返回」最容易遇到的怪现象。

角度归一化的代码很简单，但每个做上位机的人都应该写成工具函数：

public static double WrapAngle180(double angleDeg) { double wrapped = angleDeg % 360.0; if (wrapped > 180.0) wrapped -= 360.0; else if (wrapped < -180.0) wrapped += 360.0; return wrapped; }

使用方法是：不是改原始数据，而是在计算差值时调用。比如计算当前姿态和目标姿态的 A 角偏差：

double deltaA = WrapAngle180(targetA - currentA);

这样得到的deltaA永远在 -180 到 180 之间，差值方向正确，不会出现假跳变。这个函数同样适用于 B、C 角。角度归一化不是可选项，凡是做运动控制的上位机，必须处理，否则轨迹跟踪曲线会莫名出现尖刺。

4.4 把控制指令送回去：写入变量与 RSI 速度帧

运动控制指令下发，EKI 方式是构造 XML 写变量。比如要下发目标速度到机器人端 KRL 变量VEL_X：

public void SendVelocity(double velX) { // 显式指定不变文化，避免小数点变成逗号 string xml = "<EKI><Var Name=\"VEL_X\" Type=\"REAL\">" + velX.ToString("F2", CultureInfo.InvariantCulture) + "</Var></EKI>"; byte[] buffer = Encoding.UTF8.GetBytes(xml); _stream.Write(buffer, 0, buffer.Length); _stream.Flush(); }

这段代码的关键在CultureInfo.InvariantCulture。如果漏掉这个，在德语区或者某些系统区域设置下，ToString("F2")可能把 12.50 变成 12,50，机器人端解析 XML 时直接类型转换失败，指令被丢弃，而且从日志里很难看出来。

RSI 方式则是发送定长 ASCII 帧，比如六个速度分量加上一个帧计数器：

public void SendRsiVelocity(double[] velocities, int frameId) { // 帧格式：帧ID + 6个速度值，空格分隔 StringBuilder sb = new StringBuilder(); sb.Append(frameId.ToString(CultureInfo.InvariantCulture)); foreach (double v in velocities) { sb.Append(' '); sb.Append(v.ToString("F3", CultureInfo.InvariantCulture)); } byte[] buffer = Encoding.ASCII.GetBytes(sb.ToString() + "\r\n"); _stream.Write(buffer, 0, buffer.Length); }

RSI 帧发送的节奏是每次必须按机器人侧插补周期发送，漏一拍或者多发一拍，安全逻辑都会报警。所以 C# 侧要用Stopwatch精确计时，而不是Thread.Sleep，因为Thread.Sleep的时间误差在 Windows 上可能到十毫秒级，对于 4ms 周期的 RSI 来说是致命的。

4.5 帧计数与时间对齐：给数据打时间戳

做实时位置监控，不能只看到坐标在变，还要知道这一帧是机器人什么时候发出的。常见做法是机器人端在发送的数据里带一个递增计数器或者时间戳，C# 侧把接收时间和帧计数一起存下来，用来计算链路延迟。

C# 侧的数据接收可以设计成一个环形缓冲，收到一帧就解析一帧，并把本地接收时间记上：

private void ReceiveLoop() { while (_running) { if (_stream.CanRead) { // 读取一帧数据，假设按换行符分帧 string line = _stream.ReadLine(); if (string.IsNullOrEmpty(line)) continue; KukaPosition pos = ParsePositionFrame(line); pos.Timestamp = DateTime.UtcNow; // 丢入线程安全队列，UI 或上层逻辑异步消费 _frameQueue.Add(pos); } } }

分帧方式需要和机器人端约定好，EKI 的 XML 包一般以换行符结尾，RSI 的 ASCII 帧也是用\r\n结尾。用ReadLine可以天然按帧读取，不需要自己拼半包。这里要注意NetworkStream没有内置ReadLine，我一般会封装一个带内部缓冲的读取方法，或者直接用底层的Read方法按字节读取直到遇到换行符。

时间戳的对齐价值在于：当你在上位机上做轨迹插补时，知道每一帧数据的实际延迟，才能判断某个坐标点该匹配到哪个参考位置。没有时间戳的位置流，只能做监控显示，不能用来做严格的轨迹复现。

5. 实战避坑：TCP + KUKA 运动控制常见的 5 个翻车现场

5.1 连接正常但位置数据卡顿，帧间隔忽长忽短

现象：上位机连上机器人，能收到位置，但帧间隔不稳定，有时 50ms，有时 300ms。查询机器人侧程序循环时间又很短。

原因：最常见的是上位机接收 socket 上 Nagle 算法没有关闭，小数据包被操作系统攒在缓冲区里，等到一定数量才一起发出去。其次是 KRL 程序里通讯发送函数和运动指令混在同一个循环，运动指令执行时间过长拖慢了整个周期。

解决：C# 侧TcpClient.NoDelay = true，关闭 Nagle。机器人侧把通讯发送逻辑从运动执行逻辑中分离，或者用独立的提交解释器周期。若问题依旧，抓包看 TCP 数据包到达时间，区分是机器人侧发送慢还是上位机接收慢。

5.2 机器人位置曲线出现尖刺，角度跳变几百甚至上千度

现象：上位机实时曲线中，A/B/C 角度偶尔出现剧烈跳动，同一时刻机器人实际并没有做大幅度转动。

原因：欧拉角跨越 ±180 度边界时没有归一化，直接做了差值或显示。这属于数据后处理问题，不是机器人真的动了。

解决：在 C# 侧对 A/B/C 做WrapAngle180归一化后再计算差值。同时在显示曲线时，也不要用原始值连线，而是对每帧和上一帧的差值做归一化，保证曲线连续。

5.3 机器人程序一停，上位机连接就断开且无法自动恢复

现象：调试时机器人端把 KRL 程序手动停止，TCP 连接立刻断开，上位机卡在异常状态，必须手动重启程序才能重新连接。

原因：EthernetKRL 或 RSI 的连接生命周期绑定在 KRL 任务上。程序停止，通讯任务被杀，socket 关闭。上位机如果不做自动重连，就只能干等。

解决：C# 侧做断线重连，重连间隔用指数退避，同时把重连状态显示在界面上。机器人侧在程序末尾或异常处理中主动关闭连接并回到等待连接状态，这样上位机重连就能再次建立会话。

5.4 下发速度后机器人没反应，查日志发现指令根本没被解析

现象：上位机发送速度指令，机器人端变量始终是旧值，或者直接出现类型转换错误日志。

原因：数字格式化问题。在中文或德语区域设置下，velX.ToString("F2")可能生成小数逗号，机器人端 XML 解析器按小数点解析就把整个值当非法数据丢弃。

解决：所有下发数值统一用CultureInfo.InvariantCulture格式化。另外不要在 C# 侧把字符串拼好之后再做一次隐式转换，每一步都显式指定文化。这个坑在工业现场特别隐蔽，因为本机调试时系统区域可能是英文，一切正常，部署到客户电脑后才翻车。

5.5 控制指令一下发，机器人立刻触发安全停机

现象：好容易数据链路通了，上位机发一个速度值，机器人刚动一下，控制器弹出 safe stop 报警，现场直接停工。

原因：EKI 写入的变量被直接用于运动叠加，而叠加量或速度值超出了控制系统安全监控的限幅；RSI 场景下则是外部输入速度过大触发拓展安全监控。

解决：运动控制联调时，上位机下发值必须从极小量开始，比如速度先给 1mm/s，确认运动方向正确后再逐步加大。限幅逻辑放在上位机底层，不允许业务代码直接传一个任意大的值。另外 KRL 侧对指令变量可以做一次平滑和限幅，双保险。

6. 冲更高刷新率之前：先验证数据链路，再谈实时控制

当你把上位机跑起来，位置能显示、指令能下发，先别急着追求更快的刷新率，花一个下午做链路验证是值得的。

第一步，验证位置数据的准确性。让机器人以一个已知轨迹运动，比如画一个 200mm 见方的矩形，上位机把接收到的 X/Y/Z 坐标写入 CSV。然后用这些数据重新绘制轨迹曲线，对比实际矩形尺寸。偏差超过一两毫米，先查坐标系基准是不是没统一，不要急着怪 TCP 延迟。

第二步，验证帧间隔的稳定性。在 C# 里用Stopwatch记录每一帧到达的时间差，统计最大、最小和平均帧间隔。如果最大帧间隔超过平均值的 3 倍，链路就有抖动问题，后续做实时控制一定会出鬼。排查抖动时，除了查 Nagle，还可以看一下 Windows 的 TCP 全局参数：

netsh int tcp show global

如果发现Timestamps状态异常或者网卡卸载策略导致小包延迟，可以按需调整。这类网络参数属于黑匣子范畴，一般不需要乱动，但排查时序问题时值得看一眼。

第三步，验证控制指令的往返延迟。可以在上位机发一帧「请求位置」指令，记录发送时间，机器人端收到后立即回一帧包含当前坐标的数据，上位机计算时间差。这个往返时间决定了你能不能做闭环控制。如果往返时间超过控制周期，就必须上 RSI 或者重新设计控制架构。

最后分享一条血泪经验：我曾经做过一个视觉引导项目，上位机显示的位置和机器人实际轨迹总差一拍，查了很久，最后发现是上位机接收线程里做了大量字符串解析和日志写入，数据到达时间戳是在解析完成之后才记的，一帧的延迟被解析耗时吃掉了。后来把时间戳记录挪到收到原始字节的那一刻，问题立刻消失。做实时位置处理，时间戳必须打在最接近硬件接收的位置，这是很多人容易忽略的。希望这些从方案选型到代码细节再到排查方法的经验，能帮你在做 C# 上位机和 KUKA 机器人对接时，少走几步弯路。

本文还有配套的精品资源，点击获取