控制程式發展系統
曹永誠
[刊登於電機月刊140期 (2002年8月)]
前 言
以目前的趨勢來說﹐PC Base控制器往往是高價自動化機臺控制器的最佳選擇之一﹐但是對於PC Base控制程式的開發﹐機臺設計/製造廠商總有些困難與瓶頸需要克服。雖然對同一家廠商而言﹐所開發與量產的機種間大致上相似相近﹐但是對於PC Base控制程式的設計來說﹐這些相似相近而且架構與動作又十分雷同的機種﹐在控制程式的開發上卻還是得一次次的重新設計。或許有部份的程式碼可以套用﹐但是可重用的比例很低。因此筆者在「共通控制程式架構」（刊登於電機月刊第99期1999年3月號）中﹐曾提出一套汎用型架構以提高軟體重用性﹑建立標準介面﹑縮短開發時間﹑提升軟體品質與增進維護效率。不過雖然這套架構可以應用於大部份的機臺控制程式的開發﹐可是當機臺設計/製造廠商想要將理論實作時﹐所需要的就不單只是架構而已﹐而是根據這套架構所產生的核心(Kernel)﹑發展工具組(SDK)﹑因應機臺設計/製作/組裝/試機實際需求的試機工具(Tools)﹑Debug Tool與最佳化調機軟體等等﹐最後還得有一個輕薄短小﹑高效能﹑小體積的Run - Time版本供出機使用。如此才能全面性的解決機臺設計/製造廠商﹐在面對PC Base控制器控制程式開發上的困難點﹐以解決包括研發人員難找﹑開發成本高昂﹑設計時間較長與軟體品質難以掌控等等問題。本文試圖將「共通控制程式架構」落實到現實應用中﹐推展出機臺設計/製造廠商可以實用的「控制程式發展系統」﹐並論述相關概念﹑系統架構﹑基本功能與發展心得﹐並以工研院機械所筆者所主導開發的「控制程式發展系統」- Tkernel為範本來說明之﹐希望能藉此拋磚引玉﹐並供各位先進參考。PC Base控制器的問題點
PC Base一開始就不是針對工業控制需求所設計的﹐只是由於PC產業的快速發展﹑價格合理﹑資源豐富且人材眾多﹐為了取得這些種種的優勢而得以蓬渤發展。就PC產業來說﹐工業用控制器的市場只佔很小很小的比例﹐所以雖然工業用PC Base控制器的硬體產品已經相當的普遍﹐價格也很合理﹐但是在控制軟體的開發上﹐相關的工具與理論不管在質或量方面卻仍顯不足。大部份的開發工程師只好被迫採用商用或套裝軟體界所流行的開發工具來發展(例如Microsoft Visual C++或Visual Basic等等)﹐並且使用軟體界流行的架構或理論來開發(例如OOA/OOD/OOP或UML等等)。這些東西也不是不好﹐或是不夠用﹐但是在應用上就是與機臺控制領域的特質有些不同﹐例如Hard Real Time的需求在Microsoft Windows OS中就無法獲得解決。又例如商用Database(例如SQL Server)也無法負荷工業監控系統龐大密集的存取。又例如由於作業員操作機臺的姿勢多半是站姿﹐操作工具多半是觸控螢幕或按鈕等特質﹐機臺的MMI(人機介面)與Windows上商用或套裝軟體的設計理念就會有所差異。因此如何架構﹑規劃與設計出彈性大且擴充性高的系統﹐而且又能直接套用於未來其它未知新機種的研發而不用重新架構﹑規劃與設計﹐將是很大的困難點。以目前的現狀來說﹐大部份的PC Base控制器設計工程師都是直接使用市售的控制卡與Driver﹐這些市售的控制卡功能多半很「強大」﹐可應用的範圍也很廣﹐只是在文件與程式庫支援上就不是如此「強大」了﹐往往文件很簡單且內容很簡略﹐似乎把使用者都當成「高手」(這些大家都懂﹐不用多提)看待。更麻煩的是大部份的控制卡都沒有提供較佳的試機工具可以快速方便的試機﹐而只是提供一些Library或Sample程式﹐要求使用者自己寫程式試機。乍看之下﹐這種作法並無不妥﹐由於一開始開發機臺的研發小組PC Base程式設計功力多半很強﹐經驗與技術也很不錯﹐所以對於這些功能強大卻工具陽春的控制卡﹐在使用上或許沒有重大的困難處。但是一旦將機臺的生產放入生產線中﹐對於配電﹑調機﹑試機人員來說﹐「難以使用」的困擾就會浮現檯面。以I/O控制卡為例﹐PLC的I/O模組多半會在模組上方安裝LED燈明暗顯示I/O狀態﹐但是PC Base的I/O控制卡就不是如此。PC Base的I/O控制卡很少有LED燈的設計﹐甚至沒有隨卡內附工具軟體來顯示I/O狀態或是強制下達DO Out命令。當然對於程式設計師來說或許寫這樣的程式並不困難﹐但對於生產線現場配電工程師來說﹐由於素質與技術背景不一定精通程式設計﹐因此在應用上就常會出現很大的問題。更何況LED燈的設計看似笨拙佔空間﹐卻是很實用的設計﹐不但在配電時可以隨時監控配線正確與否﹐在控制軟體試機有Bug時也可以透過LED燈快速的找到問題所在﹐甚至於在機臺外售之後﹐如果機臺發生當機的情形﹐透過LED燈狀態顯示﹐也可加速找出當機原因並儘快排除之。
另一個較大的問題在於PC Base控制器的開發缺乏標準架構與程序。一般來說﹐當公司在決定要開發某一類新機臺時﹐往往會將該機臺的控制系統交給某個軟體小組或外包公司來負責。如果該小組(或外包公司)是第一次開發機臺的話﹐那這機臺控制系統的規劃﹑設計與程式撰寫架構﹑程序與品質﹐就會完全取決於該小組(或外包公司)Leader的技術與主觀看法了。也就是說﹐大部份的Leader會依照該機臺的規格需求﹐然後用自己最熟悉的技術和經驗加以規劃設計。或許資深與技術高超的Leader會稍稍考慮一下未來的維護性﹑擴充彈性與下一臺機臺開發時的軟體重用性。但是大部份的情況都是﹐以目前機臺規格需求與時程為重點﹐並採用自己最熟悉的技術盡快規劃﹑開發﹑試機與結案﹐而不管這些技術是否為最佳的解決方案。這種方式也不是不好﹐但是「人治」的成份過高﹐遇到技術高超的Leader或小組﹐或許機臺的軟體彈性好品質高﹐但是如果Leader的素質普普﹐或是做事態度馬虎﹐那就很可能只會做出一套「堪用」的系統﹐至於彈性與品質﹐天知道!
況且機臺開發公司不會只開發一種機臺﹐而是依公司的營運策略陸續開發一系列機臺。當下一種機臺需要開發時﹐往往就會有二種狀況發生。第一種狀況是Leader的功力不足﹐前一種機臺的程式完全無法重用﹐或許是不夠模組化無法重用﹐或許是架構不夠彈性無法套用到新機臺。因此整個開發程序必須從頭再來一次(再一次「重新發明輪子」)﹐開發成本﹑人力與時程完全無法降低﹐新軟體品質也無從確保。第二種狀況是Leader會將前一種機臺的程式直接Copy到新一種機臺當成「背景」﹐然後開始針對新機臺的規格需求修改﹐東改一點西改一點﹐也不管原先規劃該程式時的考量與著眼點﹐只是盡力「剪裁」成新機臺可用的程式。這種「剪裁」的方式「人治」的成份就更高了。或許一個技術高超的Leader﹐在前機種開發時就已經好好的考量過架構的彈性與擴充性﹐因此對於這種Copy/Modify的方式仍可達到尚可的品質。但是如果前機種開發時的架構與程式只是「堪用」的系統的話﹐那這種「穿著衣服改衣服」的方式勢必讓軟體品質更糟。更麻煩的是當這個機臺開發完成之後﹐下下一種(第三臺)機臺開發時﹐這個過程勢必會再次被使用。一再的修修補補﹐外加人是會遺忘的﹐結果是一些程式設計的小細節久而久之會被忘記或混淆。也就是說﹐當新機種開發需要修補(Copy/Modify)這些舊程式時﹐很容易因為遺忘當初設計時的考量與著眼點﹐因而越改越糟。況且開發人員還有人事流動問題﹐當機臺程式開發工程師離職時﹐不可能鉅細靡遺的交接每一行程式﹐因此技術上的流失將會讓問題更加惡化。
此外﹐這種Copy/Modify的設計方式還有個大問題-就是缺乏回溯性。假設機臺開發到第五代﹐結果發現這些原始程式中有段程式碼有Bug﹐當工程師將該Bug找出並修正了第五代機臺的程式之後﹐面對前面四種機臺﹐工程師無法只用簡單的「將原始碼Copy回前四代機臺」的簡單方式修正Bug﹐而是得重新面對前四種機臺與衍生機臺一一檢視原始碼並手動修改。雖說每一代機臺間的原始碼都是「大同小異」﹐但小異之處又無標準﹐因此得花費龐大的人力與工時﹐細細的重新Review原始碼一一修正Bug。又如果有一種新功能在第六代機臺開發的同時被同步開發出來﹐假設新功能非常茁越不可或缺﹐而必須將這種新功能放回前五種機臺﹐想必這時所花費的工時將會非常可觀。
最後﹐這些被主觀規劃﹑設計與撰寫完成的程式﹐實際上真正的技術是掌握在工程師的「手中」﹐而且很難文件化與技術交接。當核心工程師離職或流動時﹐開發的時程與成本將會大受影響﹐而舊機臺的維護也會有困難。面對這麼多不確定的因素﹐對於機臺開發公司而言﹐將是很危險的事情。為求針對這些問題點提出解決方案﹐並且設法讓控制系統的開發能工程化與合理法﹐因此筆者使用「共通控制程式架構」﹐規劃設計了一套「控制程式發展系統」- Tkernel﹐以期全面性的解決這些問題。
「控制程式發展系統」基本概念
「控制程式發展系統」的基本概念可從三部份著手:第一部份是架構「控制程式核心」。將機臺開發公司內相類似機種的控制程式共通部份抽離出來成為「控制程式核心」。基本上如果機臺控制程式的開發都能依筆者「共通控制程式架構」所論述的﹐使用標準架構來設計系統的話﹐機種間程式碼大概有60%至80%都是相同的。因此我們可以將這些通用的程式碼抽離出來封裝成「控制程式核心」。然後將機種間因應規格與動作流程不同的部份獨立開來。如此新機臺的開發就不用一切重頭開始﹐而可以直接使用核心程式﹐只針對機種不同部份予以開發與修改。例如核心程式為父Class﹐各機種繼承與修改之。或是將核心程式編譯為DLL﹐各機種程式可以使用Call DLL方式以利用核心程式。如此可以有效的降低開發成本與時程。而且核心程式與因機種間不同而個別開發的程式分離﹐在Debug﹑維護與版本更新上會更為快速。
第二部份是規劃「控制程式標準設計規範」。以程式設計來說﹐人的問題往往是最大的問題。程式設計師往往會有「文人相輕」的習性﹐喜好用自己喜歡與習慣的方式來撰寫程式。如此常會造成日後程式交接與維護上的困難﹐而且在程式整合上也會產生問題。因此對於因機種間規格與動作流程不同的機臺個別程式﹐就必須規劃「控制程式設計標準規範」來規範程式設計師撰寫程式的方法與樣式。例如變數的命名與定義﹐除了必須遵循變數標準命名法則之外﹐還必須加上註解並編寫變數表。如此一來在程式的維護與交接上才不會發生困難。又例如排程程式﹐這是機種間完全不同﹐必須一種一種依照機臺行為模式個別編寫的程式﹐但是必須事先規劃標準的撰寫規範﹐要求程式設計師按標準樣式撰寫程式﹐以統一機種間的程式樣式﹐降低未來修改的困難度與成本。
第三部份是設計「控制程式試機工具組」。首先先確定公司內各種機臺將會使用到的各類PC Base控制卡的型號。例如I/O控制卡選定某廠牌的某二種型號﹐伺服馬達運動控制卡也依需求選定幾種型號﹐不管那一種機臺除非逼不得已都得採用這些選定型號中的硬體。然後針對配電﹑設定﹑試機﹑Debug與維護等五項需求﹐設計相關的「控制程式試機工具組」。這些工具組的設計考量重點不在於美觀的畫面或是高超的程式技巧﹐而是完全著眼於生產現場的需求。因此不管是OS的選用或是操作的方式都必須考究。例如I/O控制卡的試機工具除了DI與DO狀態顯示之外﹐為求配合氣壓缸Sensor的位置調整﹐最好也能提供相關功能讓配電人員能方便快速調整。當然究竟需要那些工具組與詳細規格﹐每家公司可能都不相同﹐必須依照實際需求規劃與設計之。
總而言之﹐「控制程式發展系統」就是為了滿足開發階段研發小組所需的核心與工具組﹐以及量產階段各種任務人員所需的試機工具﹐作通盤全面性考量所規劃設計的「Total Solution」。讓機械組裝﹑電控配電﹑程序控制設計人員﹑排程程式設計人員與人機介面設計人員等數種職責不同﹑專長不同﹑工作時程不同﹐但是卻需要互相配合﹐且進度環環相扣的各組人員﹐都能提高工作效率﹐加快開發時程。此外系統還得有足夠的彈性與擴充性可適用於不同機種。
因為對於開發人員來說﹐直接使用核心程式開發新機臺﹐讓新機臺的開發不用從無到有重新研發﹐可以有效的降低研發成本﹐減少教育訓練費用。而以標準設計規範來撰寫程式﹐可以讓程式的維護性更佳﹐日後程式交接的困難度降低。至於各種試機工具的提供﹐更可以讓各組人員獨立作業﹐減少互相干擾的不必要浪費。例如為了測試馬達的重現性﹐電控人員就會臨時要求程序控制設計人員﹐先抽空發展一些「暫用」的工具軟體來測試。如此一來不但浪費了不必要的時間﹐重覆開發了很多「暫用」軟體﹐而且常會中斷原先排定的工作﹐因而讓進度延後。而軟體模擬功能的設計﹐更可以讓各組人員在配合組人員尚未將工作完成至某個進度前﹐就可以先做好各自的先期測試。例如在機構尚未組裝或是配電尚未完成前﹐程序控制設計人員就可以開始測試各模組的程序控制動作是否正常。
以下將針對組裝人員﹑程序控制程式設計人員﹑排程程式設計人員與人機介面程式設計人員四組人員﹐分別說明「控制程式發展系統」的建議規格﹐並以Tkernel為範例說明之。
針對組裝人員
組裝工程師對於PC Base程式設計技術多半不會很精通﹐因此對於組裝人員要儘量避免要求他們自行設計程式試機﹐而是得提供相關工具組供使用。基本上工具組分為二大類: 控制卡設定工具與試機工具。在Tkernel中﹐控制卡設定工具是採用INI檔格式來儲存的﹐INI檔是Microsoft Windows的標準格式﹐而且是文字檔格式﹐易讀易懂易修改﹐是很好用的設定格式。因此組裝人員可以使用文字編輯器(例如記事本或PE2)來編修﹐或是使用Tkernel所提供的圖型人機介面的工具軟體來編輯。至於試機工具的設計重點﹐必須基於試機實際需求與操作習慣來規劃設計﹐一切以現場操作方便﹑功能實用為主要考量。例如在I/O控制卡的試機工具中(如圖三)﹐除了提供I/O點的狀態顯示與手動下達ON/OFF命令之外﹐為求提升試機效率﹐尚且必須增加一些特殊工具組。例如氣壓缸的配電﹐除了控制用電磁閥要配電(DO點)之外﹐往往會在氣壓缸的左右二端點處配上感測器(Sensor﹐常常採用磁簧開關) ﹐以偵測氣壓缸內活塞的位置﹐而這二個Sensor的裝配位置則是得要精確的調校到正確的位置。因此當配電人員把Sensor配電完成之後﹐就得請另一個同事幫忙把氣壓缸的電磁閥反覆ON與OFF﹐讓活塞位置反覆左移與右移以方便調整Sensor安裝位置。以工作效率來看實在很不划算﹐因為需要二個人分工合作﹐卻只完成實際上一個人就可以做的事情。因此在Tkernel中就新增一個特殊工具組﹐可以設定讓某二個(或一個)DO點每隔N秒ON/OFF一次﹐並重覆做X次。因此組裝人員要調整Sensor位置時﹐就不再需要旁人的幫忙了。只要先設定好氣壓缸DO點位址﹐讓氣壓缸每隔N秒自動左移過去﹐再隔M秒右移回來﹐如此重覆X次﹐這樣一來就能不靠旁人幫忙調整好Sensor位置。這功能看起來十分簡單﹐但是實作與推廣之後卻是現場配電工程師愛不釋手的工具。又例如伺服馬達的PID調整﹐大部份的伺服馬達Driver(驅動器)都會提供軟體或Teaching Box(教導盒)﹐來調整PID值與顯示馬達的時間/位置圖。於是在Tkernel中就提供Jog(送一個Pulse到驅動器)﹑Scan(定速運轉)﹑PTP(Point to Point﹐點對點加減速運轉)等等工具(如圖二)來配合Teaching Box調整PID值。又例如馬達重現性測試或是Pitch Error補嚐時﹐往往需要馬達以某種特定的模式運轉。因此在Tkernel中就設計了一組特殊工具組﹐讓組裝人員不需要撰寫程式﹐透過圖型人機介面的操作就可以進行測試。
圖二﹑伺服馬達試機工具
圖三﹑I/O控制卡試機工具
針對程序控制程式設計人員
程序控制程式設計人員對於PC Base程式設計技術多半也不會很精通﹐大部份人員的技術背景多半只熟悉PLC與Ladder的技術。因此如果要程序控制程式設計人員直接使用C/C++開發程式﹐工作效率可能不會很好﹐而且教育訓練成本將會很昂貴﹐以公司營運的角度來看並不划算。一般來說﹐程序控制只需要順序控制就可以完成的。就算是動作流程複雜且同動機構很多的機臺﹐絕大部份只要透過模組切割﹐就能把同動的複雜系統﹐拆解成一個個同動的模組﹐但模組內部卻是簡單的順序控制機制(切割方式請參閱「共通控制程式架構」)。所以在Tkernel中開發了一套新的「程序控制語言」(FSP﹐Function Script Program)﹐供程序控制程式設計人員設計模組內順序控制使用。基本上FSP語言語法與PLC的Ladder(階梯圖)很類似﹐程式撰寫架構也與狀態圖很相近﹐但是在實際應用上卻提供更強大的功能﹐例如Timeout的控制與變數使用上比起Ladder增強許多。在Tkernel中也提供編輯環境供使用者撰寫FSP程式﹐如果使用者不習慣使用﹐也可以使用自己熟悉的文字編輯器(例如記事本或PE2)來撰寫程式﹐再匯入系統中編譯(Pre-Compiler)與執行。FSP程式在Tkernel中的執行方式為直譯式(Interpreter)﹐至於為何採用Interpreter而不是Compiler成機械碼(Machine Code)﹐是因為Interpreter方式在Debug與當機保護方面比較好。至於執行速度的考量﹐現在電腦的運算速度都夠快了﹐Compiler成機械碼所能提昇的系統效能相對而言實在很有限。反而是開發時程與Debug所需工時才是最重要的事情﹐Interpreter方式在這方面的表現比起Compiler可以提供更佳的效能。當使用者採用FSP語法將順序控制程式編輯完成﹐接著得將程式Pre-Compiler成「虛擬機械碼」(Visual Machine Binary Code)﹐然後將「虛擬機械碼」放入機臺內Tkernel目錄﹐就可以開始執行程式了。基本上控制程式與一般軟體的最大不同點是﹐一般軟體如果有Bug頂多把資料毀損甚至OS當機﹐但是控制程式不但可能毀損資料與OS﹐甚至於可能會把機構撞毀。一旦發生機臺因Bug而造成機構撞毀﹐不但得花成本與時間重新發包加工﹐費錢費時延誤進度之外﹐往往還會造成試機人員的傷害﹐這是非常嚴重的問題。因此Tkernel提供一組「基本保護機制」﹐以保護機構不會因為Bug誤動作而撞毀。使用者可以在試機之前先透過「基本保護機制」編輯程式將「保護法則」輸入存檔。例如一個Pick and Place的門型機器人﹐如果在Z軸夾爪機構尚未上升到安全高度之前就移動X/Y軸﹐則Z軸夾爪勢必與工作平臺相撞。為求保護機構避免撞機﹐我們可以設計一組「保護法則」﹐強制X軸與Y軸移動的必要條件是Z軸的某個DI點必須在ON的狀態(在此例中是Z軸上移安全位置的感測器)﹐以確保X/Y軸移動時﹐Z軸一定在上方安全位置。這些「保護法則」在設定完成之後﹐就會自動被下載到Driver層的各個硬體Driver程式中﹐隨時檢查是否有「保護法則」所禁止的各種危險指令被下達﹐從最底層保護避免不正確指令所造成的危險。因此一旦「保護法則」設定完善﹐不管是手動操作或是順序程式試機﹐甚至於Autorun排程程式試機等等﹐都會被嚴密的保護著﹐有效的避免撞機危險。
當程序控制程式設計人員將FSP程式放入Tkernel系統之後﹐Tkernel也提供「Debug工具」 (如圖四)供FSP程式Debug使用。「Debug工具」除了提供單步執行與中斷點之外﹐也可以隨時觀看變數內容﹑修改變數值﹑Stack查詢以及透過List Box Panel顯示程式運作流程。如果該機臺機構部份尚未加工組裝完成﹐Tkernel也提供「機構模擬器」可以模擬機臺機構運作。使用者只要按照機臺的機構特性﹐將機構運轉法則建立﹐則FSP程式就可以在沒有配接機構的一般PC上執行與Debug。
最後當機臺動作流程FSP程式測試完成之後﹐Tkernel提供「最佳化工具組」做機臺效能調整。「最佳化工具組」可以在FSP程式執行完成之後﹐顯示每一個FSP指令每一步動作的實際執行時間﹐單位是ms(微秒﹐1/1000)。透過每一步動作的執行時間﹐我們可以找出機臺機構與控制上隱含的問題。例如當氣壓缸的磁簧開關安裝位置不是在最佳位置﹐而是在可使用範圍內的話﹐乍看之下順序控制動作會一切正常。但是如果仔細觀察每一步動作執行時間的話﹐就會發現該氣壓缸的動作執行時間與理論差距過大。依照這些訊息我們可以找出問題與瓶頸﹐以提高運作效能與UPH(Unit per Hour)。又例如伺服馬達的PID沒有調整到最佳數值﹐或是PID的強健性(Robust)不夠﹐往往會產生在某些轉速下反應良好﹐但是在另一些轉速下安定時間過長等問題。透過「最佳化工具組」的追蹤﹐我們就可以很快的找到問題改善瓶頸提高效能。
圖四﹑FSP Debug工具
針對排程派工程式設計人員
以機臺控制程式的行數來看﹐雖然排程派工所佔的比例最低﹐卻對機臺的效能影響很大﹐而且也是最麻煩的部份。因為排程派工法則因應機臺與流程的不同﹐法則與程式碼完全無法重用﹐必須按規格重新量身定作。因此無法提供一組通用的程式碼或程式庫以協助設計排程派工程式。對此Tkernel採用「程式樣版」方式以提高程式碼的相似性﹐並降低日後維護的困難度。也就是說由於機臺排程派工法則與機臺規格或流程緊密相關﹐很難模組化或是提供排程派工語言﹐因此Tkernel事先定義好相關函式的撰寫規範與樣版﹐讓工程師使用C/C++語言依照規範與樣版撰寫程式﹐並放入規定的函式之中。如此一來﹐雖然程式碼本身無法重用﹐但是卻可以讓維護工作的困難度降低﹐而且當未來需要擴充新功能的時候﹐追加的成本也會較少。在Tkernel系統架構中﹐程序控制(包括排程派工﹑順序控制﹑硬體驅動器與組裝工具組)和MMI(人機介面)是分開獨立的二大部份﹐彼此透過「Interface通訊模組」通訊。在開發階段﹐二部份可以同步工作以加速開發進度。這時候程序控制部份是以獨立執行檔(EXE檔)的方式執行﹐並且提供「共通標準人機介面」(Standard MMI﹑如圖一)來操作與試機。「共通標準人機介面」讓程序控制部份在MMI部份尚未完成之前﹐暫時替代MMI使用﹐此時二部份間的Interface通訊模組將會自動改用DDE或TCP/IP方式進行通訊。相對的在程序控制部份尚未完成之前﹐Tkernel也提供模擬器給MMI暫用﹐可以模擬程序控制部份的動作與通訊﹐讓MMI部份不受機構限制可以獨立在一般PC上開發﹑測試與Debug。當二部份都各自測試完成之後﹐就可以將模擬功能取消﹐程式合併進行整合測試﹐實機驗證系統的運作。最後當整機整合測試完成之後﹐再將Tkernel改成DLL模式﹐程序控制部份會自動轉換成DLL檔供MMI部份使用﹐測試階段所需的試機畫面﹑Debug工具與試機軟體﹐都會被自動去除或精簡以縮小執行檔尺寸﹐提高執行效率。而Interface通訊模組的通訊協定也會自動被切換成DLL﹐以加快模組間的通訊資料交換速度﹐讓機臺的執行效率更佳。
圖一﹑共通標準人機介面
針對機臺人機介面(MMI)程式設計人員
以機臺人機介面部份(MMI)來說﹐不同機種間的差異性極大﹐這是因為人機介面的好壞﹐主觀意識與喜好佔很高的比例﹐不同的廠商所喜歡的操作介面都不相同﹐很難共通化與標準化。不過如果就功能面來看﹐反而容易找到各機種間的共通性﹐所以在Tkernel中對於人機介面部份的處理方式﹐是將共通功能部份寫成一系列的元件﹐以原始碼型式提供工程師使用﹐並且讓這些元件的畫面可以使用簡單的畫面編修程式來修改畫面顏色或按鍵位置。如此一來﹐透過這些現成元件的排列組合﹐就可以完成80%的人機介面程式。至於剩餘的部份﹐大部份是屬於機臺操作流程的設計﹐機臺操作流程的程式碼﹐對於機臺的不同差異性很大﹐必須被個別考量重新撰寫。因此在Tkernel中﹐如同排程程式的處理方式﹐事先定義了相關函式的撰寫樣版與規範﹐以減少日後維護的成本與困難度。其它核心功能
除了上述的工具﹑元件與樣版之外﹐如果以機構/配電等硬體的角度或是以機臺運作的功能面來看﹐有很多功能是機臺間所共通並廣汎使用的部份﹐例如三色燈的控制或是外部PB(Push Button)。這些共通的功能在Tkernel中是設計成一組組的元件﹐提供給人機介面程式或是排程程式直接使用﹐這些元件區分為三大類:第一類﹐機臺常用模組: 歸類機臺硬體常應用的範圍中可以制式化的部份﹐針對常用且標準的功能﹐設計成標準函式集以提供使用者程式使用。例如:三色燈設定與使用﹑外部PB設定與使用﹑安全門/EM狀態監看與觸控螢幕用的虛擬鍵盤等等。以三色燈為例﹐雖然機臺何時該亮綠燈何時該亮紅燈的運轉法則﹐因應機臺的操作流程不同而異﹐但是如果以宏觀的角度來看﹐畢竟三色燈已經是機臺標準配備﹐如果可以將動作標準化並提供現成的元件可以直接套用﹐在效率與時程上一定助益良多。因此在Tkernel中提供一組人機畫面供開發人員輸入三色燈的相關設定﹐開發人員只要使用設定畫面分別設定系統的總共運作模式數目﹐與各個運作模式(mode﹐例如自動運轉模式或手動操作模式)的代碼(Code)以及燈號狀態(三色燈與二蜂鳴器是否暗或亮﹐或是以某種頻率閃爍)﹐而這些設定將會以INI檔案型式儲存。當使用者在撰寫系統運作程式時﹐只要在運作模式更動時﹐透過三色燈模組所提供的介面﹐設定目前的運作模式代碼﹐則三色燈模組就會自動依照INI設定檔的設定﹐自動控制所需的燈號與蜂鳴器。
又例如外部PB模組。雖然PC Base控制器的人機介面﹐多半有配備滑鼠與鍵盤操控(或觸控螢幕)﹐但是為求提升作業員操作效率﹐因此常常會使用Push Button做成外部PB﹐讓作業員只需簡單的按鍵就能操作機臺。因此在Tkernel中提供一組人機畫面供開發人員輸入外部PB的相關設定﹐開發人員只要使用設定畫面分別設定PB的DI點位址與PB上燈號的DO點位址(如果沒有裝燈號也可以取消)﹐再設定PB與MMI畫面上物件(例如按鈕物件)的關連性﹐讓外部PB被作業員按下的時候﹐就如同使用滑鼠按下MMI畫面上相關連物件一樣﹐或是將外部PB與鍵盤上的某個鍵關連﹐當外部PB被作業員按下的時候﹐就如同鍵盤上相關連按鍵被按下。如此就不用為了外部PB特別設計相對應程式碼﹐只要設定完成就會自動掛上(plug in)。至於PB上的燈號﹐也可以與MMI畫面上物件(例如LED物件)相關連﹐或是在需要改變燈號時﹐透過外部PB模組所提供的介面動態設定之。
第二類﹐硬體控制卡常用元件: 歸類控制介面卡常應用的範圍中可以制式化的部份﹐針對常用且標準的功能﹐設計成常用元件集以提供使用者使用。以I/O控制卡為例﹐I/O控制卡中有些功能是常常會被使用的﹐例如抓取訊號上緣(I/O Trigger﹑觸發器)﹐或是訊號的數位低通濾波器（Low Pass Filter）﹐或是對於通過輸送帶的工件（Sensor的DI點）加以計數(Counter﹑計數器)等等功能。這些功能當然可以透過上層程式撰寫輕易達成﹐但是一方面在上層程式運作由於層數過多因而效能（Performance）勢必降低﹐另一方面由於這些功能都很制式化﹐沒有必要一次次的重新撰寫新程式。因此在Tkernel中根據實際需求為I/O控制介面卡設計了一套常用元件集﹐提供函式呼叫介面供程序控制與排程程式使用﹐以及提供通訊介面命令供人機介面程式使用。I/O常用元件集分為七組﹐說明如下。
- I/O直接映射元件：當某個VIO點(Visual I/O﹐虛擬I/O點﹐與實際I/O點使用方法相同﹐但並無真實輸出/輸入動作)為某值時（或是無條件）﹐將某個DI點映射（Mirror）到另一個DO點或是VIO點﹐而且可以設定是否反相（Not）與數位低通濾波器（Low Pass Filter）。例如如果我們想要將某個感測器的DI點﹐直接透過某個燈號顯示狀態的話﹐我們就可以使用直接映射元件﹐將該DI點映射到DO點﹐如此就可以讓感測器的狀態(DI點)直接控制燈號(DO點)的亮與暗。當元件被設定之後﹐相關設定將會被下載到Driver層I/O 控制介面卡的Driver中﹐成為Driver運作的一部份。也就是說從此感測器的狀態就會自動反應到燈號的亮與暗﹐完全不用撰寫程式碼來控制﹐該動作變成硬體Driver功能的一部份。
- I/O計時器元件：當某個VIO點為某值時（或是無條件）﹐將某個DI點訊號的上緣訊號或下緣訊號延後x微秒後映射到另一個DO點或是VIO點﹐而且可以設定是否反相與數位低通濾波器。
- I/O計數器元件：當某個VIO點為某值時（或是無條件）﹐將某個DI點訊號的上緣訊號或下緣訊號計數﹐並將計數值送到Global變數(虛擬I/O點集合﹐可存放32BITs﹐與實際I/O點使用方法相同﹐但並無真實輸出/輸入動作)﹐而且可以設定數位低通濾波器。
- I/O邊緣觸發元件：當某個VIO點為某值時（或是無條件）﹐當某個DI點訊號產生上緣訊號或下緣訊號﹐會將某一個DO點或是VIO點設定為1或是0﹐而且可以設定數位低通濾波器。
- I/O強迫設定DI點元件1：當某個VIO點為某值時（或是無條件）﹐不管目前外部真實的Sensor狀態﹐強迫將某個DI點狀態設定與DO點輸出訊號相同。這個元件常使用於I/O模擬與空跑（Dry Run）﹐例如某部使用真空吸盤吸取工件的機臺希望能加上空跑功能(不吸工件但是動作流程正常執行)﹐以測試控制程序與機構/氣壓缸的調整﹐對於大部份的機臺控制程式來說﹐追加此功能可說是不小的額外負擔﹐但是對Tkernel來說只需設定工件吸取的真空感測器的DI點﹐強制為真空產生器的DO點。如此一來﹐上層程式完全不需要新增或修改﹐當程式執行至吸取工件打開真空產生器的DO點時﹐真空感測器的DI點就是自動強制變成ON的訊號﹐於是上層程式就會誤以為工件已經吸取成功﹐而讓動作流程繼續下去﹐完成空跑的測試程序。
- I/O強迫設定DI點元件2：當某個VIO點為某值時（或是無條件）﹐強迫將某個DI點狀態設定與VIO點輸出訊號相同。這個元件與前項相同﹐但DI被強制設定的來源來自VIO點﹐而VIO點的值又可以來自其它的I/O元件集﹐例如來自邊緣觸發元件由另一個DI點的上升緣來改變VIO值﹐如此可以讓元件管線化(Pipe)以增強使用彈性。
- 從Driver中刪除某元件：當某個元件不需要使用時﹐可以使用此函式(或命令)刪除之。例如使用直接映射元件將某個感測器的狀態自動反應到燈號的亮與暗﹐則自設定下載之後﹐這個動作就會不斷的被運作。或許在某些情況下﹐這元件不再需要被運作了﹐我們就可以透過這項功能來刪除此元件﹐取消映射的運作。
結 語
基本上﹐「控制程式發展系統」的概念與理論是共通的﹐可以跨公司與跨機種的標準理論﹐但是實際應用上卻與公司所開發的系列機種類別有著很深的關係﹐也就是說各家公司都應該慢慢的落實這套理論﹐將「控制程式發展系統」成品開發出來。乍看之下或許會覺得整個系統十分龐大複雜﹐似乎得花費很高昂的成本與工時才能設計完成﹐因此認為不值得投入如此高昂的成本研發。但是如果老是被這種迷思所困惑﹐那只會讓問題永遠存在。「控制程式發展系統」並不用一次投入大量資金與人力專案研發﹐只要理念與目標是正確的﹐初期或許只是小量的核心程式與幾個小工具程式﹐但是隨著機種的陸續開發﹐慢慢的就可以把系統成形﹐然後新機種的研發就會越來越上軌道﹐控制軟體的撰寫也會越來越工程化。筆者所主導開發的Tkernel也不是一開始就投入大筆經費的專案計畫﹐而是「機臺控制系統開發小組」從多年來的工作中﹐從一次次的機臺開發經驗與技術中累積核心程式﹐抽空將一個個模組完成﹐並慢慢的規劃出一個個工具﹐漸漸的把整套系統完成的。因此Tkernel或許沒有最炫的畫面與最酷的程式撰寫技巧﹐但是在實用性上絕對是值得肯定的﹐並且已經推廣到數家設備商使用了。所以筆者將此概念與內容提出﹐期盼能拋磚引玉﹐並提供給各位先進參考。
參考文獻
[1]曹永誠﹐漫談PC-Base控制程式設計(1)(2)(3)﹐工業電機&自動控制裝置與設計雜誌﹐1998/7,8,9[2]曹永誠﹐共通控制程式架構﹐電機月刊第99期﹐1999/3
沒有留言:
張貼留言