技術文章

解鎖複雜運動潛能:運用 StatusGetAxisItemFast() 實現客製化多軸同步

解鎖複雜運動潛能:運用 StatusGetAxisItemFast() 實現客製化多軸同步

從非線性關係定義到精確軌跡同步的 AeroScript 編程實踐

 

客製化運動關係的實現與同步 許多進階應用中,系統參數或輔助運動設備需要與主要機械結構的運動建立客製化的協調關係;同樣地,在虛擬編程座標框架與實際機械結構座標框架之間,也普遍需要進行客製化的運動學轉換,以應對非標準的運動需求。
 

AeroScript 與 StatusGetAxisItemFast() 為滿足這些需求,Aerotech 的 AeroScript 程式語言提供了 StatusGetAxisItemFast() 函數,此函數是編程這類客製化關係與複雜轉換的理想工具;以下範例將具體展示如何運用此函數來達成目標。
 

範例關係開發:Z 軸跟隨球面

情境說明:

定義 Z 軸與 X、Y 軸的球面相依性 一個說明客製化可編程關係實用性的簡單範例是,要求垂直的 Z 需跟隨一個已定義球面 (spherical surface) 的高度變化,而 X 與 Y 則獨立地被編程以在該球面上方移動;此範例源於實際應用,清楚展現了在協調運動系統中導入客製化可編程關係的價值。
 

實作優勢:

簡化複雜曲面運動編程

如圖 1 所示的部分半球體表面上進行 3D 列印天線陣列,透過將已知的 X、Y、Z 軸位置球面關係預先編程至運動控制器,便能顯著簡化維持工具尖端與曲面相對位置,並與 X、Y 軸運動協調的複雜性;使用者隨後可利用 Aerotech 的 CADFusion 2D 圖形化運動開發工具,僅需編程所需的投影 2D 輪廓於 X、Y 座標,由於 Z 軸將自動遵循已編程的球面關係,此 2D 輪廓便能被正確地重新投影至目標半球面上。
 

關鍵技術

運用 StatusGetAxisItemFast() 與 TrajectoryDelayTime 這個客製化關係的實現,主要倚賴 Automation1 的兩項編程特點:StatusGetAxisItemFast() 函數與 TrajectoryDelayTime 參數;這兩項工具賦予使用者強大的能力,可用於編程系統變數與軸運動間的客製化協調關係,且其使用方法相當直觀。

 



圖 1. 在部分半球體表面上進行天線陣列的 3D 列印。照片由哈佛大學 Professor Jennifer A. Lewis 提供。
 

數學模型

