ABB机器人跟上位机走Socket通讯，有没有比较稳的写法？
最近在搞一个项目，PC端用C#写的，ABB IRB1200要跟它走Socket通讯传一些实时数据。机器人端程序是RobotStudio里写的，用的是SocketSend和SocketReceive那一套。我现在的问题是，PC那边发过来的时候，机器人这边收数据偶尔会丢一两条，频率还不低，大概发100次能有2-3次收不全。PC端的发送我加了校验，机器人端也用了字符触发的方式等数据。
想问下各位，ABB这块Socket通讯有没有什么比较稳的写法？比如是不是要加心跳、要不要用RAW socket、还是走PC Interface更靠谱？另外机器人端的程序结构一般是咋组织的，是死循环收还是用中断？
全部回复 (3)
ABB的Socket通讯这玩意儿我前两年在IRB6700上用过，IRB1200应该也差不多。丢包这事儿我以前也碰到过，后来排查下来两个原因：一是SocketReceive那个指令本身有个坑，它的接收长度是按字节算的，如果PC端发的是字符串，机器人这边没把结束符（比如换行）算清楚，就容易卡在那一帧收不全。二是机器人端如果用WHILE TRUE死循环收，CPU会占得很高，反而影响通讯稳定性。
我的做法是机器人端开一个中断，定时50ms去查一下有没有数据，配合一个标志位做握手。另外PC端发数据的时候最好分包，每包别超过256字节，加个帧头帧尾做校验，ABB那边用SocketReceive配合String类型读取。我这边发包1000次大概也就丢个1-2次，勉强能用了。要是要求再高，就上PC Interface走OPC UA，那个稳定但是要授权。
你这个1200要是负载不高，可以试试把机器人端的通讯任务优先级设低一点，让运动任务优先，也能缓解一点丢包。
你这个场景为啥不直接走PROFINET或者EtherNet/IP？上位机要是西门子或者罗克韦尔的PLC直接走总线多稳，Socket这种应用层的东西在工业现场本来就不靠谱。你C#上位机直接发UDP都比TCP稳，丢了就重发一帧，比你死磕TCP好使。
