并联机器人程序结构你们一般怎么搭？示教器还是直接上位机发点位？
最近在接一个分拣项目，客户那边指定要用并联机器人（delta结构，4轴+1个旋转），厂家是国产二线品牌，给的控制器文档写得很糙，例程基本就是一个pick_place的demo。需求是大概8个吸盘工位、3个放料位，还要根据视觉反馈动态调整抓取点，节拍要求1.2秒一个循环。
想问问各位平时做这类项目，程序结构是怎么组织的？是直接在示教器上把点位全编好、然后用逻辑块切换，还是上位机通过socket/Modbus实时下发目标点？视觉那边的坐标补偿一般放在哪一层处理？还有码垛/分拣这种点位频繁变的场景，离线编程软件用得多吗？
目前卡在不确定是走"示教器为主+上位机只发启停信号"的路子，还是"示教器只跑底层IO，上位机全程发点位"，感觉两种架构工作量差挺多的，但又看不出哪种更适合这种小批量多品种的工况。
全部回复 (4)
我做食品包装线delta用了快4年了，节拍1秒以内跑过4个工位+2个放料位。说下我的方案：示教器只跑运动底层和IO响应，所有的点位全部由上位机PC实时下发，用的是TCP/IP自定义协议（不是Modbus，太慢了），单条指令大概3-5ms，足够1.2秒节拍用。视觉补偿建议放在上位机算完再下发，因为示教器那点运算能力跑图像坐标变换太勉强，离线编程软件我只在初期仿真用过一次，后面点位全靠上位机生成，因为产品换型太频繁。
你那个8抓3放的工况，如果产品尺寸固定还好，要是经常变，坚决别把点位写死在示教器里，维护起来要命。
不太同意你这个"必须上位机全程发点位"的说法。我们做医药行业的分拣，同款delta，示教器里写了一套点位表+逻辑脚本，上位机只发"启动+产品代号"两个信号，示教器自己根据代号索引到对应的点位组，视觉补偿通过串口走自定义协议发给控制器做叠加，循环时间稳定在0.9秒。点位全在控制器里维护的好处是通信故障时机器人能降级运行，不会出现上位机一断就死机的情况。你的节拍1.2秒其实很宽松，示教器方案完全够用。
问一下你那8个吸盘工位是环形布置还是直线排列？视觉是装在头顶上往下看还是每个工位单独配一个？如果是单相机全局视野那种，坐标变换矩阵只算一次就行，放哪层都无所谓；要是每个工位独立相机，那补偿数据流会比较大，得考虑控制器串口缓冲区够不够。国产二线品牌的控制器我没用过，他们的EtherCAT从站刷新率能做到多少？1kHz有吗？
巧了上个月刚交了一个一模一样的项目，也是国产delta+视觉分拣。直接告诉你结论：别纠结架构了，先把视觉那边出坐标的稳定性和延迟测出来。如果视觉单帧处理+通信延迟超过50ms，你上位机下发的方案基本就废了，1.2秒节拍里光视觉就吃掉快一半时间，剩下的运动规划根本来不及。我那个项目最后是视觉和运动学解算全在控制器侧跑（虽然控制器是ARM的，性能一般，但比走外部通信稳），上位机只管触发和显示。客户那边对你怎么实现不感兴趣，他只看你节拍能不能稳定跑满8小时不掉点。