發(fā)那科機器人報警代碼 H0ST-208  SM:還沒有連接     H0ST-209  SM:連接已強制結束

然后他是和海康相機走的MODBUS TCP/IP，是一個類似于孔定位打螺絲的設備，而且相機給的偏移數(shù)據在顯示器上查看都是對的，但是機器人這邊寄存器收到的數(shù)據跟相機的不一樣，而且還很大      

網線，交換機端口，交換機都換過了，本來接地沒接，又把接地接上，

他這個報警，很不穩(wěn)定，有時候機器人斷電重啟就好了，有時候自己就好了，有時候上步程序定位，走的位置都沒問題，下一步就報警，連接已強制結束

不清楚，先回復，保持熱度

斷開連接問題，發(fā)那科2個端口，之前用了端口#1，通過交換機跟plc和視覺聯(lián)機，現(xiàn)在增加了端口#2，直接和視覺聯(lián)機，端口#1只和plc連接，因為視覺和plc之間不通訊，端口#2的網段也和端口#1分開，不在同一網段

現(xiàn)在的報警暫時還會出現(xiàn)幾次，很少了，

然后機械手接收數(shù)據的問題是因為相機沒法送出來，在電腦用socket調試助手試了，發(fā)送后，機械手能接收到

然后就覺得視覺沒法送出來
然后視覺用調試助手也是了，也是沒問題（這是視覺廠家遠程試的），但是，再次連接走了一遍拍照程序，，，，，，，，接收到了

那到底是誰的問題呢，，，，，，，不知道咯，好了就行啊

感謝LZ分享，學習了

數(shù)據現(xiàn)在傳輸沒問題了，改了機器人這邊視覺拍照的程序，但是昨天通訊方面沒出過問題，今天又出現(xiàn)了，很不穩(wěn)定，總會出現(xiàn)，208報警，還沒有連接

現(xiàn)在尋求廣大能人義士，能來現(xiàn)場給看看解決一下這個問題，費用問題可以聊，地點是青島

我都是用 PLC做過渡,沒這樣用過,覺得這樣用反而麻煩

這是你機器人程序的邏輯有問題，
你一開始圖1第9行就是斷開連接，斷開連接的前提條件是已建立socket連接，才能在斷開連接
把這一行往后移，移到數(shù)據已處理完或刪除試試

正常的邏輯是
建立連接
送送數(shù)據請求
接收數(shù)據
處理數(shù)據
斷開連接，正常說是不用斷開連接

引用

引用第7樓tkggtdkjpl于2025-08-05 17:33發(fā)表的  :
這是你機器人程序的邏輯有問題，
你一開始圖1第9行就是斷開連接，斷開連接的前提條件是已建立socket連接，才能在斷開連接
把這一行往后移，移到數(shù)據已處理完或刪除試試

正常的邏輯是
.......

這么寫沒問題的，正常情況就應該這么寫。

大概率還是通信配置導致的，看看有沒有什么地方配了比如modbusTCP 超時時間、心跳包之類的參數(shù)，小日本的東西特別是網絡這塊，要么不按照標準來自己搞一套，要么生搬硬套標準不考慮實際情況，反正就不好用。

還有就是，現(xiàn)在的機器人大部分都支持跑后臺程序，通信最好還是放在后臺跑，因為機器人和PLC 不一樣，幾乎所有的機器人前臺程序都是阻塞模式的，特別是運動指令執(zhí)行要好久，這樣導致通信的發(fā)起和處理很多時候時機不好，又是modbus TCP這種強實時性和可靠性的協(xié)議。

放后臺跑，意味著隨時隨地和外設保持通信，即使發(fā)生通信錯誤，也可以靠輪詢在下一次通信的時候把數(shù)據補回來，而且因為單獨寫通信的程序，可以做更多的檢查和通信錯誤處理，就像前面說的，modbus TCP并不是完全可靠的，但是靠速度和輪詢，可以在偶發(fā)故障的時候完全不影響運行。

引用

引用第7樓tkggtdkjpl于2025-08-05 17:33發(fā)表的  :
這是你機器人程序的邏輯有問題，
你一開始圖1第9行就是斷開連接，斷開連接的前提條件是已建立socket連接，才能在斷開連接
把這一行往后移，移到數(shù)據已處理完或刪除試試

正常的邏輯是
.......

是，我就是把斷開連接下移到最后一步才好的

引用

引用第8樓cstw18于2025-08-06 15:23發(fā)表的  :

這么寫沒問題的，正常情況就應該這么寫。

  

但是我改了之后   確實就好了