简介：一套完整的C#上位机与库卡（KUKA）机器人TCP通讯方案，面向需要实现机器人远程监控、位置回读与运动控制的工程师、调试人员和自动化项目开发者。方案基于KUKA系统软件8.3版本与.NET Framework 4.0环境，包含KUKA端的配置文件、子程序、KRL源代码，以及PC端上位机程序，可实时获取机器人各关节位置并导出CSV文件，同时支持关节单步运动和从当前位置到给定坐标的点运动。从机器人端程序编写、上位机界面设计，到通讯参数配置与数据导出，均有对应模块支撑，能帮助快速搭建可实际运行的调试环境。资源共68个文件，以PDF说明文档、C#源码、XML配置、KRL源程序、TXT说明和辅助可执行文件为主，并附有Ethernet KRL协议、KUKA系统软件等学习资料；压缩包约36.47MB，目录清晰区分PC端与KUKA端，便于按需查阅。已有737人学习下载，适合希望通过C#二次开发库卡机器人通讯与控制功能的中高级用户。 做工业自动化的朋友应该都遇到过这个场景：产线上有一台库卡机器人，需要和上位机系统做数据交互，上位机要实时看到机器人当前坐标，还得能下发指令让机器人动起来。很多人第一反应是上OPC UA或者走硬件IO，但实际项目里往往没那么复杂，一条TCP链路就能把活干完。这篇文章就是我实际做过的方案：用C#写上位机，通过TCP和KUKA机器人通讯，实现位置实时回传和运动控制，整个过程从KRL端到C#端全部拆开讲清楚，适合正在做类似项目的工程师直接参考。
这个方案的核心思路就一个词：XML报文。KUKA控制器自带的EthernetKRL（EKI）功能天生就支持走TCP收发XML格式的数据，机器人侧写一段KRL程序就能作为TCP服务端，上位机作为客户端连进来，双向收发数据。相比OPC UA那一套，EthernetKRL不需要额外授权，配置简单，实时性也够用，几十毫秒一个周期轻松做到。如果你也是用C#做上位机开发，这篇文章应该能帮你少走不少弯路。
1. 项目背景与技术选型思路
1.1 为什么选C# + TCP通讯
选型这事得从现场实际需求说起。当时项目里的KUKA机器人是KRC4控制器，产线MES系统要求机器人把当前坐标、状态、报警信息实时上传，同时支持调度系统下发目标点让机器人自动跑位。现场没有现成的PLC中转，机器人本体也没配OPC UA授权，最快能落地的方案就是走TCP。
C#做上位机在这个场景里非常合适。WinForm做界面快，TcpClient封装得又好用，序列化和解析XML有现成的XMLDocument，开发效率比C++高一大截。而且C#的异步编程模型处理TCP长连接很顺手，不用担心界面卡死的问题。另一个原因是后期维护方便，产线上的设备程序不是你写完就不管了，后续要加功能、改界面，C#的可维护性比MFC那种老框架好得多。
再聊聊TcpClient这个类。很多人总觉得TcpClient性能不行，其实在工业上位机这个量级完全够用。KUKA的EthernetKRL本身就不是为超高吞吐设计的，一个周期处理一个XML报文足够了。真正要注意的是超时处理、断线重连这些工程问题，而不是纠结性能。
1.2 整体架构与数据流设计
先画一下整体架构，不用图也能说清楚：C#上位机作为TCP客户端，主动连接KUKA控制器上的EthernetKRL服务端。通讯端口默认是54600，KUKA侧通过KRL程序创建Socket服务并维护连接。数据流向有两个方向：上行是上位机发指令（读位置、移动、停止等），下行是KUKA返回的响应（位置坐标、状态、运动结果）。
数据交互我设计了两种模式，项目里都用到过：
- 请求-响应模式：上位机发一条指令，KUKA处理后返回结果。适合点位读取、坐标下发、状态查询这类操作，简单直接，同步逻辑好写。
- 主动推送模式：KUKA侧每个扫描周期主动把位置数据推给上位机，上位机被动接收。适合实时位置监控、轨迹跟踪这类需要持续刷新数据的场景。
实际项目里我一般两种模式混合用：实时位置用推送，运动控制和状态切换用请求响应。这样既保证了位置显示的流畅性，又让控制逻辑清晰可追溯。
2. KUKA机器人侧通讯配置与KRL编程
2.1 EthernetKRL通讯配置要点
KUKA的EthernetKRL（简称EKI）是自带的功能包，不需要额外购买授权，这是选它很关键的一个原因。使用前要在机器人控制器的src目录下找到EthernetKRL文件夹，里面的配置文件EthernetKRL.xml决定了Socket服务的行为。
配置文件里要注意几个参数：
<ETHERNETKRL> <CONFIGURATION> <EXTERNAL> <IP>192.168.0.100</IP> <PORT>54600</PORT> </EXTERNAL> <INTERNAL> <IP>192.168.0.10</IP> <PORT>54601</PORT> </INTERNAL> </CONFIGURATION> </ETHERNETKRL>EXTERNAL是外部连接的IP和端口，也就是上位机要去连的地址。INTERNAL是KUKA内部的回环地址和端口，一般不轻易动。配置完要重启机器人控制器才能生效。这里有个小坑：如果你改了端口或者IP，一定记得在KUKA的防火墙里放行，不然连不上，排查半天都不知道问题出在哪。
EKI实例创建好之后，可以通过KRL端的EKI_Init函数初始化通讯连接。每次启动KRL程序前确认EthernetKRL的XML配置文件名和你的代码里一致，我见过不少次配置文件名字拼写不一致导致初始化失败的。
2.2 KRL端服务程序：位置反馈与运动控制实现
KRL这边我写了一个通用的TCP服务程序，核心逻辑就三步：接收上位机指令、解析指令内容、执行对应动作并返回结果。下面是一个简化版的例子，你们可以基于这个改。
DEF TCP_Server() INT ret CHAR cmd[128] DECL E6POS pos ; 初始化EKI并开放监听 ret = EKI_Init("TCP_SERVER") ret = EKI_Open("TCP_SERVER") LOOP ; 读取上位机发来的指令 cmd[] = EKI_GetString("TCP_SERVER","Command") ; 指令1：读取当前实时位置 IF cmd[] == "GET_POS" THEN pos = $POS_ACT EKI_SetReal("TCP_SERVER","X", pos.X) EKI_SetReal("TCP_SERVER","Y", pos.Y) EKI_SetReal("TCP_SERVER","Z", pos.Z) EKI_SetReal("TCP_SERVER","A", pos.A) EKI_SetReal("TCP_SERVER","B", pos.B) EKI_SetReal("TCP_SERVER","C", pos.C) EKI_SetString("TCP_SERVER","Result","OK") ENDIF ; 指令2：运动到目标位置 IF cmd[] == "MOVE_TO_POS" THEN pos.X = EKI_GetReal("TCP_SERVER","TargetX") pos.Y = EKI_GetReal("TCP_SERVER","TargetY") pos.Z = EKI_GetReal("TCP_SERVER","TargetZ") pos.A = EKI_GetReal("TCP_SERVER","TargetA") pos.B = EKI_GetReal("TCP_SERVER","TargetB") pos.C = EKI_GetReal("TCP_SERVER","TargetC") PTP pos EKI_SetString("TCP_SERVER","Result","DONE") ENDIF ; 指令3：停止运动 IF cmd[] == "STOP_MOVE" THEN BRAKE EKI_SetString("TCP_SERVER","Result","STOPPED") ENDIF WAIT SEC 0.01 ENDLOOP END这段代码里有个细节值得注意：$POS_ACT是KUKA读取当前实际位置最常用的系统变量，返回的是E6POS类型数据，含X、Y、Z坐标和A、B、C姿态角。我们把它拆成一个一个的Real变量返回给上位机，上位机拿到后拼回坐标数据，这个拆解过程保证了XML报文的可读性。
运动控制这里用的是PTP指令，适合点位到点位的快速移动。如果你的场景需要直线走指定轨迹，把PTP pos换成LIN pos就行。两者区别在于PTP按关节运动，速度快但走的是曲线；LIN是按笛卡尔空间的直线运动，适合需要保持轨迹路径的场合。
有一点必须提醒：KRL里操作EKI变量的取值和赋值，都是在机器人控制器的R1进程里跑的，如果你的程序在运动过程中同时读写EKI，要考虑扫描周期内数据的一致性，别一个运动周期里前后读到同一个变量两次不一样的值。实际项目中我习惯在KRL端用标志位做简单的互斥，保证同一时间只有一个数据访问任务。
3. C#上位机核心实现
3.1 通讯层封装
C#这头我写了一个KukaRobotClient类，把TCP连接、发送报文、接收响应、断线重连这些都封装起来。这样做的好处是业务逻辑可以完全关注在指令交互上，不用每次调用都去写Socket代码。
public class KukaRobotClient { private TcpClient _client; private NetworkStream _stream; private readonly object _lockObj = new object(); private readonly string _host; private readonly int _port; private readonly int _timeout = 3000; public KukaRobotClient(string host, int port) { _host = host; _port = port; } public bool Connect() { try { _client = new TcpClient(); IAsyncResult ar = _client.BeginConnect(_host, _port, null, null); bool success = ar.AsyncWaitHandle.WaitOne(_timeout); if (!success) { throw new TimeoutException("连接KUKA超时"); } _client.EndConnect(ar); _stream = _client.GetStream(); _stream.ReadTimeout = _timeout; _stream.WriteTimeout = _timeout; return true; } catch (Exception ex) { Console.WriteLine($"连接失败: {ex.Message}"); return false; } } public string SendReceive(string xml) { lock (_lockObj) { if (_client == null || !_client.Connected) { throw new InvalidOperationException("连接未建立或已断开"); } byte[] sendData = Encoding.UTF8.GetBytes(xml); _stream.Write(sendData, 0, sendData.Length); _stream.Flush(); using (MemoryStream ms = new MemoryStream()) { byte[] buffer = new byte[4096]; int bytesRead; // 循环读直到对端关闭写或读到足够数据 while ((bytesRead = _stream.Read(buffer, 0, buffer.Length)) > 0) { ms.Write(buffer, 0, bytesRead); if (bytesRead < buffer.Length) break; } return Encoding.UTF8.GetString(ms.ToArray()); } } } public void Disconnect() { _stream?.Close(); _client?.Close(); } }这段代码里比较重要的是发送接收用的同一个锁对象。为什么加锁？因为上位机界面往往有多个功能同时在跑，比如位置刷新线程在发GET_POS，用户点击下发运动指令也在发MOVE_TO_POS，如果两个请求同时挤到一个TCP流里，响应就会串掉。加锁保证同一时刻只处理一个请求响应，虽然牺牲了一点并发度，但对KUKA这种单连接通讯来说最稳定。
还有一个细节是读取响应的逻辑。EthernetKRL的响应是以XML文本形式返回的，没有专门的消息头或结束符，所以我这里用了一个取巧的方法：一直接收直到对端暂时没数据可读（Read返回小于缓冲区长度），再拼装成完整XML。实测在局域网环境下这个逻辑很可靠，但如果网络抖动可能有偶发拆分问题。更稳的做法是约好固定长度的报文，不过EthernetKRL的XML不定长，所以实际项目中我更推荐用超时控制加缓冲拼接的方式，读不到数据就跳出循环。
3.2 XML指令构造与响应解析
KUKA的EthernetKRL对XML格式要求比较严格，根节点必须是Robot，然后挂EKI节点，指令和数据都放在EKI下面。
举个例子，构造一个读取位置指令：
string GetPosXml() { return "<Robot><EKI><Command>GET_POS</Command></EKI></Robot>"; }构造运动控制指令：
string MoveToPosXml(double x, double y, double z, double a, double b, double c) { return $@"<Robot><EKI> <Command>MOVE_TO_POS</Command> <TargetX>{x.ToString("F3")}</TargetX> <TargetY>{y.ToString("F3")}</TargetY> <TargetZ>{z.ToString("F3")}</TargetZ> <TargetA>{a.ToString("F3")}</TargetA> <TargetB>{b.ToString("F3")}</TargetB> <TargetC>{c.ToString("F3")}</TargetC> </EKI></Robot>"; }这里有个小坑要提醒：浮点数格式化一定要用固定小数位数，KUKA的KRL解析对1.200和1.2的处理没差别，但你要保证发给它的是合法数值，不要出现NaN或者科学计数法格式。C#默认的ToString在某些文化区设置下会用逗号当小数点，必须用ToString("F3", CultureInfo.InvariantCulture)才能保证KUKA认得。
响应解析用XmlDocument就行，KUKA返回的XML结构基本就是请求XML加上返回的数据字段。比如GET_POS的响应大概是：
<Robot><EKI> <Command>GET_POS</Command> <X>1234.567</X> <Y>-234.890</Y> <Z>1800.234</Z> <A>0.000</A> <B>45.678</B> <C>90.123</C> <Result>OK</Result> </EKI></Robot>解析代码：
public RobotPosition ParsePosition(string responseXml) { XmlDocument doc = new XmlDocument(); doc.LoadXml(responseXml); RobotPosition pos = new RobotPosition(); pos.X = GetNodeDouble(doc, "X"); pos.Y = GetNodeDouble(doc, "Y"); pos.Z = GetNodeDouble(doc, "Z"); pos.A = GetNodeDouble(doc, "A"); pos.B = GetNodeDouble(doc, "B"); pos.C = GetNodeDouble(doc, "C"); return pos; } private double GetNodeDouble(XmlDocument doc, string nodeName) { XmlNode node = doc.SelectSingleNode($"//{nodeName}"); if (node == null) return 0; return Convert.ToDouble(node.InnerText, CultureInfo.InvariantCulture); }用SelectSingleNode按节点名取数是最省事的做法。注意别用String.Replace去手动解析XML，那会把自己坑死，老老实实用XmlDocument或者LINQ to XML。
3.3 实时位置显示与跨线程刷新
实时位置回传我用的是后台线程加Timer的组合。简单场景下开一个System.Windows.Forms.Timer，100ms触发一次，每次发GET_POS拿坐标刷新界面。但项目里如果位置刷新频率要求高，比如做视觉跟踪或者轨迹监控，就要用单独的后台线程循环。
这里必须要处理跨线程访问控件的问题。WinForm的UI控件只能在UI线程里操作，后台线程直接赋值CheckBox.Text或者TextBox.Text会抛InvalidOperationException。用Invoke或者BeginInvoke把UI更新调度回UI线程执行。
private void RefreshPositionLoop() { while (_running) { try { string xml = GetPosXml(); string response = _client.SendReceive(xml); RobotPosition pos = ParsePosition(response); if (InvokeRequired) { BeginInvoke(new Action(() => { labelX.Text = pos.X.ToString("F3"); labelY.Text = pos.Y.ToString("F3"); labelZ.Text = pos.Z.ToString("F3"); })); } } catch (Exception ex) { // 记录日志并处理重连 } Thread.Sleep(100); } }多说一句后台循环的位置，如果你是在UI线程里先开了线程又在后台无限循环，务必加一个CancellationToken或者bool开关，窗体关闭时安全退出循环。不然关了窗口进程还不退，过一会儿就会有人喊上位机占着机器人连不上，这种问题在车间里很常见。
另一种实时性好一点的方案是让KUKA主动推送位置数据，上位机只接收不请求。这样省掉了请求-响应的半轮询开销，位置数据更平滑。实现也不复杂：KRL程序里每个循环周期用EKI_SetReal更新位置字段，上位机端收到数据后解析UI刷新。我实际项目里就是这么做的，20ms一个推送周期，界面上坐标刷新非常流畅。
3.4 运动控制指令与状态机设计
运动控制这块，我不建议把下发的业务逻辑写成一次性发完就结束的模式。更稳妥的做法是设计一个简单的状态机，把整个运动控制流程串起来。
状态机大概分这几个状态：
- Idle（空闲）：机器人就绪，等待指令
- Moving（运动中）：已下发移动指令，等待执行完成
- Done（完成）：运动完成，位置到达目标点
- Error（故障）：运动过程或通讯出现异常
C#端的主流程就是在一个循环里发指令、查状态、等结果。
public bool MoveToPosition(RobotPosition target, int timeoutMs) { string cmdXml = MoveToPosXml(target.X, target.Y, target.Z, target.A, target.B, target.C); string resp = _client.SendReceive(cmdXml); if (!resp.Contains("DONE")) { return false; } // 持续读取位置，确认到达目标点容差范围 Stopwatch sw = Stopwatch.StartNew(); while (sw.ElapsedMilliseconds < timeoutMs) { Thread.Sleep(200); string posXml = _client.SendReceive(GetPosXml()); RobotPosition current = ParsePosition(posXml); if (Distance(current, target) < 0.5) { return true; } } return false; }运动控制的安全性怎么强调都不过分。我在项目里做这些保护：
- 下发运动指令前，上位机必须校验目标点是否在机器人的工作空间内。这个校验不用做太复杂，限定XYZ的范围就行，防止坐标写错让机器人撞到夹具或者自身。
- 设置运动超时。如果下发指令很久没收到
DONE，上位机要能主动发STOP_MOVE并报警。 - 手动模式下不允许上位机下发运动指令。这个限制可以直接读KUKA运行模式的系统变量，或者只在自动模式下开放运动控制按钮。
界面层也要配合状态机做交互控制：机器人运动中就禁用运动按钮，避免用户连续点击多次下发互相冲突。位置到达后恢复按钮可用，整个体验就顺了。
4. 联调踩坑实录与经验总结
4.1 常见问题排查手册
前后联调大概花了两天时间，踩了不少坑，整理了最容易遇到的问题。
| 现象 | 可能原因 | 解决方案 |
|---|---|---|
| 上位机连接KUKA超时 | IP/端口配置错误、机器人未运行EKI程序 | 逐一ping通网络，检查EthernetKRL.xml配置，确认KRL程序已启动 |
| 连接成功后收不到响应 | KRL程序里没调用EKI_Open，或指令名不匹配 | 检查KRL端Command判断条件与上位机发送的XML指令一致 |
| 响应XML解析异常 | 读取响应不完整、字节截断 | 用超时循环读或按约定的结束标记截取；打印收到的原始字符串定位问题 |
| KUKA返回的数据是0 | 变量名打错、EKI变量未映射 | 核对KRL里EKI_SetReal的变量名和C#解析的节点名完全一致 |
| 中文在日志里变成问号 | 编码不统一 | 统一使用UTF-8编码，KRL端只传输ASCII字符，日志中文单独处理 |
| 运动指令下发但机器人不动 | 模式不对、机器人处于报警状态或安全门打开 | 检查KUKA是否处于自动模式，清报警复位，确认安全门信号正常 |
| 位置数据偶尔卡顿跳变 | 网络抖动或者刷新周期太快 | 适当降低请求频率，或改用KUKA主动推送模式 |
4.2 几条实操心得
做这个项目最大的体会是：TCP通讯本身不算难，难的是通讯之外的工程问题。
第一，编码问题。KRL端处理字符时对非ASCII字符的支持有限，所以我在KRL程序里只用英文字符做指令和状态码。上位机日志如果需要中文，就在C#端做映射，比如收到Result=OK就翻译成“运动完成”，别指望KRL直接返回中文给你，省了那一步跨语言编码的坑。
第二，日志记录要详细。上位机联调阶段，每一步的发送内容和接收响应都记录下来，排查问题的时候才知道是发出去错了、还是KUKA没正确解析、还是响应解析环节出错。没有日志，盲猜会浪费大量时间。
第三，一个很实用的小技巧：断线重连机制。产线上偶尔有网络闪断或者KUKA控制器复位的情况，TCP连接就断了。上位机要有自动重连功能，别让操作工每次都要重启软件。我一般用后台线程每隔2秒检查一次连接状态，发现断开就尝试重连，重连成功后自动恢复到位置监控状态。这个设计被现场操作工夸了很多次，真的省心。
第四，有关运动控制的边界情况。实际测试中我发现PTP运动到达目标点后，$POS_ACT到达的值和指令值之间多少会有一点偏差，这是正常的。所以在判定“到位”的逻辑里，加了0.5毫米的容差阈值，避免因为微小偏差而误判运动未完成。
最后说一句，上位机控制机器人一定要留手动干预的入口。界面无论如何都要有一键停止的按钮，不管什么情况下都能发STOP_MOVE。听起来是个很傻的要求，但真到了现场机器人跑飞或者撞工具的时候，这个按钮就是保命的。我的界面上这个按钮永远是红色、永远可以点、永远不需要任何确认弹窗，因为紧急情况下多一次点击确认可能就来不及了。
本文还有配套的精品资源，点击获取
