模板FB覆蓋8種機(jī)型：ST代碼復(fù)用架構(gòu)的完整落地指南)
前陣子接手一個(gè)項(xiàng)目的維護(hù)清單點(diǎn)開一看8臺(tái)不同規(guī)格的設(shè)備8個(gè)平行的PLC程序文件里面大量復(fù)制粘貼的痕跡同名變量在8個(gè)工程里各編譯各的改一處漏三處的現(xiàn)象嚴(yán)重到客戶只敢在零點(diǎn)停機(jī)讓我動(dòng)程序。這個(gè)項(xiàng)目讓我下決心做了ST代碼復(fù)用架構(gòu)的重構(gòu)用一個(gè)設(shè)備模板FB把8種機(jī)型的控制邏輯全部收斂到同一套代碼里。最終程序本體從三四十個(gè)FB縮減成核心的1個(gè)模板FB外掛幾個(gè)工具FB程序量壓縮了接近七成換型維護(hù)時(shí)改數(shù)據(jù)、不動(dòng)邏輯故障定位時(shí)間從半小時(shí)級(jí)降到分鐘級(jí)。這篇就把這個(gè)一個(gè)設(shè)備模板FB覆蓋8種機(jī)型的完整設(shè)計(jì)與落地過程拆開講清楚。內(nèi)容不綁定某個(gè)具體PLC品牌按IEC 61131-3的結(jié)構(gòu)化文本ST思路來寫只要你用的平臺(tái)支持UDT和功能塊實(shí)例化思路可以直接抄作業(yè)。適合正在被多機(jī)型、多版本程序折磨的設(shè)備廠工程師也適合想從梯形圖思維轉(zhuǎn)向數(shù)據(jù)驅(qū)動(dòng)編程的PLC開發(fā)者。1. 多機(jī)型程序?yàn)槭裁磿?huì)失控復(fù)制粘貼模式欠下的債1.1 復(fù)制粘貼帶來的隱性成本設(shè)備廠做多機(jī)型項(xiàng)目時(shí)最省事的辦法就是拿上一臺(tái)的程序改一改。改IO表、改軸參數(shù)、改幾個(gè)計(jì)時(shí)器然后編譯下載看起來半天就能交付一臺(tái)。但這種模式下欠下的債往往在半年后集中爆發(fā)。我接手的那批8種機(jī)型就存在典型的復(fù)制漂移問題最早的兩臺(tái)設(shè)備程序還算同源到第4臺(tái)時(shí)某個(gè)執(zhí)行機(jī)構(gòu)因?yàn)橛布男蛽Q了動(dòng)作方式于是有人在復(fù)制出來的程序里把一段邏輯替換掉了第6臺(tái)的工程師又在這個(gè)基礎(chǔ)上加了配方切換到第8臺(tái)程序結(jié)構(gòu)和第1臺(tái)已經(jīng)面目全非。結(jié)果就是每臺(tái)設(shè)備都帶了一套自己的歷史包袱現(xiàn)場(chǎng)報(bào)障時(shí)對(duì)方工程師說你看一下第4臺(tái)能不能參考第6臺(tái)的處理我只能苦笑——兩套程序的變量命名都完全對(duì)不上了。復(fù)制粘貼看起來是單臺(tái)成本最低的方案但乘以機(jī)型數(shù)量之后維護(hù)成本是疊加而不是累加的。你在1臺(tái)設(shè)備上做的任何修正都要手工同步到另外7臺(tái)漏一臺(tái)就是一顆定時(shí)炸彈。更麻煩的是不同機(jī)型的程序差異到底是參數(shù)不同還是邏輯不同在純復(fù)制模式下完全不可控到了后期連寫程序的人自己都說不清第5臺(tái)為什么比第2臺(tái)多了一個(gè)中間繼電器。1.2 按機(jī)型維護(hù)程序版本走不遠(yuǎn)的三個(gè)原因很多人會(huì)說那我不復(fù)制每個(gè)機(jī)型單獨(dú)建工程、單獨(dú)維護(hù)版本不就行了嗎這種做法的第一個(gè)問題在于版本爆炸。8種機(jī)型就是8份工程每份工程還有自己的修訂歷史現(xiàn)場(chǎng)改了一版、廠里又改了一版、出差臨時(shí)又改了一版最后誰的工程最全都沒人知道。第二個(gè)問題是交叉bug無法收斂某個(gè)通用邏輯比如安全回路、報(bào)警處理、手自動(dòng)切換在第3臺(tái)設(shè)備上修好了但第7臺(tái)還是舊邏輯客戶現(xiàn)場(chǎng)就會(huì)再踩一遍同樣的坑而這個(gè)坑明明在另一臺(tái)設(shè)備上已經(jīng)填平了。第三個(gè)問題最致命工程師的人力被死死綁在按機(jī)型維護(hù)的模式里一旦老員工離職新來接手的工程師面對(duì)8套風(fēng)格可能完全不同的程序光理解就要花幾個(gè)月更別說繼續(xù)改。1.3 破局點(diǎn)把設(shè)備差異從代碼里抽出去要解決多機(jī)型失控核心思路其實(shí)一句話讓程序邏輯關(guān)注動(dòng)作怎么做讓數(shù)據(jù)關(guān)注每個(gè)機(jī)型的具體參數(shù)是什么。動(dòng)作邏輯寫一遍就夠了機(jī)型差異全部交給數(shù)據(jù)去表達(dá)。這個(gè)思路落到PLC里就是用一個(gè)模板FB多個(gè)實(shí)例化背景數(shù)據(jù)塊的結(jié)構(gòu)同一份FB代碼喂給不同機(jī)型的數(shù)據(jù)塊跑出不同的控制行為。所謂覆蓋8種機(jī)型本質(zhì)不是8份程序而是1份邏輯8份參數(shù)。這也是為什么這篇博文的重心不在某個(gè)具體功能怎么寫而在于你怎么設(shè)計(jì)這套數(shù)據(jù)和邏輯的邊界——邊界畫對(duì)了8種機(jī)型是運(yùn)氣問題后續(xù)再來新機(jī)型也只是新增一份數(shù)據(jù)的問題。2. 設(shè)備模板FB的頂層設(shè)計(jì)邏輯與數(shù)據(jù)徹底分離2.1 用UDT把機(jī)型翻譯成一張數(shù)據(jù)表ST代碼復(fù)用架構(gòu)里最核心的數(shù)據(jù)基礎(chǔ)設(shè)施是UDT用戶自定義數(shù)據(jù)類型。你可以把UDT理解成一張機(jī)型的空表格里面定義清楚這個(gè)設(shè)備有哪些參數(shù)維度。我的做法是建一個(gè)名為TYPE_MachineConfig的UDT字段分成幾個(gè)組第一組是身份信息MachineTypeID機(jī)型編號(hào)、MachineName機(jī)型名稱、FirmwareVersion程序版本這些字段主要用于HMI顯示和追溯不參與邏輯判斷。第二組是工藝時(shí)間參數(shù)CycleTime目標(biāo)節(jié)拍、HomeTimeout回原點(diǎn)超時(shí)、PositionTimeout定位超時(shí)、ActionTime壓合/貼裝動(dòng)作時(shí)間所有這些都用REAL或INT類型單位是毫秒放進(jìn)數(shù)據(jù)塊里可在線修改。第三組是運(yùn)動(dòng)參數(shù)AxisCount軸數(shù)量、MaxSpeed最大速度、Acceleration加速度、TargetPositions數(shù)組多個(gè)目標(biāo)位置的數(shù)組這樣個(gè)別機(jī)型即使有5個(gè)定位點(diǎn)也能用同一個(gè)數(shù)組字段覆蓋。第四組是使能開關(guān)HasUnloader是否有下料剔除、HasVisionCheck是否有視覺校驗(yàn)、HasTaping是否有貼標(biāo)動(dòng)作——這類BOOL字段非常關(guān)鍵它們是邏輯分支的開關(guān)在程序里用IF HasUnloader THEN ...這樣的寫法讓不同機(jī)型走不同的子步驟。這張表設(shè)計(jì)得好不好直接決定了模板FB能覆蓋多少機(jī)型。我在第一版設(shè)計(jì)里把動(dòng)作時(shí)間和是否有某機(jī)構(gòu)混在了一個(gè)字段里結(jié)果新機(jī)型出現(xiàn)時(shí)又要加字段、又要改FB非常被動(dòng)。后來總結(jié)出的經(jīng)驗(yàn)是凡是你能預(yù)見的差異都用字段表達(dá)凡是沒把握的差異用擴(kuò)展字段通用處理兜底不要讓FB代碼因?yàn)閿?shù)據(jù)不夠而被迫跟著改。2.2 FB內(nèi)部只寫動(dòng)作不寫哪臺(tái)機(jī)器有了UDT這張表模板FB內(nèi)部就只做一件事把動(dòng)作流程按狀態(tài)機(jī)一段段跑完每一步需要什么參數(shù)統(tǒng)統(tǒng)從VAR_IN_OUT接進(jìn)來的Config數(shù)據(jù)塊里取。我在FB_DeviceTemplate里定義了一個(gè)整數(shù)型狀態(tài)變量用CASE語句描述整臺(tái)設(shè)備的工藝循環(huán)代碼看起來大致是這樣FUNCTION_BLOCK FB_DeviceTemplate VAR_INPUT Enable : BOOL; // 總使能來自安全回路/手自動(dòng)切換 bStart : BOOL; // 啟動(dòng)指令來自HMI按鈕或上位機(jī) bStop : BOOL; // 停止指令緊急停止鏈之外的操作停止 END_VAR VAR_IN_OUT Config : TYPE_MachineConfig; // 機(jī)型參數(shù)指向?qū)嵗约旱腄B IO : TYPE_IO_Interface; // IO映射接口后面單獨(dú)講 END_VAR VAR State : INT : 0; // 工藝狀態(tài)機(jī)0IDLE10回原點(diǎn)20抓取30定位40執(zhí)行... bStepDone : BOOL : FALSE; bError : BOOL : FALSE; ErrorCode : INT : 0; StepTimeout : TON; // 每一步的超時(shí)計(jì)時(shí)器 END_VARCASE State OF 0: // IDLE等待啟動(dòng) IF Enable AND bStart THEN State : 10; END_IF; 10: // 回原點(diǎn) IF IO.bHomeSwitch THEN State : 20; ELSIF StepTimeout.Q THEN bError : TRUE; ErrorCode : 101; // 回原點(diǎn)超時(shí) END_IF; 20: // 抓取/取料 IF IO.bGripperDone THEN State : 30; END_IF; 30: // 定位到目標(biāo)位置 IF ABS(IO.rCurrentPos - Config.TargetPositions[Config.ActiveTargetIndex]) 0.5 THEN State : 40; ELSIF StepTimeout.Q THEN bError : TRUE; ErrorCode : 102; // 定位超時(shí) END_IF; 40: // 執(zhí)行壓合/貼裝/焊接等動(dòng)作 IF IO.bActionDone THEN State : 50; ELSIF StepTimeout.Q THEN bError : TRUE; ErrorCode : 103; // 動(dòng)作超時(shí) END_IF; 50: // 可選的下料/剔除步驟僅部分機(jī)型啟用 IF Config.HasUnloader THEN IF IO.bUnloaderDone THEN State : 0; // 循環(huán)完成 bStepDone : TRUE; END_IF; ELSE State : 0; bStepDone : TRUE; END_IF; END_CASE;看見沒有FB里面從頭到尾沒有出現(xiàn)過如果是第3臺(tái)設(shè)備就怎樣、第7臺(tái)設(shè)備就怎樣的機(jī)型編號(hào)判斷。所有差異都通過Config里的BOOL開關(guān)、數(shù)組下標(biāo)、超時(shí)值來體現(xiàn)。這個(gè)設(shè)計(jì)的好處是當(dāng)你需要修改某個(gè)動(dòng)作順序時(shí)你只需要改這一個(gè)FB8種機(jī)型立刻全部生效不用再一臺(tái)一臺(tái)同步。缺點(diǎn)也很明顯——任何一次改動(dòng)影響的范圍從一臺(tái)設(shè)備變成了全部設(shè)備所以后面我會(huì)專門講版本管理和測(cè)試清單的配合。2.3 為什么這里選ST而不是梯形圖很多工程師習(xí)慣用梯形圖寫設(shè)備程序?qū)懙蕉鄼C(jī)型時(shí)容易順手在里面加幾條機(jī)型判斷的比較指令程序很快就變得不可讀。ST在這個(gè)場(chǎng)景下的優(yōu)勢(shì)不是高大上而是三個(gè)非常實(shí)際的點(diǎn)第一ST對(duì)數(shù)據(jù)結(jié)構(gòu)友好。UDT、數(shù)組、多維數(shù)組、結(jié)構(gòu)體嵌套這些操作在ST里就是很自然的字段訪問而在梯形圖里你需要在DB里逐個(gè)展開地址寫起來又長又容易錯(cuò)。第二ST對(duì)分支和循環(huán)的表達(dá)力強(qiáng)。CASE、IF-ELSIF-ELSE、FOR循環(huán)寫出來邏輯一目了然維護(hù)時(shí)能直接看到條件和分支的完整關(guān)系。第三ST代碼在版本管理工具里可以像普通文本一樣做差異對(duì)比。我用任何文本差異工具都能看到這個(gè)模板FB前后兩個(gè)版本改了什么而梯形圖導(dǎo)出成文本后對(duì)比效果很差。ST并不是萬能的比如位邏輯的簡單聯(lián)鎖你用梯形圖可能更直觀但當(dāng)一個(gè)FB要承載8種機(jī)型的狀態(tài)機(jī)時(shí)用ST寫狀態(tài)機(jī)必然是首選。2.4 IO差異處理見符號(hào)不見地址機(jī)型差異里最讓人頭疼的是IO數(shù)量不一樣、IO分配完全對(duì)不上。如果FB里直接寫%I0.5這種絕對(duì)地址換個(gè)機(jī)型程序立刻崩。所以我的IO處理原則是FB不碰任何物理地址全部通過一個(gè)叫做TYPE_IO_Interface的UDT作為接口層。這個(gè)UDT里定義的是語義化的BOOL量比如bHomeSwitch回原點(diǎn)到位、bGripperDone抓取完成、bActionDone動(dòng)作完成、bUnloaderDone下料完成以及一個(gè)REAL類型的rCurrentPos當(dāng)前軸位置。在主程序或OB1里每個(gè)機(jī)型實(shí)例化時(shí)都有自己的一張IO映射表把物理輸入點(diǎn)映射到這些語義信號(hào)上再把物理輸出點(diǎn)映射到動(dòng)作指令上。簡單說FB和物理IO之間隔了一層翻譯器型號(hào)差異被翻譯器消化掉了模板FB永遠(yuǎn)只跟語義信號(hào)打交道。這個(gè)思想跟面向?qū)ο罄锏慕涌诤芟馪LC界叫符號(hào)訪問但真正落地時(shí)關(guān)鍵不是有沒有符號(hào)而是你把物理映射放在哪個(gè)層級(jí)。我選擇放在上層專門做一個(gè)IO_Assign功能塊每個(gè)機(jī)型一份IO映射邏輯雖然這部分不能完全復(fù)用但它的體量比整個(gè)FB要小得多而且邏輯簡單純粹出錯(cuò)的概率也低。3. 落地實(shí)操從零搭出一個(gè)覆蓋8種機(jī)型的模板FB3.1 第一步把8種設(shè)備的工藝動(dòng)作用一張狀態(tài)圖抽象出來不要一開始就寫代碼。我的經(jīng)驗(yàn)和習(xí)慣是先拿A3紙把所有機(jī)型的工藝流程畫出來找到它們的公共骨架。我當(dāng)時(shí)那8種機(jī)型都屬于同一類貼裝設(shè)備雖然有的機(jī)型有視覺校驗(yàn)有的有自動(dòng)下料有的有雙工位但不管怎么變主干流程都繞不開準(zhǔn)備→回原點(diǎn)→取料→定位→執(zhí)行壓合動(dòng)作→檢查→放行。于是我把這個(gè)主干流程確定為狀態(tài)機(jī)的主路徑把那些部分機(jī)型才有的步驟設(shè)計(jì)成側(cè)分支。畫這個(gè)狀態(tài)圖的過程中最大的爭執(zhí)往往來自這個(gè)步驟到底是所有機(jī)型都有還是只有某幾臺(tái)有。我的判斷標(biāo)準(zhǔn)很簡單如果有一個(gè)動(dòng)作是至少兩臺(tái)設(shè)備共用并且出現(xiàn)在主流程相同位置我就把它放進(jìn)主狀態(tài)機(jī)如果它只在一臺(tái)設(shè)備上出現(xiàn)我就把它抽成可選步驟用Config里的BOOL字段控制。這樣既不會(huì)讓8種機(jī)型共用一個(gè)超級(jí)臃腫的狀態(tài)機(jī)也不會(huì)因?yàn)閭€(gè)別特例而破壞模板的整體性。3.2 第二步定義UDT和背景DB8種機(jī)型的參數(shù)差異怎么放公共骨架確定后下一步就是建立TYPE_MachineConfig這個(gè)UDT。我先列了一個(gè)8種機(jī)型差異清單把軸數(shù)、目標(biāo)位數(shù)量、動(dòng)作時(shí)間、有無校驗(yàn)機(jī)構(gòu)、有無下料機(jī)構(gòu)、有無安全門互鎖差異等信息全部列出來然后設(shè)計(jì)字段。關(guān)鍵技巧是數(shù)組字段要按最大的機(jī)型來定義。比如8種機(jī)型里軸數(shù)最多的是4軸那么TargetPositions就定義成ARRAY[1..4] OF REAL軸數(shù)少的機(jī)型只填前幾項(xiàng)其余默認(rèn)0但邏輯上不參與。這樣FB代碼里不需要根據(jù)軸數(shù)去動(dòng)態(tài)改變數(shù)組訪問的邊界只要用Config.ActiveTargetIndex來控制使用哪個(gè)目標(biāo)位置即可。建好UDT后我在程序塊里為8種機(jī)型分別建立了8個(gè)獨(dú)立的背景數(shù)據(jù)塊分別命名為DB_Machine201、DB_Machine202……每個(gè)背景塊里的Config字段類型都是TYPE_MachineConfig但實(shí)參值互不相同。PLC平臺(tái)在生成背景DB時(shí)會(huì)自動(dòng)帶上UDT的所有字段我只需要逐個(gè)填參數(shù)。這一步我必須強(qiáng)調(diào)一個(gè)坑不要圖省事讓8個(gè)實(shí)例共用同一個(gè)全局?jǐn)?shù)據(jù)塊那樣會(huì)出現(xiàn)一臺(tái)設(shè)備改參數(shù)、另外7臺(tái)也跟著變的事故。獨(dú)立的背景DB是隔離的基礎(chǔ)后面你要在線修改任何一臺(tái)設(shè)備的參數(shù)影響范圍都是這一個(gè)DB。3.3 第三步模板FB的ST骨架與三個(gè)關(guān)鍵設(shè)計(jì)技巧模板FB的骨架就是前面那段CASE狀態(tài)機(jī)代碼但真正讓它能穩(wěn)定覆蓋8種機(jī)型靠的是三個(gè)額外的設(shè)計(jì)技巧第一個(gè)技巧是主使能鏈條。我把總安全繼電器的狀態(tài)、手自動(dòng)切換狀態(tài)、急停狀態(tài)全部匯總成一個(gè)MasterEnable信號(hào)從FB外部串進(jìn)來FB內(nèi)部第一個(gè)CASE周期就會(huì)判斷Enable為FALSE時(shí)不管當(dāng)前狀態(tài)在哪一步立刻把輸出全部清零狀態(tài)機(jī)凍結(jié)。這個(gè)保證了不論哪臺(tái)機(jī)型安全優(yōu)先級(jí)永遠(yuǎn)最高不會(huì)出現(xiàn)因?yàn)閰?shù)差異導(dǎo)致某些設(shè)備在急停后還繼續(xù)動(dòng)作的情況。第二個(gè)技巧是步進(jìn)超時(shí)參數(shù)化。傳統(tǒng)做法是給整個(gè)程序?qū)懸粋€(gè)固定掃描超時(shí)但不同機(jī)型的節(jié)拍差別很大有的機(jī)型單循環(huán)8秒有的要25秒。我把每一步的超時(shí)時(shí)間都做成了Config里可配置的TimeoutXx字段調(diào)試時(shí)根據(jù)每臺(tái)設(shè)備的實(shí)際節(jié)拍微調(diào)避免誤報(bào)警。第三個(gè)技巧是錯(cuò)誤碼統(tǒng)一編碼。ErrorCode的前兩位是步驟號(hào)機(jī)構(gòu)號(hào)后三位是具體原因比如102定位超時(shí)、201抓取失敗。8種機(jī)型共用這套編碼HMI報(bào)警界面不需要針對(duì)每個(gè)機(jī)型做不同文本映射這又省了一大塊維護(hù)量。3.4 第四步在OB1里實(shí)例化8次一個(gè)模板吃8份數(shù)據(jù)數(shù)據(jù)層準(zhǔn)備好后程序集成就變得非常樸素在OB1里連續(xù)調(diào)用FB_DeviceTemplate八次每次把對(duì)應(yīng)的背景DB包含各自Config和IO映射作為實(shí)參傳進(jìn)去// 在OB1主程序中的調(diào)用示意 FB_DeviceTemplate_Instance_201( Enable : MasterEnable, bStart : HMI_Start_201, bStop : HMI_Stop_201, Config : DB_Machine201.Config, IO : DB_Machine201.IO ); FB_DeviceTemplate_Instance_202( Enable : MasterEnable, bStart : HMI_Start_202, bStop : HMI_Stop_202, Config : DB_Machine202.Config, IO : DB_Machine202.IO );這里要注意TIA這類平臺(tái)允許同一個(gè)FB生成多個(gè)實(shí)例化調(diào)用每個(gè)調(diào)用自動(dòng)帶一份獨(dú)立的內(nèi)部變量存儲(chǔ)區(qū)。我的習(xí)慣是給8個(gè)調(diào)用分別命名為Instance_201到Instance_208方便監(jiān)控時(shí)一眼看出哪臺(tái)設(shè)備在哪個(gè)狀態(tài)。這一步做完理論上整套系統(tǒng)就已經(jīng)能跑起來了。我第一次實(shí)際下載運(yùn)行那天8臺(tái)設(shè)備先后上電第一臺(tái)走完一個(gè)完整循環(huán)后后面的7臺(tái)逐個(gè)跑通那種同一份代碼跑出不同動(dòng)作的感覺確實(shí)很爽但也馬上迎來了第二個(gè)問題——現(xiàn)場(chǎng)調(diào)試時(shí)有些怪毛病根本不是程序邏輯錯(cuò)而是數(shù)據(jù)填錯(cuò)了。4. 8種機(jī)型到底差在哪數(shù)據(jù)解決90%邏輯解決10%4.1 用數(shù)據(jù)就能搞定的差異很多人聽到一個(gè)FB覆蓋8種機(jī)型會(huì)覺得不可思議其實(shí)是因?yàn)樗麄儼巡町惗籍?dāng)成了邏輯差異實(shí)際上80%到90%的機(jī)型差異都只是參數(shù)差異。我按實(shí)際項(xiàng)目列個(gè)清單第一類是時(shí)間類差異。不同機(jī)型的目標(biāo)節(jié)拍不同、動(dòng)作時(shí)間不同、等待時(shí)間不同這些全部進(jìn)入Config的REAL字段。第二類是位置類差異。8種機(jī)型的幾個(gè)定位點(diǎn)完全不同把它們做進(jìn)TargetPositions數(shù)組每個(gè)機(jī)型填自己的坐標(biāo)。第三類是數(shù)量類差異。軸數(shù)、工位數(shù)、點(diǎn)位數(shù)量不同時(shí)用數(shù)組和ActiveTargetIndex來控制當(dāng)前使用哪個(gè)。第四類是機(jī)構(gòu)選配差異。某幾臺(tái)設(shè)備帶下料剔除機(jī)構(gòu)某幾臺(tái)帶視覺校驗(yàn)這些用BOOL開關(guān)控制程序只在開關(guān)為TRUE時(shí)才執(zhí)行對(duì)應(yīng)分支段。第五類是通訊地址和IO分配差異這部分放進(jìn)IO映射層解決不讓模板FB感知。這里最核心的思路是參數(shù)差異的本質(zhì)是同一種動(dòng)作的不同數(shù)值邏輯差異的本質(zhì)是動(dòng)作是否存在或動(dòng)作順序不同。前者完全不值得用代碼區(qū)分給數(shù)據(jù)就行后者才需要謹(jǐn)慎設(shè)計(jì)分支。4.2 必須用邏輯分支處理的例外那10%的邏輯差異是什么樣我項(xiàng)目里的實(shí)際例子有兩個(gè)。一個(gè)是有視覺校驗(yàn)功能的機(jī)型在定位完成后、執(zhí)行動(dòng)作前要插入一個(gè)拍照并等待結(jié)果的步驟這個(gè)步驟不僅影響狀態(tài)機(jī)的走向還涉及視覺信號(hào)交互。另一個(gè)是雙工位機(jī)型會(huì)在主流程里多出一個(gè)工位切換的并行操作。處理這些例外時(shí)我沒有把它們從模板FB里剝出去而是讓它們?cè)跔顟B(tài)機(jī)里以可選步驟的方式存在。以視覺校驗(yàn)為例我在狀態(tài)機(jī)里保留了一個(gè)標(biāo)記為校驗(yàn)站的狀態(tài)節(jié)點(diǎn)State35前面用IF Config.HasVisionCheck THEN引導(dǎo)進(jìn)入否則跳過。這樣模板FB仍然是唯一的主邏輯載體例外動(dòng)作只是這條主線上的旁支。這個(gè)方法的前提是例外數(shù)量可控如果一個(gè)FB里插了七八個(gè)例外分支狀態(tài)機(jī)會(huì)變得沒人能看懂那時(shí)候就要考慮拆成基礎(chǔ)模板FB擴(kuò)展功能FB的組合結(jié)構(gòu)了。4.3 一張表看清楚8種機(jī)型的差異歸屬我把當(dāng)時(shí)整理的差異歸屬表簡化后放在這里方便大家參考這個(gè)分析的粒度機(jī)型代號(hào)軸數(shù)量目標(biāo)位數(shù)量有無視覺校驗(yàn)有無下料剔除有無雙工位節(jié)拍目標(biāo)差異歸屬M(fèi)20122無無無8s數(shù)據(jù)M20223有無無12s數(shù)據(jù)邏輯視覺M20334無有無10s數(shù)據(jù)邏輯下料M20434有有無15s數(shù)據(jù)邏輯視覺下料M20546無有有20s數(shù)據(jù)邏輯下料雙工位M20646有有有25s數(shù)據(jù)邏輯全選配M20722無無無8s數(shù)據(jù)與M201同一模板M20835有無有18s數(shù)據(jù)邏輯視覺雙工位這張表是我和團(tuán)隊(duì)討論了兩輪才定下來的。定完之后我就能精確告訴客戶和同事哪幾臺(tái)的差異只需要填數(shù)據(jù)哪幾臺(tái)需要多寫一小段可選邏輯新增機(jī)型時(shí)也照這個(gè)思路先做差異歸屬分析再?zèng)Q定要不要?jiǎng)覨B。5. 換型調(diào)試現(xiàn)場(chǎng)填錯(cuò)數(shù)據(jù)比寫錯(cuò)程序更常見5.1 一次IO映射錯(cuò)誤引發(fā)的誤動(dòng)作排查全過程模板FB跑通以后現(xiàn)場(chǎng)調(diào)試的主要矛盾就從寫邏輯變成了填數(shù)據(jù)、配映射。我記得調(diào)試第5臺(tái)雙工位機(jī)型時(shí)出現(xiàn)了間歇性誤啟動(dòng)有時(shí)候按下啟動(dòng)按鈕設(shè)備不動(dòng)有時(shí)候剛完成一次循環(huán)又自動(dòng)觸發(fā)第二次。第一反應(yīng)以為是狀態(tài)機(jī)復(fù)位邏輯有問題查了半小時(shí)代碼沒查出異常。后來打開IO映射導(dǎo)出的表格一比對(duì)發(fā)現(xiàn)該機(jī)型背景DB里的bUnloaderDone下料完成信號(hào)被映射到了某個(gè)物理輸入點(diǎn)而那個(gè)輸入點(diǎn)實(shí)際上接的是安全門到位信號(hào)。下料機(jī)構(gòu)還沒動(dòng)安全門一關(guān)程序就以為下料完成了于是狀態(tài)機(jī)提前放行緊接著又啟動(dòng)下一循環(huán)。這類問題的根源在于模板FB把物理IO藏起來了人機(jī)界面看到的全是語義信號(hào)一旦物理點(diǎn)位重新分配或接線調(diào)整映射表必須人工同步。建議是每次換型接線后先做一次信號(hào)強(qiáng)制測(cè)試——把每個(gè)輸入點(diǎn)逐個(gè)強(qiáng)制核對(duì)HMI監(jiān)控畫面上的語義信號(hào)是否跟著變化全部對(duì)上號(hào)再跑自動(dòng)流程。這個(gè)步驟看起來土但對(duì)排查這類數(shù)據(jù)錯(cuò)誤非常高效。5.2 在線修改、熱下載與庫更新的坑多機(jī)型模板FB有一個(gè)隱形的管理難題你改了模板FB8個(gè)實(shí)例會(huì)同時(shí)變但理論上是同時(shí)變實(shí)際下載時(shí)PLC可不一定允許你一次全刷下來。在線修改和熱下載在不同平臺(tái)有不同限制有些情況下你改了變量表或背景DB的數(shù)據(jù)類型就需要停機(jī)下載全量程序而不能后臺(tái)熱更新。我在項(xiàng)目中碰到過一次現(xiàn)場(chǎng)正在生產(chǎn)我想給模板FB加一個(gè)報(bào)警提示字段結(jié)果這個(gè)字段的修改牽動(dòng)了背景DB的結(jié)構(gòu)PLC提示無法在線修改需要初始下載。那天的經(jīng)驗(yàn)讓我明白涉及數(shù)據(jù)結(jié)構(gòu)變更的改動(dòng)必須提前計(jì)劃停機(jī)窗口別指望所有優(yōu)化都能在線熱更新。另一個(gè)經(jīng)驗(yàn)是庫更新傳播。如果你把模板FB做成了可復(fù)用的庫元件每次改完庫后所有項(xiàng)目的引用不會(huì)自動(dòng)更新需要手動(dòng)執(zhí)行更新庫元件版本的操作。我見過有同事改了庫元件忘了同步導(dǎo)致8臺(tái)設(shè)備有5臺(tái)在用新邏輯、3臺(tái)還在跑舊邏輯。所以我的管理習(xí)慣是庫元件每次修改都記錄版本號(hào)項(xiàng)目里統(tǒng)一在發(fā)布前檢查引用版本現(xiàn)場(chǎng)版本不一致時(shí)用程序頭部的FirmwareVersion字段做對(duì)比一眼就能看出哪臺(tái)固件落后了。5.3 8個(gè)實(shí)例同時(shí)工作的掃描周期壓力實(shí)測(cè)有人會(huì)擔(dān)心一個(gè)FB被調(diào)用8次CPU掃描周期會(huì)不會(huì)扛不住。實(shí)際測(cè)下來純邏輯指令的負(fù)載非常小ST的CASE狀態(tài)機(jī)和IF判斷在PLC里都是布爾和整數(shù)運(yùn)算8個(gè)實(shí)例加一起也就幾百條指令現(xiàn)代CPU完全無壓力。真正的壓力來自兩個(gè)地方一是背景DB的數(shù)據(jù)量大如果UDT里塞了幾百個(gè)REAL數(shù)組字段8個(gè)DB加起來內(nèi)存占用可觀但PLC內(nèi)存通常也不是瓶頸二是如果有通訊指令比如和視覺、機(jī)器人通訊每個(gè)實(shí)例都收發(fā)數(shù)據(jù)時(shí)通訊處理時(shí)間可能遠(yuǎn)超邏輯掃描時(shí)間。這種情況我建議把通訊從模板FB里摘出去單獨(dú)用通訊管理塊模板FB只讀取已經(jīng)更新好的通訊結(jié)果避免一個(gè)FB又要跑工藝又要等通訊導(dǎo)致的時(shí)序混亂。5.4 規(guī)范化調(diào)試的幾條清單經(jīng)歷了這一輪8機(jī)型的調(diào)試我沉淀了一套調(diào)試前檢查清單核心幾條是先核對(duì)IO映射表與端子接線圖再核對(duì)8份背景DB的參數(shù)是不是按不同機(jī)型的銘牌填寫接著做一次所有輸入信號(hào)的強(qiáng)制測(cè)試然后手動(dòng)單步走一遍每個(gè)機(jī)型的狀態(tài)機(jī)最后才能允許自動(dòng)循環(huán)。這套清單在第一次跑通后我反復(fù)用了好幾輪每次都能在正式啟動(dòng)前揪出至少一兩個(gè)參數(shù)填錯(cuò)的問題比到時(shí)候停機(jī)強(qiáng)太多。6. 再往前走一步從機(jī)種模板到平臺(tái)化維護(hù)6.1 新增一種機(jī)型代碼要改幾處這是評(píng)估這套架構(gòu)最直接的試金石。在我這套方案里新增一種機(jī)型需要改動(dòng)的代碼量基本是零要做的事只有三件第一在HMI或全局配置里增加一個(gè)機(jī)型編號(hào)第二復(fù)制一份背景DB并改成新機(jī)型名第三把新機(jī)型的工藝參數(shù)和IO映射填進(jìn)去。如果新機(jī)型帶有全新的選配機(jī)構(gòu)還需要在模板FB里加一個(gè)可選步驟分支但這種情況通常是少數(shù)。換句話說一個(gè)FB覆蓋8種機(jī)型不是一個(gè)終點(diǎn)它更大價(jià)值在于新機(jī)型開局只需要處理數(shù)據(jù)不需要?jiǎng)舆壿嬤@對(duì)設(shè)備廠快速響應(yīng)新需求的意義非常實(shí)際。6.2 用配方表批量生成實(shí)例DB的參數(shù)當(dāng)機(jī)型數(shù)量繼續(xù)增長到十幾、二十臺(tái)時(shí)人工填DB參數(shù)不僅費(fèi)時(shí)還容易錯(cuò)。我的做法是把TYPE_MachineConfig的字段做成一張Excel配方表用工程腳本把表格內(nèi)容自動(dòng)生成PLC數(shù)據(jù)塊的初始化文件或者導(dǎo)入到配方變量里。這樣新機(jī)型到達(dá)時(shí)工藝工程師在Excel里做完參數(shù)生成配置文件我再導(dǎo)入工程背景DB的初始值和配方就全部就位。這個(gè)流程的重點(diǎn)是Excel的列頭必須和UDT字段名完全對(duì)齊否則腳本轉(zhuǎn)換時(shí)報(bào)錯(cuò)后你得一條條查反而比手工填更慢。6.3 報(bào)警、HMI畫面和MES接口的聯(lián)動(dòng)復(fù)用模板FB幫我們把控制邏輯收斂了報(bào)警、HMI畫面和MES通訊也應(yīng)該跟著復(fù)用。我的做法是讓模板FB輸出一個(gè)統(tǒng)一的MachineStatus結(jié)構(gòu)體里面包含當(dāng)前狀態(tài)編號(hào)、當(dāng)前步驟編號(hào)、錯(cuò)誤碼、運(yùn)行計(jì)數(shù)等HMI畫面讀取這個(gè)結(jié)構(gòu)體不同機(jī)型共用同一張主畫面只是底層的DB實(shí)例不同。MES接口也類似上位機(jī)只需要和統(tǒng)一的DB結(jié)構(gòu)打交道不必關(guān)心當(dāng)前連的是哪臺(tái)機(jī)器。這個(gè)結(jié)構(gòu)體接口的思路和前面IO接口層的思路是一脈相承的定義好契約內(nèi)部差異再大也不影響外部交互。6.4 個(gè)人維護(hù)這個(gè)庫兩年的三點(diǎn)體會(huì)前陣子我又把這兩年的維護(hù)記錄翻了一遍最想分享的體會(huì)是模板FB不是一上來就要設(shè)計(jì)得完美無缺而是先用一個(gè)合理的骨架圈住80%的共性然后在每個(gè)新機(jī)型到來時(shí)小步演進(jìn)。我第一版只覆蓋了3種機(jī)型過程里發(fā)現(xiàn)選配機(jī)構(gòu)開關(guān)這個(gè)設(shè)計(jì)后才逐步擴(kuò)展成覆蓋8種。二是每次改動(dòng)模板FB都必須全量回歸測(cè)試哪怕只是加一個(gè)字段也要把8臺(tái)設(shè)備的典型流程各跑一遍我建議把這一步寫進(jìn)項(xiàng)目流程。三是模板FB的價(jià)值要到第二、第三個(gè)項(xiàng)目才能真正體現(xiàn)同一套架構(gòu)如果只服務(wù)一個(gè)項(xiàng)目前期投入可能不劃算但一旦你面對(duì)的是持續(xù)交付的機(jī)型族這套架構(gòu)就是降低維護(hù)成本的真正杠桿。 一個(gè)模板FB覆蓋8種機(jī)型：ST代碼復(fù)用架構(gòu)的完整落地指南
前陣子接手一個(gè)項(xiàng)目的維護(hù)清單點(diǎn)開一看8臺(tái)不同規(guī)格的設(shè)備8個(gè)平行的PLC程序文件里面大量復(fù)制粘貼的痕跡同名變量在8個(gè)工程里各編譯各的改一處漏三處的現(xiàn)象嚴(yán)重到客戶只敢在零點(diǎn)停機(jī)讓我動(dòng)程序。這個(gè)項(xiàng)目讓我下決心做了ST代碼復(fù)用架構(gòu)的重構(gòu)用一個(gè)設(shè)備模板FB把8種機(jī)型的控制邏輯全部收斂到同一套代碼里。最終程序本體從三四十個(gè)FB縮減成核心的1個(gè)模板FB外掛幾個(gè)工具FB程序量壓縮了接近七成換型維護(hù)時(shí)改數(shù)據(jù)、不動(dòng)邏輯故障定位時(shí)間從半小時(shí)級(jí)降到分鐘級(jí)。這篇就把這個(gè)一個(gè)設(shè)備模板FB覆蓋8種機(jī)型的完整設(shè)計(jì)與落地過程拆開講清楚。內(nèi)容不綁定某個(gè)具體PLC品牌按IEC 61131-3的結(jié)構(gòu)化文本ST思路來寫只要你用的平臺(tái)支持UDT和功能塊實(shí)例化思路可以直接抄作業(yè)。適合正在被多機(jī)型、多版本程序折磨的設(shè)備廠工程師也適合想從梯形圖思維轉(zhuǎn)向數(shù)據(jù)驅(qū)動(dòng)編程的PLC開發(fā)者。1. 多機(jī)型程序?yàn)槭裁磿?huì)失控復(fù)制粘貼模式欠下的債1.1 復(fù)制粘貼帶來的隱性成本設(shè)備廠做多機(jī)型項(xiàng)目時(shí)最省事的辦法就是拿上一臺(tái)的程序改一改。改IO表、改軸參數(shù)、改幾個(gè)計(jì)時(shí)器然后編譯下載看起來半天就能交付一臺(tái)。但這種模式下欠下的債往往在半年后集中爆發(fā)。我接手的那批8種機(jī)型就存在典型的復(fù)制漂移問題最早的兩臺(tái)設(shè)備程序還算同源到第4臺(tái)時(shí)某個(gè)執(zhí)行機(jī)構(gòu)因?yàn)橛布男蛽Q了動(dòng)作方式于是有人在復(fù)制出來的程序里把一段邏輯替換掉了第6臺(tái)的工程師又在這個(gè)基礎(chǔ)上加了配方切換到第8臺(tái)程序結(jié)構(gòu)和第1臺(tái)已經(jīng)面目全非。結(jié)果就是每臺(tái)設(shè)備都帶了一套自己的歷史包袱現(xiàn)場(chǎng)報(bào)障時(shí)對(duì)方工程師說你看一下第4臺(tái)能不能參考第6臺(tái)的處理我只能苦笑——兩套程序的變量命名都完全對(duì)不上了。復(fù)制粘貼看起來是單臺(tái)成本最低的方案但乘以機(jī)型數(shù)量之后維護(hù)成本是疊加而不是累加的。你在1臺(tái)設(shè)備上做的任何修正都要手工同步到另外7臺(tái)漏一臺(tái)就是一顆定時(shí)炸彈。更麻煩的是不同機(jī)型的程序差異到底是參數(shù)不同還是邏輯不同在純復(fù)制模式下完全不可控到了后期連寫程序的人自己都說不清第5臺(tái)為什么比第2臺(tái)多了一個(gè)中間繼電器。1.2 按機(jī)型維護(hù)程序版本走不遠(yuǎn)的三個(gè)原因很多人會(huì)說那我不復(fù)制每個(gè)機(jī)型單獨(dú)建工程、單獨(dú)維護(hù)版本不就行了嗎這種做法的第一個(gè)問題在于版本爆炸。8種機(jī)型就是8份工程每份工程還有自己的修訂歷史現(xiàn)場(chǎng)改了一版、廠里又改了一版、出差臨時(shí)又改了一版最后誰的工程最全都沒人知道。第二個(gè)問題是交叉bug無法收斂某個(gè)通用邏輯比如安全回路、報(bào)警處理、手自動(dòng)切換在第3臺(tái)設(shè)備上修好了但第7臺(tái)還是舊邏輯客戶現(xiàn)場(chǎng)就會(huì)再踩一遍同樣的坑而這個(gè)坑明明在另一臺(tái)設(shè)備上已經(jīng)填平了。第三個(gè)問題最致命工程師的人力被死死綁在按機(jī)型維護(hù)的模式里一旦老員工離職新來接手的工程師面對(duì)8套風(fēng)格可能完全不同的程序光理解就要花幾個(gè)月更別說繼續(xù)改。1.3 破局點(diǎn)把設(shè)備差異從代碼里抽出去要解決多機(jī)型失控核心思路其實(shí)一句話讓程序邏輯關(guān)注動(dòng)作怎么做讓數(shù)據(jù)關(guān)注每個(gè)機(jī)型的具體參數(shù)是什么。動(dòng)作邏輯寫一遍就夠了機(jī)型差異全部交給數(shù)據(jù)去表達(dá)。這個(gè)思路落到PLC里就是用一個(gè)模板FB多個(gè)實(shí)例化背景數(shù)據(jù)塊的結(jié)構(gòu)同一份FB代碼喂給不同機(jī)型的數(shù)據(jù)塊跑出不同的控制行為。所謂覆蓋8種機(jī)型本質(zhì)不是8份程序而是1份邏輯8份參數(shù)。這也是為什么這篇博文的重心不在某個(gè)具體功能怎么寫而在于你怎么設(shè)計(jì)這套數(shù)據(jù)和邏輯的邊界——邊界畫對(duì)了8種機(jī)型是運(yùn)氣問題后續(xù)再來新機(jī)型也只是新增一份數(shù)據(jù)的問題。2. 設(shè)備模板FB的頂層設(shè)計(jì)邏輯與數(shù)據(jù)徹底分離2.1 用UDT把機(jī)型翻譯成一張數(shù)據(jù)表ST代碼復(fù)用架構(gòu)里最核心的數(shù)據(jù)基礎(chǔ)設(shè)施是UDT用戶自定義數(shù)據(jù)類型。你可以把UDT理解成一張機(jī)型的空表格里面定義清楚這個(gè)設(shè)備有哪些參數(shù)維度。我的做法是建一個(gè)名為TYPE_MachineConfig的UDT字段分成幾個(gè)組第一組是身份信息MachineTypeID機(jī)型編號(hào)、MachineName機(jī)型名稱、FirmwareVersion程序版本這些字段主要用于HMI顯示和追溯不參與邏輯判斷。第二組是工藝時(shí)間參數(shù)CycleTime目標(biāo)節(jié)拍、HomeTimeout回原點(diǎn)超時(shí)、PositionTimeout定位超時(shí)、ActionTime壓合/貼裝動(dòng)作時(shí)間所有這些都用REAL或INT類型單位是毫秒放進(jìn)數(shù)據(jù)塊里可在線修改。第三組是運(yùn)動(dòng)參數(shù)AxisCount軸數(shù)量、MaxSpeed最大速度、Acceleration加速度、TargetPositions數(shù)組多個(gè)目標(biāo)位置的數(shù)組這樣個(gè)別機(jī)型即使有5個(gè)定位點(diǎn)也能用同一個(gè)數(shù)組字段覆蓋。第四組是使能開關(guān)HasUnloader是否有下料剔除、HasVisionCheck是否有視覺校驗(yàn)、HasTaping是否有貼標(biāo)動(dòng)作——這類BOOL字段非常關(guān)鍵它們是邏輯分支的開關(guān)在程序里用IF HasUnloader THEN ...這樣的寫法讓不同機(jī)型走不同的子步驟。這張表設(shè)計(jì)得好不好直接決定了模板FB能覆蓋多少機(jī)型。我在第一版設(shè)計(jì)里把動(dòng)作時(shí)間和是否有某機(jī)構(gòu)混在了一個(gè)字段里結(jié)果新機(jī)型出現(xiàn)時(shí)又要加字段、又要改FB非常被動(dòng)。后來總結(jié)出的經(jīng)驗(yàn)是凡是你能預(yù)見的差異都用字段表達(dá)凡是沒把握的差異用擴(kuò)展字段通用處理兜底不要讓FB代碼因?yàn)閿?shù)據(jù)不夠而被迫跟著改。2.2 FB內(nèi)部只寫動(dòng)作不寫哪臺(tái)機(jī)器有了UDT這張表模板FB內(nèi)部就只做一件事把動(dòng)作流程按狀態(tài)機(jī)一段段跑完每一步需要什么參數(shù)統(tǒng)統(tǒng)從VAR_IN_OUT接進(jìn)來的Config數(shù)據(jù)塊里取。我在FB_DeviceTemplate里定義了一個(gè)整數(shù)型狀態(tài)變量用CASE語句描述整臺(tái)設(shè)備的工藝循環(huán)代碼看起來大致是這樣FUNCTION_BLOCK FB_DeviceTemplate VAR_INPUT Enable : BOOL; // 總使能來自安全回路/手自動(dòng)切換 bStart : BOOL; // 啟動(dòng)指令來自HMI按鈕或上位機(jī) bStop : BOOL; // 停止指令緊急停止鏈之外的操作停止 END_VAR VAR_IN_OUT Config : TYPE_MachineConfig; // 機(jī)型參數(shù)指向?qū)嵗约旱腄B IO : TYPE_IO_Interface; // IO映射接口后面單獨(dú)講 END_VAR VAR State : INT : 0; // 工藝狀態(tài)機(jī)0IDLE10回原點(diǎn)20抓取30定位40執(zhí)行... bStepDone : BOOL : FALSE; bError : BOOL : FALSE; ErrorCode : INT : 0; StepTimeout : TON; // 每一步的超時(shí)計(jì)時(shí)器 END_VARCASE State OF 0: // IDLE等待啟動(dòng) IF Enable AND bStart THEN State : 10; END_IF; 10: // 回原點(diǎn) IF IO.bHomeSwitch THEN State : 20; ELSIF StepTimeout.Q THEN bError : TRUE; ErrorCode : 101; // 回原點(diǎn)超時(shí) END_IF; 20: // 抓取/取料 IF IO.bGripperDone THEN State : 30; END_IF; 30: // 定位到目標(biāo)位置 IF ABS(IO.rCurrentPos - Config.TargetPositions[Config.ActiveTargetIndex]) 0.5 THEN State : 40; ELSIF StepTimeout.Q THEN bError : TRUE; ErrorCode : 102; // 定位超時(shí) END_IF; 40: // 執(zhí)行壓合/貼裝/焊接等動(dòng)作 IF IO.bActionDone THEN State : 50; ELSIF StepTimeout.Q THEN bError : TRUE; ErrorCode : 103; // 動(dòng)作超時(shí) END_IF; 50: // 可選的下料/剔除步驟僅部分機(jī)型啟用 IF Config.HasUnloader THEN IF IO.bUnloaderDone THEN State : 0; // 循環(huán)完成 bStepDone : TRUE; END_IF; ELSE State : 0; bStepDone : TRUE; END_IF; END_CASE;看見沒有FB里面從頭到尾沒有出現(xiàn)過如果是第3臺(tái)設(shè)備就怎樣、第7臺(tái)設(shè)備就怎樣的機(jī)型編號(hào)判斷。所有差異都通過Config里的BOOL開關(guān)、數(shù)組下標(biāo)、超時(shí)值來體現(xiàn)。這個(gè)設(shè)計(jì)的好處是當(dāng)你需要修改某個(gè)動(dòng)作順序時(shí)你只需要改這一個(gè)FB8種機(jī)型立刻全部生效不用再一臺(tái)一臺(tái)同步。缺點(diǎn)也很明顯——任何一次改動(dòng)影響的范圍從一臺(tái)設(shè)備變成了全部設(shè)備所以后面我會(huì)專門講版本管理和測(cè)試清單的配合。2.3 為什么這里選ST而不是梯形圖很多工程師習(xí)慣用梯形圖寫設(shè)備程序?qū)懙蕉鄼C(jī)型時(shí)容易順手在里面加幾條機(jī)型判斷的比較指令程序很快就變得不可讀。ST在這個(gè)場(chǎng)景下的優(yōu)勢(shì)不是高大上而是三個(gè)非常實(shí)際的點(diǎn)第一ST對(duì)數(shù)據(jù)結(jié)構(gòu)友好。UDT、數(shù)組、多維數(shù)組、結(jié)構(gòu)體嵌套這些操作在ST里就是很自然的字段訪問而在梯形圖里你需要在DB里逐個(gè)展開地址寫起來又長又容易錯(cuò)。第二ST對(duì)分支和循環(huán)的表達(dá)力強(qiáng)。CASE、IF-ELSIF-ELSE、FOR循環(huán)寫出來邏輯一目了然維護(hù)時(shí)能直接看到條件和分支的完整關(guān)系。第三ST代碼在版本管理工具里可以像普通文本一樣做差異對(duì)比。我用任何文本差異工具都能看到這個(gè)模板FB前后兩個(gè)版本改了什么而梯形圖導(dǎo)出成文本后對(duì)比效果很差。ST并不是萬能的比如位邏輯的簡單聯(lián)鎖你用梯形圖可能更直觀但當(dāng)一個(gè)FB要承載8種機(jī)型的狀態(tài)機(jī)時(shí)用ST寫狀態(tài)機(jī)必然是首選。2.4 IO差異處理見符號(hào)不見地址機(jī)型差異里最讓人頭疼的是IO數(shù)量不一樣、IO分配完全對(duì)不上。如果FB里直接寫%I0.5這種絕對(duì)地址換個(gè)機(jī)型程序立刻崩。所以我的IO處理原則是FB不碰任何物理地址全部通過一個(gè)叫做TYPE_IO_Interface的UDT作為接口層。這個(gè)UDT里定義的是語義化的BOOL量比如bHomeSwitch回原點(diǎn)到位、bGripperDone抓取完成、bActionDone動(dòng)作完成、bUnloaderDone下料完成以及一個(gè)REAL類型的rCurrentPos當(dāng)前軸位置。在主程序或OB1里每個(gè)機(jī)型實(shí)例化時(shí)都有自己的一張IO映射表把物理輸入點(diǎn)映射到這些語義信號(hào)上再把物理輸出點(diǎn)映射到動(dòng)作指令上。簡單說FB和物理IO之間隔了一層翻譯器型號(hào)差異被翻譯器消化掉了模板FB永遠(yuǎn)只跟語義信號(hào)打交道。這個(gè)思想跟面向?qū)ο罄锏慕涌诤芟馪LC界叫符號(hào)訪問但真正落地時(shí)關(guān)鍵不是有沒有符號(hào)而是你把物理映射放在哪個(gè)層級(jí)。我選擇放在上層專門做一個(gè)IO_Assign功能塊每個(gè)機(jī)型一份IO映射邏輯雖然這部分不能完全復(fù)用但它的體量比整個(gè)FB要小得多而且邏輯簡單純粹出錯(cuò)的概率也低。3. 落地實(shí)操從零搭出一個(gè)覆蓋8種機(jī)型的模板FB3.1 第一步把8種設(shè)備的工藝動(dòng)作用一張狀態(tài)圖抽象出來不要一開始就寫代碼。我的經(jīng)驗(yàn)和習(xí)慣是先拿A3紙把所有機(jī)型的工藝流程畫出來找到它們的公共骨架。我當(dāng)時(shí)那8種機(jī)型都屬于同一類貼裝設(shè)備雖然有的機(jī)型有視覺校驗(yàn)有的有自動(dòng)下料有的有雙工位但不管怎么變主干流程都繞不開準(zhǔn)備→回原點(diǎn)→取料→定位→執(zhí)行壓合動(dòng)作→檢查→放行。于是我把這個(gè)主干流程確定為狀態(tài)機(jī)的主路徑把那些部分機(jī)型才有的步驟設(shè)計(jì)成側(cè)分支。畫這個(gè)狀態(tài)圖的過程中最大的爭執(zhí)往往來自這個(gè)步驟到底是所有機(jī)型都有還是只有某幾臺(tái)有。我的判斷標(biāo)準(zhǔn)很簡單如果有一個(gè)動(dòng)作是至少兩臺(tái)設(shè)備共用并且出現(xiàn)在主流程相同位置我就把它放進(jìn)主狀態(tài)機(jī)如果它只在一臺(tái)設(shè)備上出現(xiàn)我就把它抽成可選步驟用Config里的BOOL字段控制。這樣既不會(huì)讓8種機(jī)型共用一個(gè)超級(jí)臃腫的狀態(tài)機(jī)也不會(huì)因?yàn)閭€(gè)別特例而破壞模板的整體性。3.2 第二步定義UDT和背景DB8種機(jī)型的參數(shù)差異怎么放公共骨架確定后下一步就是建立TYPE_MachineConfig這個(gè)UDT。我先列了一個(gè)8種機(jī)型差異清單把軸數(shù)、目標(biāo)位數(shù)量、動(dòng)作時(shí)間、有無校驗(yàn)機(jī)構(gòu)、有無下料機(jī)構(gòu)、有無安全門互鎖差異等信息全部列出來然后設(shè)計(jì)字段。關(guān)鍵技巧是數(shù)組字段要按最大的機(jī)型來定義。比如8種機(jī)型里軸數(shù)最多的是4軸那么TargetPositions就定義成ARRAY[1..4] OF REAL軸數(shù)少的機(jī)型只填前幾項(xiàng)其余默認(rèn)0但邏輯上不參與。這樣FB代碼里不需要根據(jù)軸數(shù)去動(dòng)態(tài)改變數(shù)組訪問的邊界只要用Config.ActiveTargetIndex來控制使用哪個(gè)目標(biāo)位置即可。建好UDT后我在程序塊里為8種機(jī)型分別建立了8個(gè)獨(dú)立的背景數(shù)據(jù)塊分別命名為DB_Machine201、DB_Machine202……每個(gè)背景塊里的Config字段類型都是TYPE_MachineConfig但實(shí)參值互不相同。PLC平臺(tái)在生成背景DB時(shí)會(huì)自動(dòng)帶上UDT的所有字段我只需要逐個(gè)填參數(shù)。這一步我必須強(qiáng)調(diào)一個(gè)坑不要圖省事讓8個(gè)實(shí)例共用同一個(gè)全局?jǐn)?shù)據(jù)塊那樣會(huì)出現(xiàn)一臺(tái)設(shè)備改參數(shù)、另外7臺(tái)也跟著變的事故。獨(dú)立的背景DB是隔離的基礎(chǔ)后面你要在線修改任何一臺(tái)設(shè)備的參數(shù)影響范圍都是這一個(gè)DB。3.3 第三步模板FB的ST骨架與三個(gè)關(guān)鍵設(shè)計(jì)技巧模板FB的骨架就是前面那段CASE狀態(tài)機(jī)代碼但真正讓它能穩(wěn)定覆蓋8種機(jī)型靠的是三個(gè)額外的設(shè)計(jì)技巧第一個(gè)技巧是主使能鏈條。我把總安全繼電器的狀態(tài)、手自動(dòng)切換狀態(tài)、急停狀態(tài)全部匯總成一個(gè)MasterEnable信號(hào)從FB外部串進(jìn)來FB內(nèi)部第一個(gè)CASE周期就會(huì)判斷Enable為FALSE時(shí)不管當(dāng)前狀態(tài)在哪一步立刻把輸出全部清零狀態(tài)機(jī)凍結(jié)。這個(gè)保證了不論哪臺(tái)機(jī)型安全優(yōu)先級(jí)永遠(yuǎn)最高不會(huì)出現(xiàn)因?yàn)閰?shù)差異導(dǎo)致某些設(shè)備在急停后還繼續(xù)動(dòng)作的情況。第二個(gè)技巧是步進(jìn)超時(shí)參數(shù)化。傳統(tǒng)做法是給整個(gè)程序?qū)懸粋€(gè)固定掃描超時(shí)但不同機(jī)型的節(jié)拍差別很大有的機(jī)型單循環(huán)8秒有的要25秒。我把每一步的超時(shí)時(shí)間都做成了Config里可配置的TimeoutXx字段調(diào)試時(shí)根據(jù)每臺(tái)設(shè)備的實(shí)際節(jié)拍微調(diào)避免誤報(bào)警。第三個(gè)技巧是錯(cuò)誤碼統(tǒng)一編碼。ErrorCode的前兩位是步驟號(hào)機(jī)構(gòu)號(hào)后三位是具體原因比如102定位超時(shí)、201抓取失敗。8種機(jī)型共用這套編碼HMI報(bào)警界面不需要針對(duì)每個(gè)機(jī)型做不同文本映射這又省了一大塊維護(hù)量。3.4 第四步在OB1里實(shí)例化8次一個(gè)模板吃8份數(shù)據(jù)數(shù)據(jù)層準(zhǔn)備好后程序集成就變得非常樸素在OB1里連續(xù)調(diào)用FB_DeviceTemplate八次每次把對(duì)應(yīng)的背景DB包含各自Config和IO映射作為實(shí)參傳進(jìn)去// 在OB1主程序中的調(diào)用示意 FB_DeviceTemplate_Instance_201( Enable : MasterEnable, bStart : HMI_Start_201, bStop : HMI_Stop_201, Config : DB_Machine201.Config, IO : DB_Machine201.IO ); FB_DeviceTemplate_Instance_202( Enable : MasterEnable, bStart : HMI_Start_202, bStop : HMI_Stop_202, Config : DB_Machine202.Config, IO : DB_Machine202.IO );這里要注意TIA這類平臺(tái)允許同一個(gè)FB生成多個(gè)實(shí)例化調(diào)用每個(gè)調(diào)用自動(dòng)帶一份獨(dú)立的內(nèi)部變量存儲(chǔ)區(qū)。我的習(xí)慣是給8個(gè)調(diào)用分別命名為Instance_201到Instance_208方便監(jiān)控時(shí)一眼看出哪臺(tái)設(shè)備在哪個(gè)狀態(tài)。這一步做完理論上整套系統(tǒng)就已經(jīng)能跑起來了。我第一次實(shí)際下載運(yùn)行那天8臺(tái)設(shè)備先后上電第一臺(tái)走完一個(gè)完整循環(huán)后后面的7臺(tái)逐個(gè)跑通那種同一份代碼跑出不同動(dòng)作的感覺確實(shí)很爽但也馬上迎來了第二個(gè)問題——現(xiàn)場(chǎng)調(diào)試時(shí)有些怪毛病根本不是程序邏輯錯(cuò)而是數(shù)據(jù)填錯(cuò)了。4. 8種機(jī)型到底差在哪數(shù)據(jù)解決90%邏輯解決10%4.1 用數(shù)據(jù)就能搞定的差異很多人聽到一個(gè)FB覆蓋8種機(jī)型會(huì)覺得不可思議其實(shí)是因?yàn)樗麄儼巡町惗籍?dāng)成了邏輯差異實(shí)際上80%到90%的機(jī)型差異都只是參數(shù)差異。我按實(shí)際項(xiàng)目列個(gè)清單第一類是時(shí)間類差異。不同機(jī)型的目標(biāo)節(jié)拍不同、動(dòng)作時(shí)間不同、等待時(shí)間不同這些全部進(jìn)入Config的REAL字段。第二類是位置類差異。8種機(jī)型的幾個(gè)定位點(diǎn)完全不同把它們做進(jìn)TargetPositions數(shù)組每個(gè)機(jī)型填自己的坐標(biāo)。第三類是數(shù)量類差異。軸數(shù)、工位數(shù)、點(diǎn)位數(shù)量不同時(shí)用數(shù)組和ActiveTargetIndex來控制當(dāng)前使用哪個(gè)。第四類是機(jī)構(gòu)選配差異。某幾臺(tái)設(shè)備帶下料剔除機(jī)構(gòu)某幾臺(tái)帶視覺校驗(yàn)這些用BOOL開關(guān)控制程序只在開關(guān)為TRUE時(shí)才執(zhí)行對(duì)應(yīng)分支段。第五類是通訊地址和IO分配差異這部分放進(jìn)IO映射層解決不讓模板FB感知。這里最核心的思路是參數(shù)差異的本質(zhì)是同一種動(dòng)作的不同數(shù)值邏輯差異的本質(zhì)是動(dòng)作是否存在或動(dòng)作順序不同。前者完全不值得用代碼區(qū)分給數(shù)據(jù)就行后者才需要謹(jǐn)慎設(shè)計(jì)分支。4.2 必須用邏輯分支處理的例外那10%的邏輯差異是什么樣我項(xiàng)目里的實(shí)際例子有兩個(gè)。一個(gè)是有視覺校驗(yàn)功能的機(jī)型在定位完成后、執(zhí)行動(dòng)作前要插入一個(gè)拍照并等待結(jié)果的步驟這個(gè)步驟不僅影響狀態(tài)機(jī)的走向還涉及視覺信號(hào)交互。另一個(gè)是雙工位機(jī)型會(huì)在主流程里多出一個(gè)工位切換的并行操作。處理這些例外時(shí)我沒有把它們從模板FB里剝出去而是讓它們?cè)跔顟B(tài)機(jī)里以可選步驟的方式存在。以視覺校驗(yàn)為例我在狀態(tài)機(jī)里保留了一個(gè)標(biāo)記為校驗(yàn)站的狀態(tài)節(jié)點(diǎn)State35前面用IF Config.HasVisionCheck THEN引導(dǎo)進(jìn)入否則跳過。這樣模板FB仍然是唯一的主邏輯載體例外動(dòng)作只是這條主線上的旁支。這個(gè)方法的前提是例外數(shù)量可控如果一個(gè)FB里插了七八個(gè)例外分支狀態(tài)機(jī)會(huì)變得沒人能看懂那時(shí)候就要考慮拆成基礎(chǔ)模板FB擴(kuò)展功能FB的組合結(jié)構(gòu)了。4.3 一張表看清楚8種機(jī)型的差異歸屬我把當(dāng)時(shí)整理的差異歸屬表簡化后放在這里方便大家參考這個(gè)分析的粒度機(jī)型代號(hào)軸數(shù)量目標(biāo)位數(shù)量有無視覺校驗(yàn)有無下料剔除有無雙工位節(jié)拍目標(biāo)差異歸屬M(fèi)20122無無無8s數(shù)據(jù)M20223有無無12s數(shù)據(jù)邏輯視覺M20334無有無10s數(shù)據(jù)邏輯下料M20434有有無15s數(shù)據(jù)邏輯視覺下料M20546無有有20s數(shù)據(jù)邏輯下料雙工位M20646有有有25s數(shù)據(jù)邏輯全選配M20722無無無8s數(shù)據(jù)與M201同一模板M20835有無有18s數(shù)據(jù)邏輯視覺雙工位這張表是我和團(tuán)隊(duì)討論了兩輪才定下來的。定完之后我就能精確告訴客戶和同事哪幾臺(tái)的差異只需要填數(shù)據(jù)哪幾臺(tái)需要多寫一小段可選邏輯新增機(jī)型時(shí)也照這個(gè)思路先做差異歸屬分析再?zèng)Q定要不要?jiǎng)覨B。5. 換型調(diào)試現(xiàn)場(chǎng)填錯(cuò)數(shù)據(jù)比寫錯(cuò)程序更常見5.1 一次IO映射錯(cuò)誤引發(fā)的誤動(dòng)作排查全過程模板FB跑通以后現(xiàn)場(chǎng)調(diào)試的主要矛盾就從寫邏輯變成了填數(shù)據(jù)、配映射。我記得調(diào)試第5臺(tái)雙工位機(jī)型時(shí)出現(xiàn)了間歇性誤啟動(dòng)有時(shí)候按下啟動(dòng)按鈕設(shè)備不動(dòng)有時(shí)候剛完成一次循環(huán)又自動(dòng)觸發(fā)第二次。第一反應(yīng)以為是狀態(tài)機(jī)復(fù)位邏輯有問題查了半小時(shí)代碼沒查出異常。后來打開IO映射導(dǎo)出的表格一比對(duì)發(fā)現(xiàn)該機(jī)型背景DB里的bUnloaderDone下料完成信號(hào)被映射到了某個(gè)物理輸入點(diǎn)而那個(gè)輸入點(diǎn)實(shí)際上接的是安全門到位信號(hào)。下料機(jī)構(gòu)還沒動(dòng)安全門一關(guān)程序就以為下料完成了于是狀態(tài)機(jī)提前放行緊接著又啟動(dòng)下一循環(huán)。這類問題的根源在于模板FB把物理IO藏起來了人機(jī)界面看到的全是語義信號(hào)一旦物理點(diǎn)位重新分配或接線調(diào)整映射表必須人工同步。建議是每次換型接線后先做一次信號(hào)強(qiáng)制測(cè)試——把每個(gè)輸入點(diǎn)逐個(gè)強(qiáng)制核對(duì)HMI監(jiān)控畫面上的語義信號(hào)是否跟著變化全部對(duì)上號(hào)再跑自動(dòng)流程。這個(gè)步驟看起來土但對(duì)排查這類數(shù)據(jù)錯(cuò)誤非常高效。5.2 在線修改、熱下載與庫更新的坑多機(jī)型模板FB有一個(gè)隱形的管理難題你改了模板FB8個(gè)實(shí)例會(huì)同時(shí)變但理論上是同時(shí)變實(shí)際下載時(shí)PLC可不一定允許你一次全刷下來。在線修改和熱下載在不同平臺(tái)有不同限制有些情況下你改了變量表或背景DB的數(shù)據(jù)類型就需要停機(jī)下載全量程序而不能后臺(tái)熱更新。我在項(xiàng)目中碰到過一次現(xiàn)場(chǎng)正在生產(chǎn)我想給模板FB加一個(gè)報(bào)警提示字段結(jié)果這個(gè)字段的修改牽動(dòng)了背景DB的結(jié)構(gòu)PLC提示無法在線修改需要初始下載。那天的經(jīng)驗(yàn)讓我明白涉及數(shù)據(jù)結(jié)構(gòu)變更的改動(dòng)必須提前計(jì)劃停機(jī)窗口別指望所有優(yōu)化都能在線熱更新。另一個(gè)經(jīng)驗(yàn)是庫更新傳播。如果你把模板FB做成了可復(fù)用的庫元件每次改完庫后所有項(xiàng)目的引用不會(huì)自動(dòng)更新需要手動(dòng)執(zhí)行更新庫元件版本的操作。我見過有同事改了庫元件忘了同步導(dǎo)致8臺(tái)設(shè)備有5臺(tái)在用新邏輯、3臺(tái)還在跑舊邏輯。所以我的管理習(xí)慣是庫元件每次修改都記錄版本號(hào)項(xiàng)目里統(tǒng)一在發(fā)布前檢查引用版本現(xiàn)場(chǎng)版本不一致時(shí)用程序頭部的FirmwareVersion字段做對(duì)比一眼就能看出哪臺(tái)固件落后了。5.3 8個(gè)實(shí)例同時(shí)工作的掃描周期壓力實(shí)測(cè)有人會(huì)擔(dān)心一個(gè)FB被調(diào)用8次CPU掃描周期會(huì)不會(huì)扛不住。實(shí)際測(cè)下來純邏輯指令的負(fù)載非常小ST的CASE狀態(tài)機(jī)和IF判斷在PLC里都是布爾和整數(shù)運(yùn)算8個(gè)實(shí)例加一起也就幾百條指令現(xiàn)代CPU完全無壓力。真正的壓力來自兩個(gè)地方一是背景DB的數(shù)據(jù)量大如果UDT里塞了幾百個(gè)REAL數(shù)組字段8個(gè)DB加起來內(nèi)存占用可觀但PLC內(nèi)存通常也不是瓶頸二是如果有通訊指令比如和視覺、機(jī)器人通訊每個(gè)實(shí)例都收發(fā)數(shù)據(jù)時(shí)通訊處理時(shí)間可能遠(yuǎn)超邏輯掃描時(shí)間。這種情況我建議把通訊從模板FB里摘出去單獨(dú)用通訊管理塊模板FB只讀取已經(jīng)更新好的通訊結(jié)果避免一個(gè)FB又要跑工藝又要等通訊導(dǎo)致的時(shí)序混亂。5.4 規(guī)范化調(diào)試的幾條清單經(jīng)歷了這一輪8機(jī)型的調(diào)試我沉淀了一套調(diào)試前檢查清單核心幾條是先核對(duì)IO映射表與端子接線圖再核對(duì)8份背景DB的參數(shù)是不是按不同機(jī)型的銘牌填寫接著做一次所有輸入信號(hào)的強(qiáng)制測(cè)試然后手動(dòng)單步走一遍每個(gè)機(jī)型的狀態(tài)機(jī)最后才能允許自動(dòng)循環(huán)。這套清單在第一次跑通后我反復(fù)用了好幾輪每次都能在正式啟動(dòng)前揪出至少一兩個(gè)參數(shù)填錯(cuò)的問題比到時(shí)候停機(jī)強(qiáng)太多。6. 再往前走一步從機(jī)種模板到平臺(tái)化維護(hù)6.1 新增一種機(jī)型代碼要改幾處這是評(píng)估這套架構(gòu)最直接的試金石。在我這套方案里新增一種機(jī)型需要改動(dòng)的代碼量基本是零要做的事只有三件第一在HMI或全局配置里增加一個(gè)機(jī)型編號(hào)第二復(fù)制一份背景DB并改成新機(jī)型名第三把新機(jī)型的工藝參數(shù)和IO映射填進(jìn)去。如果新機(jī)型帶有全新的選配機(jī)構(gòu)還需要在模板FB里加一個(gè)可選步驟分支但這種情況通常是少數(shù)。換句話說一個(gè)FB覆蓋8種機(jī)型不是一個(gè)終點(diǎn)它更大價(jià)值在于新機(jī)型開局只需要處理數(shù)據(jù)不需要?jiǎng)舆壿嬤@對(duì)設(shè)備廠快速響應(yīng)新需求的意義非常實(shí)際。6.2 用配方表批量生成實(shí)例DB的參數(shù)當(dāng)機(jī)型數(shù)量繼續(xù)增長到十幾、二十臺(tái)時(shí)人工填DB參數(shù)不僅費(fèi)時(shí)還容易錯(cuò)。我的做法是把TYPE_MachineConfig的字段做成一張Excel配方表用工程腳本把表格內(nèi)容自動(dòng)生成PLC數(shù)據(jù)塊的初始化文件或者導(dǎo)入到配方變量里。這樣新機(jī)型到達(dá)時(shí)工藝工程師在Excel里做完參數(shù)生成配置文件我再導(dǎo)入工程背景DB的初始值和配方就全部就位。這個(gè)流程的重點(diǎn)是Excel的列頭必須和UDT字段名完全對(duì)齊否則腳本轉(zhuǎn)換時(shí)報(bào)錯(cuò)后你得一條條查反而比手工填更慢。6.3 報(bào)警、HMI畫面和MES接口的聯(lián)動(dòng)復(fù)用模板FB幫我們把控制邏輯收斂了報(bào)警、HMI畫面和MES通訊也應(yīng)該跟著復(fù)用。我的做法是讓模板FB輸出一個(gè)統(tǒng)一的MachineStatus結(jié)構(gòu)體里面包含當(dāng)前狀態(tài)編號(hào)、當(dāng)前步驟編號(hào)、錯(cuò)誤碼、運(yùn)行計(jì)數(shù)等HMI畫面讀取這個(gè)結(jié)構(gòu)體不同機(jī)型共用同一張主畫面只是底層的DB實(shí)例不同。MES接口也類似上位機(jī)只需要和統(tǒng)一的DB結(jié)構(gòu)打交道不必關(guān)心當(dāng)前連的是哪臺(tái)機(jī)器。這個(gè)結(jié)構(gòu)體接口的思路和前面IO接口層的思路是一脈相承的定義好契約內(nèi)部差異再大也不影響外部交互。6.4 個(gè)人維護(hù)這個(gè)庫兩年的三點(diǎn)體會(huì)前陣子我又把這兩年的維護(hù)記錄翻了一遍最想分享的體會(huì)是模板FB不是一上來就要設(shè)計(jì)得完美無缺而是先用一個(gè)合理的骨架圈住80%的共性然后在每個(gè)新機(jī)型到來時(shí)小步演進(jìn)。我第一版只覆蓋了3種機(jī)型過程里發(fā)現(xiàn)選配機(jī)構(gòu)開關(guān)這個(gè)設(shè)計(jì)后才逐步擴(kuò)展成覆蓋8種。二是每次改動(dòng)模板FB都必須全量回歸測(cè)試哪怕只是加一個(gè)字段也要把8臺(tái)設(shè)備的典型流程各跑一遍我建議把這一步寫進(jìn)項(xiàng)目流程。三是模板FB的價(jià)值要到第二、第三個(gè)項(xiàng)目才能真正體現(xiàn)同一套架構(gòu)如果只服務(wù)一個(gè)項(xiàng)目前期投入可能不劃算但一旦你面對(duì)的是持續(xù)交付的機(jī)型族這套架構(gòu)就是降低維護(hù)成本的真正杠桿。