簡(jiǎn)介本資源是一套基于C#開發(fā)的工業(yè)級(jí)上位機(jī)控制系統(tǒng)實(shí)現(xiàn)方案面向自動(dòng)化工程師、機(jī)器人集成開發(fā)者及高校機(jī)電/自動(dòng)化專業(yè)高年級(jí)學(xué)生解決庫卡KUKA機(jī)器人與PC端通過TCP協(xié)議進(jìn)行實(shí)時(shí)位置回傳與運(yùn)動(dòng)控制的核心通信問題。壓縮包共39個(gè)文件涵蓋5個(gè)核心C#源碼文件含F(xiàn)orm1.cs、KUKA_Motion.csproj等、4個(gè)說明類txt文件含readme.txt操作指南與a.txt運(yùn)行日志、2個(gè)PDF技術(shù)文檔KSS系統(tǒng)軟件與Ethernet_KRL通信協(xié)議、2個(gè)可執(zhí)行exe程序及配套resx資源、pdb調(diào)試符號(hào)、xml配置與src運(yùn)動(dòng)腳本等整體大小18.59MB。已有294人學(xué)習(xí)下載。資源完整呈現(xiàn)“PC端TCP客戶端KUKA端KRL服務(wù)響應(yīng)”的雙向通信架構(gòu)提供可直接編譯運(yùn)行的VS解決方案.sln、結(jié)構(gòu)化數(shù)據(jù)包定義、校驗(yàn)機(jī)制實(shí)現(xiàn)、位置解析邏輯及KUKA端motion16腳本部署示例特別適合理解工業(yè)現(xiàn)場(chǎng)中機(jī)器人API對(duì)接、協(xié)議封裝與實(shí)時(shí)性保障等關(guān)鍵實(shí)踐環(huán)節(jié)。 做工業(yè)自動(dòng)化的兄弟們應(yīng)該經(jīng)常碰到這類需求產(chǎn)線旁邊立著一臺(tái)KUKA機(jī)器人示教器和本體調(diào)試都做完了但工藝節(jié)拍要求在上位機(jī)界面上實(shí)時(shí)看到機(jī)器人當(dāng)前的XYZ坐標(biāo)和角度姿態(tài)最好還能遠(yuǎn)程下發(fā)一個(gè)點(diǎn)讓機(jī)器人自己走過去。最順手的路子就是搞一臺(tái)工控機(jī)用C#寫個(gè)上位機(jī)跟機(jī)器人控制器通過TCP通信把位置數(shù)據(jù)拉回來、把運(yùn)動(dòng)指令發(fā)下去。這個(gè)項(xiàng)目名字聽著挺直白真正落地才發(fā)現(xiàn)協(xié)議設(shè)計(jì)、KRL編寫、連接穩(wěn)定性、坐標(biāo)系約定每個(gè)環(huán)節(jié)都有不少坑。我前幾天剛把一個(gè)類似的項(xiàng)目完整跑通從C#上位機(jī)到KUKA KRC4控制器來回調(diào)試了一個(gè)多星期今天把整套方案從頭到尾捋一遍給準(zhǔn)備上手的兄弟一份可以直接照著干的完整參考。1. 項(xiàng)目概述與整體方案選型1.1 需求分析為什么要在C#上位機(jī)上讀KUKA位置并控制運(yùn)動(dòng)這類需求通常出現(xiàn)在三種場(chǎng)景里。一是自動(dòng)化產(chǎn)線的集中監(jiān)控現(xiàn)場(chǎng)有好幾臺(tái)機(jī)器人各自有獨(dú)立示教器和控制器但中控室需要一塊大屏幕實(shí)時(shí)顯示每臺(tái)機(jī)器人的當(dāng)前位置方便工藝員隨時(shí)掌握設(shè)備狀態(tài)。二是和視覺系統(tǒng)聯(lián)動(dòng)相機(jī)拍照之后算出工件的偏移量上位機(jī)把補(bǔ)償后的目標(biāo)點(diǎn)發(fā)給機(jī)器人讓機(jī)器人自動(dòng)抓取或者定位這種場(chǎng)合對(duì)位置下發(fā)的實(shí)時(shí)性和準(zhǔn)確性要求很高。三是做數(shù)據(jù)追溯和質(zhì)量跟蹤機(jī)器人每走完一個(gè)工位上位機(jī)需要記錄當(dāng)時(shí)的實(shí)際到達(dá)位置把這些數(shù)據(jù)存進(jìn)MES系統(tǒng)。這個(gè)項(xiàng)目要解決的就是把機(jī)器人的內(nèi)部坐標(biāo)數(shù)據(jù)通過工業(yè)以太網(wǎng)端口傳出來同時(shí)把上位機(jī)的控制指令傳進(jìn)去。聽起來不難但KUKA機(jī)器人控制器默認(rèn)不會(huì)隨便把內(nèi)部坐標(biāo)暴露給外部設(shè)備需要借助KUKA自家的通信功能在KRL程序里做拆包、解析、執(zhí)行、回包這一整套動(dòng)作。換句話說通信的技術(shù)棧是TCP/IP但真正難的不是TCP本身而是兩端之間的“約定”和“配合”。適合看這篇文章的是有一定C#基礎(chǔ)、又想往工業(yè)上位機(jī)方向走的開發(fā)以及現(xiàn)場(chǎng)搞機(jī)器人的電氣和調(diào)試人員。如果你是純C#后端出身對(duì)機(jī)器人控制不太熟也沒關(guān)系我會(huì)把這里面的坐標(biāo)系統(tǒng)、KRL程序框架、WorkVisual配置一并講清楚你照著做也能跑通。1.2 為什么選TCP通信而不是其他方式KUKA機(jī)器人對(duì)外通信的常見方案大概有三種OPC UA、TCP/IP私有協(xié)議、以及基于I/O硬接線的數(shù)字量模擬量。這里我選了TCP核心原因是它在這個(gè)場(chǎng)景里平衡了實(shí)時(shí)性、靈活性和開發(fā)成本。先說OPC UA。它是現(xiàn)在工業(yè)互聯(lián)的熱門方案KRC4也支持好處是數(shù)據(jù)模型統(tǒng)一、跨平臺(tái)、安全機(jī)制完善適合設(shè)備接入MES或者SCADA系統(tǒng)。但它有個(gè)我這次很頭疼的問題配置相對(duì)重。需要在WorkVisual里做地址空間映射上位機(jī)還要引OPC UA客戶端庫對(duì)只想快速拉一個(gè)坐標(biāo)點(diǎn)回來的項(xiàng)目來說多少有點(diǎn)殺雞用牛刀。而且OPC UA做位置實(shí)時(shí)刷新雖然可以但要做到毫秒級(jí)輪詢還得處理訂閱模型代碼復(fù)雜度一下就上去了。再說I/O硬接線。用數(shù)字量輸出給機(jī)器人一個(gè)“請(qǐng)求”信號(hào)機(jī)器人把位置通過串口或者Profibus送回PLC再由PLC轉(zhuǎn)給上位機(jī)。這種方案很多老產(chǎn)線在用響應(yīng)速度可以做到非常穩(wěn)定但靈活性太差。你想改變速度、改目標(biāo)點(diǎn)、切工具坐標(biāo)系都得加信號(hào)定義邏輯寫起來相當(dāng)痛苦。對(duì)于“要發(fā)坐標(biāo)點(diǎn)讓機(jī)器人走一個(gè)任意位置”這種需求硬接線基本不現(xiàn)實(shí)。TCP方案的好處在于它走的是一根網(wǎng)線數(shù)據(jù)報(bào)文隨便定義想傳位置就傳位置想傳速度就傳速度想擴(kuò)展命令直接加個(gè)字段就行。KUKA機(jī)器人自帶的EthernetKRL功能本質(zhì)就是給外部設(shè)備預(yù)留了一個(gè)TCP/IP的XML通信通道天生適合干這件事。而且C#這邊寫TCP客戶端簡(jiǎn)直不要太順手TcpClient一兩行代碼就能連上Unity、WPF、WinForms都能無縫集成。缺點(diǎn)是協(xié)議需要自己定義沒有OPC UA那種“開箱即用”的標(biāo)準(zhǔn)語義但這恰好給了我們最大的自由度也正好是今天這篇文章要重點(diǎn)講的。1.3 整體架構(gòu)與數(shù)據(jù)流我先畫一下這個(gè)項(xiàng)目的通信架構(gòu)大家腦子里先有個(gè)圖。上位機(jī)是一臺(tái)普通工控機(jī)裝Windows系統(tǒng)和我們的C#程序通過網(wǎng)線直連或者經(jīng)過交換機(jī)接到KUKA機(jī)器人控制柜的網(wǎng)口上。KRC4控制器內(nèi)部跑著一個(gè)KRL主程序這個(gè)主程序通過EthernetKRL功能模塊建立一個(gè)TCP服務(wù)端一直監(jiān)聽上位機(jī)發(fā)過來的連接。整個(gè)數(shù)據(jù)流是這樣的上位機(jī)用C#的TcpClient連接到機(jī)器人控制器的某個(gè)端口連接建立后上位機(jī)主動(dòng)發(fā)一段XML格式的請(qǐng)求文本比如請(qǐng)求當(dāng)前坐標(biāo)或者下發(fā)目標(biāo)點(diǎn)機(jī)器人端的KRL程序收到這段XML解析出命令類型和參數(shù)然后執(zhí)行對(duì)應(yīng)的操作如果請(qǐng)求的是位置KRL程序就把當(dāng)前機(jī)器人的實(shí)際坐標(biāo)拼成一段XML文本通過TCP返回給上位機(jī)如果請(qǐng)求的是運(yùn)動(dòng)KRL程序就把目標(biāo)點(diǎn)寫入運(yùn)動(dòng)指令觸發(fā)機(jī)器人移動(dòng)同時(shí)周期性地把運(yùn)動(dòng)過程中的實(shí)時(shí)位置推回給上位機(jī)。這里有個(gè)關(guān)鍵點(diǎn)到底誰是服務(wù)端、誰是客戶端。KUKA的EthernetKRL支持兩種模式一種是機(jī)器人當(dāng)TCP服務(wù)端外部設(shè)備來連接它另一種是機(jī)器人當(dāng)TCP客戶端主動(dòng)去連接外部設(shè)備開放的端口。我這次用的是“機(jī)器人做服務(wù)端上位機(jī)做客戶端”的模式理由很簡(jiǎn)單上位機(jī)程序可以隨時(shí)重連機(jī)器人斷開后能自動(dòng)恢復(fù)連接而且上位機(jī)作為主動(dòng)發(fā)起方容易集中管理多臺(tái)機(jī)器人的連接。你要反過來做也行但現(xiàn)場(chǎng)如果有多臺(tái)上位機(jī)同時(shí)要連機(jī)器人服務(wù)端模式會(huì)更有優(yōu)勢(shì)。2. 通信協(xié)議與數(shù)據(jù)格式設(shè)計(jì)2.1 KUKA側(cè)的EthernetKRLXML機(jī)制這里得先把KUKA的EthernetKRL講講清楚不然很多兄弟會(huì)卡在“KRL程序里怎么收發(fā)字符串”這一步。EthernetKRL是KUKA控制器里的一個(gè)通信擴(kuò)展它的核心思路是在控制器上創(chuàng)建一個(gè)TCP通道通道收到外部發(fā)來的字符串后把字符串放到KRL變量里KRL程序可以用專門的函數(shù)把這段字符串取出來解析反過來KRL程序也可以把一段字符串通過這個(gè)通道發(fā)回給外部設(shè)備。它和直接在KRL里寫socket不太一樣。EthernetKRL把底層的TCP連接管理、粘包拆包、字符串緩沖這些臟活全部封裝好了KRL開發(fā)人員只需要管業(yè)務(wù)邏輯從某個(gè)通道里拿字符串、解析、處理、回傳。正因?yàn)檫@樣它對(duì)KRL編程水平的要求并沒有想象中那么高。你只需要在WorkVisual里配置好通道參數(shù)然后在KRL代碼里調(diào)用EthernetKRL提供的函數(shù)就行了。EthernetKRL的配置信息通常集中在一個(gè)XML文件里里面定義了通道名、IP地址、端口、發(fā)送接收緩沖區(qū)大小這些參數(shù)。這個(gè)文件的具體路徑和格式KUKA不同版本略有區(qū)別但邏輯都一樣通道名是你在KRL代碼里引用這個(gè)通信連接時(shí)的標(biāo)識(shí)符IP和端口決定了對(duì)端怎么找到這個(gè)通道。我在C#這一端設(shè)計(jì)協(xié)議的時(shí)候刻意讓報(bào)文格式和EthernetKRL的XML風(fēng)格保持一致。這樣做的好處是KRL那邊解析時(shí)可以直接用EthernetKRL自帶的XML取值函數(shù)不需要手寫字符串截取。兩個(gè)端都基于XML排查問題的時(shí)候用網(wǎng)絡(luò)調(diào)試助手一看報(bào)文清清楚楚。2.2 自定義消息格式與命令集兩個(gè)端要對(duì)話首先得有語言。我定義的請(qǐng)求報(bào)文長(zhǎng)這樣Command TypeGetPose/Type /Command這是最簡(jiǎn)單的取位置請(qǐng)求上位機(jī)發(fā)給機(jī)器人機(jī)器人收到后返回當(dāng)前位置。如果是運(yùn)動(dòng)控制報(bào)文長(zhǎng)這樣Command TypeMoveTo/Type Coordinate X520.00/X Y30.50/Y Z680.20/Z A0.00/A B0.00/B C45.00/C /Coordinate MotionPTP/Motion Speed50/Speed /Command對(duì)應(yīng)地機(jī)器人返回位置報(bào)文如下Response ResultOK/Result Pose X519.87/X Y30.42/Y Z680.15/Z A0.02/A B-0.01/B C45.03/C /Pose StateRunning/State /Response這套協(xié)議我做了兩件事。第一用Type字段區(qū)分命令類型目前定義了GetPose、MoveTo、SetSpeed、Stop、Home這幾類。第二所有數(shù)值統(tǒng)一用字符串表示不涉及二進(jìn)制浮點(diǎn)字節(jié)序的坑。在KRL那邊解析時(shí)直接取節(jié)點(diǎn)里的文本再轉(zhuǎn)成REALC#這邊用XDocument解析XML節(jié)點(diǎn)效率足夠而且出問題能一眼看出格式錯(cuò)在哪。協(xié)議設(shè)計(jì)時(shí)我特意留了State字段用來返回機(jī)器人的當(dāng)前狀態(tài)比如Idle空閑、Running運(yùn)行中、Error報(bào)警。這個(gè)字段很實(shí)用上位機(jī)可以據(jù)此判斷當(dāng)前是否能接受新的運(yùn)動(dòng)指令避免在機(jī)器人還在運(yùn)動(dòng)過程中就下發(fā)下一個(gè)點(diǎn)造成指令沖突。2.3 坐標(biāo)系統(tǒng)與實(shí)時(shí)性指標(biāo)拿到X、Y、Z、A、B、C這六個(gè)值之前得先搞明白它們是什么坐標(biāo)系下的。KUKA機(jī)器人默認(rèn)返回的是工具坐標(biāo)系TCP在基坐標(biāo)系下的位置和姿態(tài)X、Y、Z是毫米單位的平移量A、B、C是用歐拉角表示的旋轉(zhuǎn)量單位是度。在實(shí)際項(xiàng)目里上位機(jī)顯示給操作員看的通常就是機(jī)器人控制器上示教器顯示的當(dāng)前值這樣才能讓工人和技術(shù)員對(duì)照核實(shí)。實(shí)時(shí)性方面機(jī)械臂的位置返回不可能像PLC的模擬量采樣那么快。KRC4的控制周期一般在12ms左右但EthernetKRL的XML處理走的是后臺(tái)解釋器涉及字符串的序列化和反序列化實(shí)際能穩(wěn)定做到的輪詢周期大約在50ms到200ms之間。我做的是100ms輪詢一次也就是一秒十次對(duì)于監(jiān)控顯示和視覺引導(dǎo)來說完全夠用。如果你追求更快的反饋可以考慮減少XML節(jié)點(diǎn)數(shù)量、精簡(jiǎn)屬性名或者改用更緊湊的私有協(xié)議但KRL解析側(cè)的壓力會(huì)增加性價(jià)比得掂量一下。還有個(gè)容易搞混的點(diǎn)機(jī)器人執(zhí)行運(yùn)動(dòng)指令時(shí)位置反饋是動(dòng)態(tài)變化的你的報(bào)文里返回的是哪個(gè)時(shí)刻的位置KUKA返回的是讀取時(shí)刻的實(shí)際軸位置換算出的TCP坐標(biāo)不確定的具體時(shí)間戳沒有所以你在上位機(jī)里看到的值嚴(yán)格來說是“KRL讀取那一刻”的坐標(biāo)中間隔了網(wǎng)絡(luò)傳輸延遲和解析延遲。對(duì)于絕大多數(shù)監(jiān)控場(chǎng)景這個(gè)誤差完全可接受但如果你要做高精度的同步記錄建議在KRL側(cè)同時(shí)把系統(tǒng)時(shí)間也拼進(jìn)響應(yīng)報(bào)文存到數(shù)據(jù)庫時(shí)作為參考。3. C#上位機(jī)核心實(shí)現(xiàn)3.1 TCP通信模塊的封裝C#上位機(jī)的核心就是TCP通信。我封裝了一個(gè)KukaTcpClient類負(fù)責(zé)連接管理、消息發(fā)送、接收循環(huán)和事件回調(diào)這樣界面層只關(guān)心收數(shù)據(jù)和發(fā)命令不用去碰socket的底層細(xì)節(jié)。先看連接代碼public class KukaTcpClient { private TcpClient _client; private NetworkStream _stream; private CancellationTokenSource _cts; private readonly object _sendLock new object(); public event Actionstring DataReceived; public event Actionbool ConnectionChanged; public async Task ConnectAsync(string ip, int port) { try { _client new TcpClient(); _client.NoDelay true; await _client.ConnectAsync(ip, port); _stream _client.GetStream(); _cts new CancellationTokenSource(); _ Task.Run(() ReceiveLoopAsync(_cts.Token)); ConnectionChanged?.Invoke(true); } catch (Exception ex) { ConnectionChanged?.Invoke(false); throw new Exception($連接KUKA控制器失敗: {ex.Message}); } } }這里有個(gè)小細(xì)節(jié)我在實(shí)際項(xiàng)目里反復(fù)吃過虧TcpClient.NoDelay一定要設(shè)為true關(guān)閉TCP的Nagle算法。Nagle算法默認(rèn)會(huì)把小數(shù)據(jù)包合并成大包再發(fā)送減少網(wǎng)絡(luò)報(bào)文數(shù)量。本來這是好事但在我們的上位機(jī)場(chǎng)景里100ms就往返一次XML報(bào)文每次報(bào)文本身也就幾百字節(jié)Nagle算法會(huì)導(dǎo)致一條指令遲遲發(fā)不出去等湊滿一個(gè)TCP段才發(fā)送實(shí)時(shí)性和響應(yīng)速度都受影響。把NoDelay打開之后報(bào)文即發(fā)即走實(shí)測(cè)下來延遲明顯降低。接收循環(huán)我用了ReadAsync配合MemoryStream做數(shù)據(jù)緩沖。因?yàn)門CP是流式協(xié)議你發(fā)給對(duì)端的一段字符串對(duì)端接收時(shí)可能一次收到半段、也可能一次收到好幾段這就是經(jīng)典的“粘包/拆包”問題。我的處理方案是做應(yīng)用層分包所有報(bào)文以換行符\n結(jié)尾接收循環(huán)讀到換行符才認(rèn)為一個(gè)完整報(bào)文結(jié)束然后觸發(fā)事件。private async Task ReceiveLoopAsync(CancellationToken token) { var buffer new byte[4096]; var streamBuffer new MemoryStream(); while (!token.IsCancellationRequested) { try { int bytesRead await _stream.ReadAsync(buffer, 0, buffer.Length, token); if (bytesRead 0) { // 對(duì)端關(guān)閉連接觸發(fā)斷開邏輯 ConnectionChanged?.Invoke(false); break; } streamBuffer.Write(buffer, 0, bytesRead); streamBuffer.Position 0; var reader new StreamReader(streamBuffer, Encoding.UTF8, true); while (true) { var line reader.ReadLine(); if (line null) break; DataReceived?.Invoke(line); } var remain streamBuffer.Length - streamBuffer.Position; var rest new byte[remain]; streamBuffer.Read(rest, 0, rest.Length); streamBuffer.Dispose(); streamBuffer new MemoryStream(rest.Length 0 ? rest : null); } catch (Exception ex) { ConnectionChanged?.Invoke(false); break; } } }寫發(fā)送方法時(shí)我加了個(gè)簡(jiǎn)單鎖防止多個(gè)業(yè)務(wù)線程同時(shí)向同一個(gè)NetworkStream寫數(shù)據(jù)導(dǎo)致報(bào)文交錯(cuò)。public void Send(string xmlString) { if (_stream null || !_client.Connected) return; lock (_sendLock) { var data Encoding.UTF8.GetBytes(xmlString \n); _stream.Write(data, 0, data.Length); _stream.Flush(); } }這套封裝調(diào)通之后上位機(jī)的其他模塊都可以通過Send發(fā)送數(shù)據(jù)通過DataReceived事件接收機(jī)器人返回的報(bào)文。連接成功后我還會(huì)單獨(dú)起一個(gè)心跳任務(wù)每2秒發(fā)一條CommandTypeGetPose/Type/Command如果連續(xù)幾次沒有響應(yīng)就判定連接異常觸發(fā)重連。這個(gè)心跳在調(diào)試階段幫了大忙機(jī)器人那邊程序一崩、或者網(wǎng)線松動(dòng)上位機(jī)馬上就能覺察到。3.2 消息收發(fā)與XML解析有了TCP收發(fā)模塊下一步就是把收到的XML字符串解析成機(jī)器人狀態(tài)數(shù)據(jù)。C#里解析XML有很多方式我選了XDocument理由是這個(gè)項(xiàng)目的報(bào)文結(jié)構(gòu)穩(wěn)定、節(jié)點(diǎn)層級(jí)不深用Linq操作最直觀代碼短、可讀性好。public RobotPose ParseResponse(string xmlText) { var doc XDocument.Parse(xmlText); var root doc.Root; var poseNode root.Element(Pose); if (poseNode null) return null; return new RobotPose { X double.Parse(poseNode.Element(X).Value), Y double.Parse(poseNode.Element(Y).Value), Z double.Parse(poseNode.Element(Z).Value), A double.Parse(poseNode.Element(A).Value), B double.Parse(poseNode.Element(B).Value), C double.Parse(poseNode.Element(C).Value) }; }解析邏輯本身不難但實(shí)際聯(lián)調(diào)時(shí)我遇到一個(gè)容易忽略的坑KRL返回的數(shù)值可能帶著科學(xué)計(jì)數(shù)法比如某個(gè)軸角度存儲(chǔ)格式是1.200000012E02。C#的double.Parse默認(rèn)能識(shí)別這種格式所以沒問題。但如果你的項(xiàng)目里用float.Parse并且沒有指定CultureInfo.InvariantCulture在中文Windows系統(tǒng)上字符串里的小數(shù)點(diǎn)會(huì)被當(dāng)成逗號(hào)處理解析直接拋異常。這個(gè)坑很隱蔽我后來統(tǒng)一在解析入口處加了CultureInfo.InvariantCulture一勞永逸。另外機(jī)器人在運(yùn)動(dòng)過程中返回的位置值多多少少會(huì)有抖動(dòng)特別是軌跡插補(bǔ)過程中某幾個(gè)軸的微小震動(dòng)反映到笛卡爾坐標(biāo)上可能表現(xiàn)為最后一位小數(shù)跳來跳去。如果上位機(jī)界面直連顯示這個(gè)原始值操作員看久了會(huì)覺得系統(tǒng)不穩(wěn)定。我在顯示層加了一個(gè)滑動(dòng)窗口濾波取最近五次采樣值的平均值再顯示。注意是只在顯示層做平滑原始數(shù)據(jù)要原封不動(dòng)地留給日志和后續(xù)算法避免把真實(shí)數(shù)據(jù)搞臟。3.3 界面實(shí)時(shí)刷新與跨線程處理我這次用的WPF因?yàn)閃PF的數(shù)據(jù)綁定機(jī)制在更新高頻監(jiān)控界面時(shí)比WinForms舒服很多。搞了一個(gè)PoseViewModel實(shí)現(xiàn)了INotifyPropertyChanged界面上直接綁定X、Y、Z等屬性?？缇€程更新UI是所有上位機(jī)開發(fā)都會(huì)遇到的老大難。TCP接收線程里解析完數(shù)據(jù)不能直接給界面上的Label賦值否則會(huì)拋“調(diào)用線程無法訪問此對(duì)象”的異常。我在接收事件里用了Dispatcher.BeginInvoke把數(shù)據(jù)更新操作切回UI線程。DataReceived (xml) { var pose ParseResponse(xml); if (pose null) return; Application.Current.Dispatcher.BeginInvoke(new Action(() { _viewModel.X pose.X; _viewModel.Y pose.Y; _viewModel.Z pose.Z; _viewModel.A pose.A; _viewModel.B pose.B; _viewModel.C pose.C; })); };100ms刷新一次UI線程的負(fù)載其實(shí)很低即使加上日志顯示和狀態(tài)圖標(biāo)更新也幾乎感覺不到卡頓。但如果以后要同時(shí)監(jiān)控四臺(tái)機(jī)器人每臺(tái)100ms就是每秒40次UI更新這時(shí)候最好把Dispatcher的優(yōu)先級(jí)調(diào)整一下并且把數(shù)據(jù)先打包成對(duì)象再一次性更新避免屬性一個(gè)個(gè)刷造成的布局抖動(dòng)。界面上我還做了運(yùn)動(dòng)控制區(qū)域輸入目標(biāo)點(diǎn)和速度之后點(diǎn)擊“移動(dòng)”按鈕。按鈕點(diǎn)擊事件里把文本框內(nèi)容組裝成XML命令調(diào)用Send發(fā)出去。發(fā)送完之后我會(huì)在狀態(tài)欄顯示“指令已下發(fā)等待機(jī)器人到達(dá)”同時(shí)用上面說的位置數(shù)據(jù)判斷機(jī)器人是否到位。到位判定的邏輯是連續(xù)十次采樣位置與目標(biāo)點(diǎn)的距離差都小于1毫米認(rèn)為到位狀態(tài)欄變成“已到達(dá)”。這個(gè)邏輯雖然樸素但在實(shí)際項(xiàng)目里很可靠。3.4 運(yùn)動(dòng)控制指令的實(shí)現(xiàn)細(xì)節(jié)運(yùn)動(dòng)指令的下發(fā)是上位機(jī)最敏感的功能因?yàn)橐粋€(gè)錯(cuò)誤的坐標(biāo)值可能讓機(jī)器人直接超限報(bào)警嚴(yán)重的還會(huì)撞周邊設(shè)備。我這邊把指令封裝成方法做了三層防護(hù)。第一層是參數(shù)校驗(yàn)。X、Y、Z的值必須落在機(jī)器人工作空間范圍內(nèi)我是直接在C#代碼里寫死了邊界值比如X最小200、最大1200這種。A、B、C的角度范圍是正負(fù)180度超出就彈窗提示。速度參數(shù)強(qiáng)制限制在0到100之間防止誤填200這樣的非法值。第二層是狀態(tài)校驗(yàn)。發(fā)指令之前先檢查最后一次返回的State字段如果是Error或者Running就不允許下發(fā)新指令提示操作員等機(jī)器人空閑或先復(fù)位報(bào)警。第三層是確認(rèn)機(jī)制。機(jī)器人端收到MoveTo指令并執(zhí)行到位后會(huì)返回一個(gè)Result字段為OK的響應(yīng)。上位機(jī)只有在收到這個(gè)確認(rèn)后才認(rèn)定指令真正執(zhí)行完成否則報(bào)超時(shí)。避免機(jī)器人還沒執(zhí)行上位機(jī)就顯示“成功”的假象。public bool MoveTo(double x, double y, double z, double a, double b, double c, int speed, int timeoutMs 5000) { var cmd $CommandTypeMoveTo/Type Coordinate X{x.ToString(F2, CultureInfo.InvariantCulture)}/X Y{y.ToString(F2, CultureInfo.InvariantCulture)}/Y Z{z.ToString(F2, CultureInfo.InvariantCulture)}/Z A{a.ToString(F2, CultureInfo.InvariantCulture)}/A B{b.ToString(F2, CultureInfo.InvariantCulture)}/B C{c.ToString(F2, CultureInfo.InvariantCulture)}/C /Coordinate MotionPTP/Motion Speed{speed}/Speed/Command; Send(cmd); // 等待確認(rèn)事件超時(shí)拋出異常 if (!_ackSemaphore.Wait(timeoutMs)) throw new TimeoutException(機(jī)器人端未返回確認(rèn)信號(hào)); return _lastAck; }這里用了一個(gè)SemaphoreSlim作為確認(rèn)信號(hào)收到機(jī)器人的響應(yīng)后在事件處理里釋放。實(shí)際項(xiàng)目中這個(gè)等待超時(shí)的機(jī)制幫了大忙機(jī)器人程序萬一卡死上位機(jī)不會(huì)無限期等下去。4. KUKA機(jī)器人端配置與KRL編程4.1 WorkVisual中EthernetKRL配置C#這邊代碼寫得再漂亮機(jī)器人端沒配好一切都是白搭。KUKA端的第一步是在WorkVisual里配置EthernetKRL通道。具體菜單不同版本的WorkVisual會(huì)有點(diǎn)差異但大致邏輯是在機(jī)器人項(xiàng)目的樹形結(jié)構(gòu)下找到和“EthernetKRL”相關(guān)的配置項(xiàng)添加一個(gè)新通道填寫通道名稱、IP地址、端口號(hào)并選擇角色。我這次配置的通道名稱叫KrcChannelIP地址填寫的是KRC4控制器上網(wǎng)絡(luò)端口的IP端口用的5010角色選的是“Server”也就是服務(wù)端模式。這里強(qiáng)烈建議端口號(hào)和通道名稱都固定下來寫到項(xiàng)目文檔里后續(xù)維護(hù)的人不用靠猜。配置完之后WorkVisual會(huì)生成對(duì)應(yīng)的XML配置文件。這份文件在控制器上的具體路徑一般位于C:\KRC\ROBOTER\Config\User\Common\EthernetKRL\下。你不一定需要手動(dòng)編輯它很多時(shí)候通過WorkVisual界面配置就足夠了。但了解這個(gè)路徑很有用因?yàn)楝F(xiàn)場(chǎng)如果改了網(wǎng)段需要直接確認(rèn)這份配置文件里的IP和端口是不是對(duì)的。配置完通道后要把項(xiàng)目部署到控制器上重新激活或者熱啟動(dòng)。這個(gè)步驟順序挺重要我一開始沒注意在WorkVisual里配置好了但沒激活結(jié)果KRL程序一初始化就報(bào)“通道不存在”。后來才反應(yīng)過來配置文件和KRL代碼是兩套東西部署激活之后新配置才會(huì)生效。4.2 KRL側(cè)的消息處理主循環(huán)機(jī)器人端的KRL程序是整個(gè)系統(tǒng)能轉(zhuǎn)起來的另一半。核心邏輯就是一個(gè)循環(huán)等待EthernetKRL通道收到報(bào)文解析命令執(zhí)行響應(yīng)動(dòng)作返回結(jié)果。我用KRL寫了一個(gè)簡(jiǎn)化的主循環(huán)框架大致結(jié)構(gòu)如下DEF KRC_TCP_MAIN() DECL EKI_STATUS RET DECL CHAR REQ_CHAR[1024] DECL CHAR RESP_CHAR[1024] ; 打開EthernetKRL通道 EKI_INIT(hKRL, KrcChannel) LOOP ; 等待并讀取上位機(jī)發(fā)來的請(qǐng)求 RET EKI_GET_STRING(hKRL, REQUEST, REQ_CHAR[]) IF RET.EKI_OK THEN ; 解析請(qǐng)求內(nèi)容 ; 判斷命令類型 ; 如果命令是獲取位置 ; 讀取當(dāng)前TCP坐標(biāo)XP, YP, ZP, AP, BP, CP ; 拼裝響應(yīng)XML字符串 ; EKI_SET_STRING(hKRL, RESPONSE, RESP_CHAR[]) ENDIF WAIT SEC 0.02 ENDLOOP END上面的代碼是示意真實(shí)EthernetKRL函數(shù)的簽名和數(shù)據(jù)類型在不同KRC版本上會(huì)有差異大家以你手上的KRL手冊(cè)為準(zhǔn)。我要強(qiáng)調(diào)的是這個(gè)20毫秒的等待時(shí)間。最開始我寫了個(gè)空轉(zhuǎn)死循環(huán)結(jié)果后臺(tái)解釋器負(fù)載居高不下機(jī)器人看起來卡卡的。加了個(gè)WAIT SEC 0.02之后掃描周期穩(wěn)定在50ms附近機(jī)器人本體的運(yùn)動(dòng)調(diào)度幾乎不受影響。在KRL里解析XML最土的辦法是用字符串函數(shù)手動(dòng)截取標(biāo)簽之間的內(nèi)容。比如取X坐標(biāo); 找到 X 和 /X 之間的字符串 pos1 FIND(REQ_CHAR[], X) pos2 FIND(REQ_CHAR[], /X) SUBSTR(REQ_CHAR[], pos1 3, pos2 - pos1 - 3, tmpStr) X_TARGET VAL(tmpStr[] , 0)這個(gè)辦法看著不優(yōu)雅但兼容性最好不依賴控制器上的XML庫。如果你用了EthernetKRL自帶的XML工具函數(shù)代碼會(huì)簡(jiǎn)潔不少但那需要額外的配置和依賴現(xiàn)場(chǎng)環(huán)境不一定支持。我圖穩(wěn)就用了手寫解析。真正的MoveTo指令處理KRL這段會(huì)讓很多不常寫機(jī)器人程序的兄弟困惑KRL里怎么接受外部傳進(jìn)來的坐標(biāo)點(diǎn)答案是通過全局變量。KRL程序里定義一個(gè)全局位置變量GLOBAL X_TARGET_POS收到上位機(jī)的坐標(biāo)后給這個(gè)變量賦值然后置位一個(gè)全局標(biāo)志位GLOBAL G_MOVE_REQ。主循環(huán)里檢測(cè)到這個(gè)標(biāo)志位就調(diào)用PTP或者SLIN指令往目標(biāo)點(diǎn)移動(dòng)IF G_MOVE_REQ THEN ; 構(gòu)造目標(biāo)點(diǎn)類型的位置變量 E6POS TARGET_POS TARGET_POS.X X_TARGET TARGET_POS.Y Y_TARGET TARGET_POS.Z Z_TARGET TARGET_POS.A A_TARGET TARGET_POS.B B_TARGET TARGET_POS.C C_TARGET ; 以PTP方式運(yùn)動(dòng)速度百分比 PTP TARGET_POS C_VEL ; 運(yùn)動(dòng)完成后復(fù)位標(biāo)志位 G_MOVE_REQ FALSE ; 組裝置位完成的XML響應(yīng)并返回 ENDIF這里有幾個(gè)細(xì)節(jié)值得展開。第一PTP指令會(huì)把機(jī)器人從當(dāng)前點(diǎn)快速插補(bǔ)運(yùn)動(dòng)到目標(biāo)點(diǎn)與路徑形狀無關(guān)適合機(jī)器人從一個(gè)工位轉(zhuǎn)到另一個(gè)工位。如果你的應(yīng)用需要走直線或者圓弧就得改用LIN或者CIRC同時(shí)需要考慮姿態(tài)過渡和速度規(guī)劃代碼復(fù)雜度會(huì)再上一個(gè)臺(tái)階。第二速度C_VEL是KUKA的編程速度變量通常在程序頂部定義成百分比比如$VEL.CP 0.5代表50%的笛卡爾速度。機(jī)器人程序默認(rèn)是無限循環(huán)運(yùn)行的如果上位機(jī)一直下發(fā)點(diǎn)位機(jī)器人就會(huì)不停地執(zhí)行運(yùn)動(dòng)指令。4.3 安全互鎖與模式切換說完功能必須說安全。運(yùn)動(dòng)控制這個(gè)東西功能跑通不算完出了事就是大事。我這邊做了幾層保護(hù)效果還不錯(cuò)。第一機(jī)器人程序里判斷了當(dāng)前運(yùn)行模式。KUKA機(jī)器人有三種模式T1手動(dòng)低速模式、T2手動(dòng)高速模式、AUT自動(dòng)模式。只有在自動(dòng)模式下才允許響應(yīng)上位機(jī)的MoveTo指令。手動(dòng)模式下上位機(jī)彈出的運(yùn)動(dòng)指令一律忽略返回一個(gè)Error響應(yīng)。這樣能防止調(diào)試人員在機(jī)器人旁邊時(shí)上位機(jī)突然發(fā)出一個(gè)運(yùn)動(dòng)指令把人嚇一跳。第二安全距離判斷。KRL程序在收到MoveTo指令后先檢查目標(biāo)坐標(biāo)是否在預(yù)設(shè)的安全工作區(qū)范圍內(nèi)這里的上下限是一組全局變量可以在上位機(jī)界面上改。實(shí)際判斷就一行比較邏輯但如果目標(biāo)點(diǎn)出了安全區(qū)直接拒絕執(zhí)行并返回錯(cuò)誤信息。第三急停聯(lián)動(dòng)。急停按鈕的硬接線是獨(dú)立于上位機(jī)的機(jī)器人控制柜本身就有安全回路這點(diǎn)絕對(duì)不能省。上位機(jī)的軟件停止只是一個(gè)輔助功能當(dāng)上位機(jī)檢測(cè)到連接異常時(shí)向機(jī)器人發(fā)送Stop指令讓機(jī)器人暫停運(yùn)動(dòng)但真正的緊急斷電仍然必須依賴物理急停。關(guān)于模式切換還有一個(gè)實(shí)操經(jīng)驗(yàn)自動(dòng)模式下面機(jī)器人程序選到AUT后程序默認(rèn)是停止?fàn)顟B(tài)需要按一次“程序啟動(dòng)”按鈕讓程序跑起來上位機(jī)的指令才能真正被處理。我在現(xiàn)場(chǎng)第一次聯(lián)調(diào)時(shí)沒按這個(gè)按鈕上位機(jī)發(fā)了一堆指令過去石沉大海KRL那邊變量確實(shí)被改到了但程序沒進(jìn)循環(huán)執(zhí)行整個(gè)人懵了好幾分鐘。后來在程序里加了個(gè)人機(jī)交互的提示讓現(xiàn)場(chǎng)工人確認(rèn)自動(dòng)模式下已經(jīng)啟動(dòng)了程序問題才解決。5. 實(shí)測(cè)過程與調(diào)試經(jīng)驗(yàn)5.1 聯(lián)調(diào)前先把環(huán)境攔住做這個(gè)項(xiàng)目我最怕的就是一上來就把C#程序和機(jī)器人連在一起互相調(diào)試。雙方都有bug出了問題根本分不清是上位機(jī)發(fā)錯(cuò)了還是機(jī)器人端沒接住。因此我強(qiáng)烈建議分三步走先純軟件模擬、再分開聯(lián)調(diào)、最后真機(jī)聯(lián)動(dòng)。第一步用網(wǎng)絡(luò)調(diào)試助手開一個(gè)TCP Server模擬KUKA機(jī)器人。把C#程序連上這個(gè)模擬服務(wù)驗(yàn)證上位機(jī)的連接邏輯、心跳邏輯、發(fā)指令和解析響應(yīng)的流程。這段時(shí)間可以把XML協(xié)議的各種邊界情況都測(cè)一遍比如機(jī)器人返回?cái)?shù)據(jù)中間有空格、數(shù)字帶科學(xué)計(jì)數(shù)法、偶發(fā)一包收到兩條報(bào)文之類的情況都在模擬階段處理掉。第二步用KUKA官方或者第三方工具連一下真機(jī)確認(rèn)以太網(wǎng)物理鏈路通、EthernetKRL通道能夠正常建立連接、KRL程序確實(shí)把配置好的通道初始化了。我記得第一次連真機(jī)時(shí)用調(diào)試助手向機(jī)器人發(fā)了一條命令KRL那邊一點(diǎn)反應(yīng)都沒有。排查半天發(fā)現(xiàn)是控制柜后面網(wǎng)口插錯(cuò)了插到了編程口而不是以太網(wǎng)口物理層根本沒有通。第三步才輪到C#程序和機(jī)器人正式聯(lián)動(dòng)。這時(shí)候上位的代碼和KRL程序都已經(jīng)各自單測(cè)過問題范圍就小了很多。而且在正式跑運(yùn)動(dòng)指令之前先把速度百分比設(shè)到10%以下確認(rèn)機(jī)器人運(yùn)動(dòng)方向正確、坐標(biāo)系理解一致再逐步把速度提上去。這是做運(yùn)動(dòng)控制項(xiàng)目必須養(yǎng)成的習(xí)慣。5.2 真實(shí)聯(lián)調(diào)過程中踩過的坑聯(lián)調(diào)階段踩坑無數(shù)我挑典型的說幾個(gè)給兄弟們做參考。第一個(gè)坑是防火墻攔截。C#程序部署到Windows工控機(jī)上之后第一次連接機(jī)器人超時(shí)但同一臺(tái)機(jī)器上用TCP調(diào)試助手就能正常連接。排查了一下午才發(fā)現(xiàn)是Windows防火墻默認(rèn)擋了C#程序的入站連接而調(diào)試助手彈出了防火墻提示框被手快點(diǎn)掉了所以它沒被攔截。解決辦法是控制面板里放行程序或者直接關(guān)閉防火墻工控機(jī)在獨(dú)立局域網(wǎng)內(nèi)可以這么做。第二個(gè)坑是KRL程序在運(yùn)動(dòng)指令執(zhí)行期間會(huì)卡住后續(xù)的報(bào)文處理。PTP這種運(yùn)動(dòng)指令是阻塞式的KRL線程執(zhí)行到PTP會(huì)一直等到運(yùn)動(dòng)完成才繼續(xù)往下走。如果上位機(jī)在機(jī)器人運(yùn)動(dòng)過程中發(fā)一個(gè)GetPose請(qǐng)求KRL線程正卡在PTP指令里根本不會(huì)去讀EthernetKRL緩沖區(qū)的數(shù)據(jù)響應(yīng)自然就回不去。解決辦法是把位置讀取和運(yùn)動(dòng)執(zhí)行拆成兩個(gè)KRL進(jìn)程或者事件處理或者在上位機(jī)加一個(gè)超時(shí)重試機(jī)制。我簡(jiǎn)化了一點(diǎn)運(yùn)動(dòng)過程中GetPose數(shù)據(jù)由機(jī)器人端另外一個(gè)后臺(tái)任務(wù)返回主運(yùn)動(dòng)線程只處理MoveTo指令這樣兩件事不再搶同一條執(zhí)行通道。第三個(gè)坑是網(wǎng)絡(luò)抖動(dòng)導(dǎo)致字符串截?cái)?。TCP本身不會(huì)丟數(shù)據(jù)但網(wǎng)絡(luò)延遲高的時(shí)候C#接收循環(huán)可能一次只收到半個(gè)報(bào)文下一次事件才補(bǔ)齊后半段。我最初收到的報(bào)文解析失敗率特別高排查發(fā)現(xiàn)是接收循環(huán)里按“行”分割的邏輯沒有處理“最后一段不完整”的情況。后來改成上面貼的MemoryStream緩存方案讀一幀處理一幀直到讀到換行符才算一個(gè)完整報(bào)文這個(gè)坑才算徹底填平。第四個(gè)坑和KRL側(cè)字符串長(zhǎng)度有關(guān)。EthernetKRL通道的緩沖區(qū)是有上限的默認(rèn)配置下大概幾KB。正常情況下我們報(bào)文字節(jié)數(shù)很小但萬一操作員把備注信息塞進(jìn)報(bào)文里超過緩沖區(qū)長(zhǎng)度報(bào)文明明發(fā)出去了機(jī)器人卻收到一堆亂碼然后解析失敗。這個(gè)問題的治理思路是控制報(bào)文長(zhǎng)度在C#端做了報(bào)文最大長(zhǎng)度校驗(yàn)超過1024字節(jié)直接拒發(fā)并提示。我把這些坑整理成一個(gè)速查表給后來者省點(diǎn)時(shí)間?，F(xiàn)象常見原因處理辦法上位機(jī)連不上機(jī)器人端口未開放、機(jī)器人程序未啟動(dòng)、IP不在同一網(wǎng)段先ping通再用調(diào)試助手測(cè)試端口連通性能連上但沒收到任何數(shù)據(jù)KRL程序沒進(jìn)循環(huán)、EthernetKRL通道未初始化確認(rèn)自動(dòng)模式和程序運(yùn)行狀態(tài)查看KRL后臺(tái)信息數(shù)據(jù)偶爾解析失敗TCP粘包拆包沒處理好C#端按換行符累積緩存一個(gè)完整報(bào)文再解析機(jī)器人執(zhí)行指令后不回狀態(tài)PTP阻塞了KRL主線程運(yùn)動(dòng)指令和狀態(tài)反饋拆分處理上位機(jī)加重試位置顯示亂跳機(jī)械震動(dòng)或者數(shù)值精度顯示層加滑動(dòng)窗口濾波數(shù)據(jù)層保留原始值上位機(jī)程序被殺毒軟件攔截殺毒誤報(bào)或者防火墻工控機(jī)加白名單內(nèi)網(wǎng)環(huán)境適度降低安全策略5.3 性能調(diào)優(yōu)與穩(wěn)定性優(yōu)化聯(lián)調(diào)跑通之后還要考慮長(zhǎng)時(shí)間運(yùn)行的問題。工業(yè)現(xiàn)場(chǎng)一開機(jī)可能就是連續(xù)一個(gè)月上位機(jī)和機(jī)器人的通信如果三天兩頭斷開重連工人會(huì)罵人的。輪詢周期我最終定在100ms這里有一個(gè)權(quán)衡輪詢太頻繁比如20ms一次EthernetKRL通道來不及處理會(huì)造成消息積壓表現(xiàn)為機(jī)器人端緩沖區(qū)越積越多機(jī)器人的實(shí)時(shí)性反而下降輪詢太慢比如500ms一次界面上的位置看起來一卡一卡的操作員體驗(yàn)差。100ms是在這個(gè)項(xiàng)目里實(shí)測(cè)下來比較平衡的值既能流暢顯示位置變化又不會(huì)給KRL造成壓力。穩(wěn)定性上我做了兩件事。一是自動(dòng)重連機(jī)制C#程序發(fā)現(xiàn)連接斷開后立即用一個(gè)后臺(tái)任務(wù)嘗試重連重連間隔從1秒開始連續(xù)失敗則指數(shù)退避最多間隔10秒?，F(xiàn)場(chǎng)工況下最常遇到的不是機(jī)器人完全斷電而是偶爾網(wǎng)絡(luò)閃斷自動(dòng)重連能在閃斷恢復(fù)后幾十秒內(nèi)把通信重新建立起來。二是上位機(jī)日志功能。C#這邊所有發(fā)送的報(bào)文和接收的報(bào)文都寫入本地日志文件按天切割。KRL這邊我同樣加了一個(gè)簡(jiǎn)單的狀態(tài)寫入把接收到的目標(biāo)點(diǎn)和執(zhí)行結(jié)果寫到控制器上的文本文件里。出現(xiàn)爭(zhēng)議時(shí)兩邊日志一對(duì)比誰發(fā)的誰收的一眼就能定位。這個(gè)習(xí)慣幫我解決了好幾次工藝那邊“是誰動(dòng)了機(jī)器人”的糾紛。6. 經(jīng)驗(yàn)總結(jié)與后續(xù)擴(kuò)展6.1 做這類項(xiàng)目的心得做完這個(gè)項(xiàng)目我最大的體會(huì)是C#上位機(jī)連接KUKA機(jī)器人這件事真正的技術(shù)難點(diǎn)從來不在C#語言本身也不在TCP協(xié)議本身而在于“兩個(gè)獨(dú)立系統(tǒng)之間的契約”。C#的世界里數(shù)據(jù)類型是整整齊齊的try-catch一包異常隨便處理。KRL的世界里字符串處理要自己動(dòng)手坐標(biāo)值用REAL類型程序跑在機(jī)器人控制器上安全性和實(shí)時(shí)性要求完全不一樣。你要做的工作本質(zhì)上是把兩個(gè)世界的“語言”翻譯到同一個(gè)XML約定里讓它們能互相理解。這個(gè)項(xiàng)目里我花了不少時(shí)間在KRL端寫字符串解析和響應(yīng)拼接這部分代碼的運(yùn)行效率和健壯性直接決定了通信質(zhì)量。KRL不是一門很舒服的編程語言調(diào)試手段也有限最好的策略是讓KRL端代碼盡量簡(jiǎn)單只做“指令解析、坐標(biāo)賦值、狀態(tài)返回”這三件事把復(fù)雜的坐標(biāo)變換、路徑規(guī)劃、UI交互都放在C#端。C#端的代碼出了問題可以隨時(shí)加日志、開斷點(diǎn)、改完重新編譯而KRL程序一改往往需要上傳、重啟開發(fā)效率低得多。所以職責(zé)劃分要清晰運(yùn)算在C#執(zhí)行在KRL。另外一個(gè)心得是位置返回和運(yùn)動(dòng)控制這兩個(gè)功能最好分開調(diào)試。先把位置返回跑通界面上能看到實(shí)時(shí)坐標(biāo)了再去做運(yùn)動(dòng)控制。因?yàn)檫\(yùn)動(dòng)控制出問題時(shí)你需要靠位置數(shù)據(jù)來快速判斷機(jī)器人是否動(dòng)了、動(dòng)到哪里了。如果你兩個(gè)功能一起上線出現(xiàn)異常會(huì)非常難定位。6.2 后續(xù)可以在哪些方向擴(kuò)展這套架構(gòu)跑通之后擴(kuò)展空間其實(shí)很大。最簡(jiǎn)單的一個(gè)把C#程序里連接機(jī)器人的IP和端口改成可配置放到配置文件里程序就成了一個(gè)通用的KUKA通信中間件。再往下可以接入多臺(tái)機(jī)器人UI層面用選項(xiàng)卡或者列表切著監(jiān)控底層用同一個(gè)通信類實(shí)例化多個(gè)客戶端對(duì)象就行。如果要做得更專業(yè)一點(diǎn)可以增加姿態(tài)可視化。現(xiàn)在上位機(jī)只顯示數(shù)字坐標(biāo)操作員腦補(bǔ)機(jī)器人在空間里的姿態(tài)比較費(fèi)勁。C#這邊拿到X、Y、Z、A、B、C之后可以轉(zhuǎn)換成旋轉(zhuǎn)矩陣再用WPF的3D能力畫一個(gè)簡(jiǎn)化的機(jī)器人模型或者坐標(biāo)軸指示器這樣機(jī)器人姿態(tài)一目了然。坐標(biāo)轉(zhuǎn)換的代碼網(wǎng)上能找到現(xiàn)成庫但你要注意歐拉角的旋轉(zhuǎn)順序KUKA的ABC角有特定的約定轉(zhuǎn)矩陣時(shí)順序搞錯(cuò)了顯示出來的姿態(tài)會(huì)非常詭異。還有一條路是軌跡回放。上位機(jī)每100ms記錄一次位置連續(xù)記錄一天就能得到一條機(jī)器人的工作軌跡。把這軌跡畫在界面上或者導(dǎo)出成CSV文件對(duì)工藝優(yōu)化會(huì)非常有幫助。這個(gè)功能需求一旦提出來你前面的位置采集框架完全不用改加個(gè)數(shù)據(jù)落庫就行。如果之后要接入MES系統(tǒng)或者讓多臺(tái)設(shè)備統(tǒng)一上報(bào)可以考慮把C#上位機(jī)里的數(shù)據(jù)再通過SQL寫入數(shù)據(jù)庫或者用MQTT轉(zhuǎn)發(fā)到云端。到那一步C#上位機(jī)就成了一個(gè)數(shù)據(jù)匯聚層向下對(duì)接機(jī)器人向上對(duì)接管理系統(tǒng)。目前的TCP通信模塊完全可以復(fù)用你要做的只是在數(shù)據(jù)到達(dá)的Event里加一個(gè)轉(zhuǎn)發(fā)動(dòng)作而已。最后再分享一個(gè)小技巧這個(gè)項(xiàng)目里我用得最多每次修改協(xié)議或者代碼先在C#端加一個(gè)“檢測(cè)模式”也就是手動(dòng)輸入XML報(bào)文直接發(fā)送的調(diào)試窗口。上位機(jī)正式界面上不放這個(gè)窗口但在開發(fā)版里保留。真機(jī)聯(lián)調(diào)時(shí)遇到任何奇怪問題都能手動(dòng)拼一條報(bào)文發(fā)給機(jī)器人看看KRL那邊到底怎么響應(yīng)比層層斷點(diǎn)定位效率高得多。這個(gè)習(xí)慣幫我省下的時(shí)間不比寫通信模塊本身少。本文還有配套的精品資源點(diǎn)擊獲取