下面是KUKA機器人中-TCP通訊里的純理論的東西. CAST_TO CAST_TO使得使用單個CWRITE語句處理多達4 KB的數據成為可能。CAST_TO將單個變量分組為一個緩沖區。然后，CWRITE將此緩沖區寫入通道。 最大緩沖區大小：4 KB（= 4,096字節）。如果數據量太大，以致最大緩沖區大小不足，則必須使用幾個連續的CWRITE語句。 CAST_TO不會觸發提前運行停止，但是，如果處理的變量確實觸發了提前運行stop，則間接觸發提前運行停止。 如果使用CWRITE傳輸使用CAST_TO生成的緩沖區，則CWRITE語句中僅允許以下轉換字符： ?r（=原始數據格式） ?s（=字符串格式） 與s相比，r具有以下優點： ?如果傳輸了字符0，則將其整數表示為字符串的結尾。r不會發生此問題。 ?偏移量以字節為單位。如果CREAD用r即二進制讀取數據，則可以使用偏移量輕松計算已傳輸的值的數量。 CAST_TO (Buffer, OFFSET, Var1 < ,? … , Var10 > ) Buffer: 類型：CHAR數組,將變量Var1…Var10寫入的緩沖區. OFFSET: 類型：INT 緩沖區內的位置（以字節為單位），之后將數據寫入緩沖區。偏移量從0開始。 Var1 … Var10 寫入緩沖區的變量。每個語句最多可以有10個變量。 對于未初始化的變量或數組元素，會將隨機值寫入緩沖區。由于隨機值可能會導致緩沖區接收器出現問題，因此建議初始化所有變量和數組元素。 CAST_FROM 如果緩沖區是在數據列表中聲明的，則不能設置初始值！ 原因：初始值被當前值覆蓋。電流值可以高達4KB，因此超過了KRL線路的最大允許長度。 對的：DECL CHAR mybuffer[4096] 不正確：DECL CHAR mybuffer[4096]=" " CAST_FROM使得使用單個CREAD語句處理多達4 KB的數據成為可能。如果CREAD已從通道讀取緩沖區，則CAST_FROM可以將緩沖區分解為各個變量。 最大緩沖區大小：4 KB（= 4,096字節）。如果數據量太大以至于最大緩沖區大小不足，則必須使用幾個連續的CREAD語句。 CAST_FROM不會觸發提前運行停止，但是，如果處理的變量確實觸發了提前停止，則間接觸發提前運行停止。 CAST_FROM ( Buffer , OFFSET, Var1 < ,? … , Var10 > )

CAST 語句中允許的數據類型

例如在EthernetKRL( )程序中設定的EKI_GetFrame: EKI_GetFrame從存儲器讀取 FRAME 類型的數值 示例 RET = EKI_GetFrame("Channel_1", "Root/TCP", MyFrame) 程序分析: GLOBAL DEFFCT EKI_STATUS EKI_GetFrame(strChannelName[]:IN,strPlace[]:IN,value:OUT) 聲明變量: DECL CHAR strChannelName[] 字符串 DECL CHAR strPlace[] 字符串 DECL FRAME value FRAME坐標類型變量 DECL CHAR Buff[24]24長度的字符串 DECL STATE_T Stat 狀態變量 DECL MODUS_T Mode DECL EKI_STATUS Ret EthernetKRL通訊專用變量 DECL INT Offset 設置模式: Mode = #SYNC設置同步模式 Ret = EKI_NULL_STATUS ret.buff=1 Offset = 0 Cast_To(Buff[], Offset,value) 將坐標變量寫入緩沖區 CONTINUE CWRITE($FCT_CALL,Stat,Mode,"EFC_eki_Get",strChannelName[],strPlace[],Buff[],Ret.Buff, Ret.Read, TYPEFRAME,Ret.Connected) 使用”EFC_eki_Get”將Buff[] 里字符串坐標FRAME值通過EthernetKRL軟件發出開通的通道,給PC上位機軟件使用 Offset=0 Cast_From(Buff[], Offset,value)將緩存區里的值再發給變量 Ret.Msg_No = Stat.Msg_No RETURN Ret 發出反饋值 ENDFCT 發送標準編碼的real數據，PLC端可直接使用ID數據進行real數據的判斷。(注：使用CAST_TO函數后，Bytes[1]為對應二進制的低位，Bytes[4]為高位。上面的KUKA1對應的bytes4是為了將PLC能直接讀數據而不用通過SWAP指令進行轉換)接收到的數據存于DATA2中。? ??
責任編輯：彭菁