建立球面關係方程式 針對此半球體範例,首要步驟是定義需編程至 Z 軸軌跡產生的數學關係;參考圖 2 的半球體側面投影,假設已在頂點建立已知零點,那麼對於 X,Y 平面中的任意點,皆可依據半球體的標稱半徑 (nominal radius) 確定對應的 Z 軸位置。若已知從半球體軸心 (hemisphere's axis) 出發,經由 X 和 Y 位置命令所計算出的徑向距離(即 ),便可繪製一個直角三角形,其三邊長分別為 R(半徑)、K(從頂點算起的垂直深度)與 ;依據畢氏定理可得方程式 1。
 

圖 2. 圖 1 中待 3D 列印之半球體成品的側面投影。已在半球體頂點建立零點位置,且其半徑為標稱已知。這使得 Z 軸的位置命令能夠依據 X 軸和 Y 軸位置命令的函數隱含地產生。


推導 Z
軸位置 同時,從圖 2 可清晰看出 Z 軸位置 Zpos 與半徑 R、垂直深度 K 之間滿足方程式 2 的關係。
 

Zpos=R−K (Eq. 2)


最終關係式:Z
軸軌跡的函數表達 將方程式 1 與方程式 2 合併,即可得到最終要編程至 Z 軸軌跡 (trajectory) 中,表示 Z 軸位置作為 X 和 Y 位置命令函數的關係式(方程式 3)。


 

後續步驟

編程實現與同步 在確立了 Z X、Y 之間所需的運動關係後,接下來的重點便是學習如何將此關係編程至 Z 軸的軌跡產生邏輯中,並確保其運動能與 X、Y 軸的軌跡精確同步。
 

使用 StatusGetAxisItemFast() 進行編程

程式範例

AeroScript 實作參考 附錄 A 中提供了一段適用於 Aerotech Automation1 Studio 應用程式的 AeroScript 範例程式碼,該程式碼詳細展示了如何依據方程式 3 建立的關係,執行相依的 Z 軸軌跡產生 (trajectory generation),並使其能與 X 和 Y 軸的軌跡同步運作。
 

核心機制

即時讀取 X、Y 軸命令 由於 Z 軸的軌跡相依於 X 和 Y 軸的軌跡,因此必須運用 StatusGetAxisItemFast() 函數,在每個運動更新週期 (motion update rate) 內即時收集 X 和 Y 的位置命令;系統設定檔中的 “MotionUpdateRate” 參數決定了各軸的軌跡產生頻率,對於伺服平台 (servo stages),此頻率通常最高可達 20 kHz;在此程式碼範例中,我們假設所有軸的 MotionUpdateRate 皆設定為 8 kHz
 

資料來源選擇

為何使用原始未過濾命令 為確保 Z 軸軌跡能精確對應 X、Y 軸的即時命令,StatusGetAxisItemFast() 函數扮演關鍵角色,其允許使用者以資料實際產生的速率來收集不同的資料項目 (data items);在此特定應用中,我們需要從 X 和 Y 軸收集名為 “PositionCommandRawUnfiltered” 的 AxisDataSignal特別強調必須使用此原始、未過濾 (raw, unfiltered) 的訊號,因為任何形式的濾波處理都會引入難以預測或補償的濾波延遲 (filtering delay),若使用過濾後訊號,將導致計算出的 Z 軸軌跡內建無法調和的時間差,使得後續透過軌跡延遲 (trajectory delay) 進行同步的操作無法完美達成目標,最終影響多軸運動的協調性。
 

處理頻率差異

1 kHz 任務處理 20 kHz 資料 程式碼的執行效率也是考量重點,StatusGetAxisItemFast() 函數被安排在範例程式碼的第 27 與 28 行,位於 AeroScript 的“critical”程式碼區塊(由 CriticalSectionStart() 和 CriticalSectionEnd() 界定)內;這類關鍵區塊的執行頻率為 1 kHz,然而 X、Y 軸的軌跡訊號更新率卻高達 20 kHz(此處假設為 20kHz,與前述 8kHz 範例設定不同,原文此處有不一致,此處依原文範例程式碼段落描述為主)。為了在 1 kHz 的任務週期內捕捉完整的 20 kHz 軌跡資訊,每次執行 CRITICAL 程式碼區塊時,必須透過 StatusGetAxisItemFast() 函數一次性捕捉 20 個資料點 (data points),並將這些點存入陣列供後續計算使用;該函數捕捉的資料點數量由命令列的最後一個參數指定。有關 StatusGetAxisItemFast() 可收集的資料項目完整清單,使用者可查閱 Automation1 說明檔中的 Controller Status FunctionAeroScript Enums 相關主題。
 

軌跡計算與命令

逐點生成 Z 軸運動 當 X 和 Y 的軌跡點被收集到陣列後,即可透過一個簡單的 ‘for’ 迴圈結構來計算 Z 軸的軌跡;迴圈會遍歷陣列中的每一個 XY 命令位置,並根據先前建立的球面關係(方程式 3)計算出對應的 Z 軸命令。在每次迴圈迭代的末尾,會呼叫 MovePt() (Position and Time) 函數,命令 Z 軸在指定的時間間隔(即 1/20 毫秒,對應於 1 毫秒關鍵區段內執行 20 次迴圈)內移動到計算出的位置,如此即可確保 Z 軸的軌跡速率X、Y 軸的 20 kHz 速率相匹配。
 

持續運作

背景任務循環執行 完成一輪(20 個點)的 Z 軸位置計算與命令後,系統會接著收集下一批(20 個)的 X 和 Y 軌跡點,並重複上述計算與命令過程;只要此客製化關係保持啟用狀態,且範例程式碼在背景 Task 中持續運行,當主要運動命令在另一個 Task 中下達給 X 和 Y 時,Z 便會始終自動地遵循方程式 3 所定義的球面進行運動。至此,最後需要解決的關鍵問題便是同步
 

同步軌跡

同步挑戰

補償 Z 軸固有延遲

為實現所有三個軸的運動同步 (synchronize),使用者必須在 X 和 Y 上實施軌跡延遲;其原因在於,Z 軸的運動是依據 X、Y 軸的命令被動計算產生的,相較於主動接收命令的 X、Y 軸,其軌跡執行本質上存在滯後 (lagging)。此滯後源於執行關鍵程式碼區段所需的時間(例如 1 毫秒)以及從機器控制器收集 X、Y 軸軌跡資料所產生的額外延遲。
 

解決方案

配置 TrajectoryDelayTime 參數 為了精確補償 Z 軸因計算關係而產生的延遲,使用者需要修改系統機器控制器定義 (MCD) 文件,為 X 和 Y 軸配置 TrajectoryDelayTime 參數;此參數可在 Automation1 Studio 應用程式的設定工作區中,於 Axes>Motion>Trajectory 路徑下找到。其作用是在 X 和 Y 軸的軌跡執行初始階段加入一個啟動延遲,該延遲的量值應設定為等於 Z 軸所經歷的總延遲時間,如此一來,三個軸的運動起點就能完美對齊,達到重新同步的效果。
 

延遲值確定

量測與設定 TrajectoryDelayTime 所需的具體數值(單位為毫秒)會因系統配置、所使用的驅動器硬體以及程式碼執行效率而異;在本文的範例情境中,經實測需要 3 毫秒的延遲來充分考慮程式碼執行時間以及相關驅動器硬體的延遲。對使用者而言,確定正確延遲值最直接的方法是:在尚未設定 TrajectoryDelayTime 的情況下,利用 Automation1 StudioData Visualizer 模組,量測 Z 軸命令串流 (command stream) 相對於 X 和 Y 命令串流的相位滯後 (phase lag);如圖 3 所示,Data Visualizer 圖表清晰地展示了 Z 軸命令串流確實滯後於 X 和 Y 軸。
 

 

圖 3. Automation1 Studio Data Visualizer 模組的螢幕截圖,顯示由於編程的球面關係對 X 和 Y 軸命令的反應,Z 軸命令響應出現相位滯後。
 

驗證同步效果

透過 Data Visualizer 中的左右游標線,可以方便地量測出所需的延遲時間,例如本例中的 3 毫秒;接著,將此 3 毫秒的延遲值設定到 X 和 Y 軸的 TrajectoryDelayTime 參數後,再次觀察運動軌跡,如圖 4 所示。從圖 4 可以明顯看到,經過延遲補償後,所有三個軸(X、Y、Z)的運動命令現在已經精確地同步 (synchronized) 在同一個軌跡產生週期上。

 


圖 4. Automation1 Studio Data Visualizer 模組的螢幕截圖,顯示在為 X 和 Y 軌跡添加了 3 毫秒的 TrajectoryDelayTime 參數後,X、Y 和 Z 軸的命令已同步。
 

核心能力總結

強大的非線性運動學編程 儘管本文展示的 Z 追蹤球面範例相對簡單,但其背後所運用的概念賦予了使用者在處理非線性客製化運動學編程方面極為強大的能力;透過 AeroScript 語言,使用者可以直接編程實現大量軸(包含實體軸與虛擬軸)之間極其複雜的函數關係運動學轉換
 

應用價值

解決複雜自動化難題 在眾多複雜的自動化應用中,軸的軌跡相依於其他軸的運動狀態,以及需要進行非線性客製化運動學轉換的情況十分常見;StatusGetAxisItemFast() 的靈活性不僅限於位置相依關係,使用者甚至可以編程讓從屬軸的位置依據主導軸的速度命令和/或加速度命令(除了位置之外)的函數來決定。
 

關鍵工具組合

實現複雜同步運動 總而言之,StatusGetAxisItemFast() 函數提供了高度的彈性,讓使用者能夠隨心所欲地定義實體及虛擬軸之間的任何運動學關係;而 TrajectoryDelayTime 參數則確保了在這些複雜關係下,所有相關軸的運動執行都能保持精確同步。

範例 AeroBasic 程式碼 | 下載完整程式檔案 >
 

焦點產品

Aerotech 六軸 (6-DOF) Hexapods 定位系統

Aerotech 的六軸 (6-DOF) Hexapods 定位系統(亦稱為 Stewart 平台)為市場提供了高性能的六自由度運動控制解決方案,這類系統以其領先業界的保證精度著稱,Aerotech 公開其規格與性能曲線,確保達到次微米級的定位精度,甚至可執行 20 奈米 (nanometer) 級別的步進運動,並經過外部設備驗證。



 

核心優勢與應用領域:
Aerotech Hexapods 系統的核心優勢在於其:

  • 超高精度
    提供市場上最精確的運動控制技術之一,並有數據保證。
  • 可靠性
    設計堅固耐用,能夠適應全天候 (24/7) 的高負載工業運行環境。
  • 單一控制器
    透過 Aerotech 強大且使用者友善的單一控制器即可管理所有運動軸,並支援即時運動模擬與視覺化,簡化了編程、整合與操作的複雜性。

 

這些高性能的六軸平台適用於對精度、穩定性及多自由度運動有嚴格要求的應用,例如:

  • 光子器件操作與對準
  • 半導體製程與精密檢測
  • 航太與衛星傳感器測試
  • 同步加速器與光束線樣品操作
  • X 射線繞射
  • 醫療與生物技術領域的高精度運動控制

 

系列產品與客製化能力:
Aerotech 提供了包括 HEX150、HEX300、HEX500 系列在內的標準化六軸平台產品線,可滿足從 7.5 公斤到 200 公斤等級的不同負載能力需求;不僅如此,面對標準品無法滿足的特殊應用,Aerotech 及台灣合作夥伴 奧創系統 還提供專業的客製化六軸 (6-DOF) Hexapods 定位系統與解決方案,服務範圍涵蓋特殊的安裝介面、線纜配置、行程範圍調整乃至真空環境兼容性等深度設計修改,以精確滿足客戶的獨特需求。
 

了解更多六軸平台解決方案

六軸平台 ≤ 200 公斤
六軸平台 > 200 公斤