KUKA KR C5控制器想接自己写的视觉脚本，二次开发走哪条路？
项目上有一台KR C5配的KR 20 R1810，客户要求我们把视觉检测结果直接喂给机器人，触发抓取动作。我之前主要玩FANUC和ABB的二次开发，KUKA接触不多，现在卡在选哪条路线上。
目前看到几条路：一是走KUKA.RobotSensorInterface配合EthernetKRL，搞个外部PC跑Python脚本通过socket发过去；二是直接用KUKA Sunrise Cabinet做JAVA二次开发，把视觉程序塞进控制器里跑；三是用KUKA的OPC UA Server（EKI的升级版？），PLC那边再转。预算和周期都有限，想问下各位有实际经验的，哪条路踩坑最少？我们视觉用的是海康的工业相机，自带SDK那种。
另外KUKA的示教器上能直接跑脚本吗，还是必须得外挂工控机？时延大概能到多少ms级别？
全部回复 (3)
说下我们去年做的类似方案，KR C5 + 海康相机 + 自己写的Python检测程序，最终走的是EthernetKRL那条路，PC端用Python开socket服务器，机器人端用KRL的SREAD/SWRITE指令收发XML字符串。单次通信周期空载测下来稳定在8-15ms，加视觉处理后整体从拍照到机器人收到坐标大概120-180ms（取决于你检测算法复杂度），客户那边检测节拍1.2秒/件完全够用。
Sunrise Cabinet那条路我也调研过，JAVA开发确实灵活，调试也能断点，但官方授权费用离谱，我们小项目根本扛不住，而且对开发环境有要求，本地得有对应的Workbench版本。OPC UA那条最坑，EKI配置到吐，最后发现KUKA的OPC UA实现对自定义数据结构支持很差，传一个6自由度的位姿都得拆成几十个节点，不建议碰。
你如果只是传坐标+触发信号，EthernetKRL完全够用，把KRL端的SREAD/SWRITE程序包成一个subroutine，视觉那边按固定格式发XML就行。唯一要注意的是机器人端要开一个独立的任务（不要塞在主程序里），避免阻塞运动控制。
等下，你确定客户要求"直接喂给机器人"？这个描述有点模糊，我们之前碰到两种完全不同的需求：一种是视觉算完位姿发给机器人做抓取（这种走外部PC通信就行），另一种是客户要求视觉程序必须跑在机器人控制器内部（这种就得Sunrise了）。你先确认清楚这个再选路线，不然白搞。另外海康SDK在Linux ARM架构上跑会有坑，如果走Sunrise路线要提前验证。
我这边在主机厂干了八年KUKA项目，提个不一样的思路：如果你项目里有汇川或者西门子PLC做中转，其实可以让视觉先发给PLC，PLC再通过PROFINET或者EtherCAT下发给机器人，这样时延更可控，而且KUKA机器人做PROFINET从站配置比EthernetKRL简单得多，示教器里勾几个选项就行。我们现在新项目基本都走这个架构，视觉、机器人、PLC三方解耦，谁换供应商都不影响。
当然如果你项目里没有PLC硬要加一个，成本就上去了，这种情况下EthernetKRL还是最优解。但有一点你得注意，KRL那点字符串处理能力太弱了，复杂一点的协议解析你得自己写状态机，我们当时写了一个通用的XML解析模板，500多行，有需要可以私聊。