接了個(gè)水泵站項(xiàng)目四個(gè)泵兩個(gè)變頻兩個(gè)工頻現(xiàn)場控制邏輯大同小異。我剛?cè)胄心菚?huì)兒圖省事每個(gè)泵都單獨(dú)寫一段梯形圖一個(gè)子程序能堆到三四百行。改個(gè)延時(shí)時(shí)間得翻半天程序甲方說再加一臺(tái)泵我整個(gè)人是崩潰的。后來第二期項(xiàng)目我咬著牙把所有泵的邏輯重構(gòu)成結(jié)構(gòu)體UDT加功能塊FB的寫法PLC編程效率提升是肉眼可見的后期維護(hù)更是省心不止一點(diǎn)。這篇文章就圍繞“UDTFB”這套模塊化做法展開聊聊為什么PLC程序會(huì)“越寫越亂”、UDT和FB到底解決什么問題、兩者怎么配合落地以及我在實(shí)際項(xiàng)目中踩過的坑。適合那些已經(jīng)能獨(dú)立寫梯形圖或SCL但程序還停留在“一份代碼復(fù)制N遍”階段的工程師也適合剛轉(zhuǎn)行做PLC編程、想從一開始就建立良好編程習(xí)慣的朋友。目錄邏輯我會(huì)按“為什么要模塊化、UDT怎么用、FB怎么用、UDTFB組合實(shí)戰(zhàn)、常見問題排查”這樣走盡量把原理、代碼、排錯(cuò)都串起來讓你看完能直接上手改自己的程序。1. 為什么PLC程序需要模塊化很多初學(xué)者會(huì)有個(gè)錯(cuò)覺PLC程序嘛變量多、邏輯雜能跑起來就行。確實(shí)單機(jī)設(shè)備、幾十個(gè)I/O點(diǎn)的情況下怎么寫都行。但一旦進(jìn)入多工位、多設(shè)備的產(chǎn)線級(jí)項(xiàng)目程序的可讀性、可維護(hù)性、可擴(kuò)展性就會(huì)決定項(xiàng)目成敗。1.1 復(fù)制粘貼式編程的災(zāi)難我見過最夸張的一個(gè)項(xiàng)目12臺(tái)相同的風(fēng)機(jī)工程師把風(fēng)機(jī)啟停程序復(fù)制了12份每個(gè)程序段里變量名就是FAN1_START、FAN2_START、FAN3_START……一直到FAN12_START。改一個(gè)保護(hù)邏輯就得同時(shí)修改12份程序漏改一個(gè)就會(huì)出問題。這種“復(fù)制、粘貼、改變量”的編程方式短期開發(fā)看似快后期維護(hù)成本是成倍增長的。更麻煩的是這種程序占用的存儲(chǔ)空間很大掃描周期也會(huì)被拉長。在S7-1200這類中低端CPU上程序段多了在線監(jiān)控都會(huì)卡頓。而且團(tuán)隊(duì)成員之間協(xié)作時(shí)別人拿了你的程序光搞清楚FAN7和FAN8之間的細(xì)微差別就要花大力氣。1.2 模塊化的核心收益模塊化的本質(zhì)是把“數(shù)據(jù)”和“邏輯”都封裝成可復(fù)用的單元。數(shù)據(jù)上用結(jié)構(gòu)體UDT統(tǒng)一格式邏輯上用功能塊FB統(tǒng)一行為。這樣帶來三個(gè)直接好處復(fù)用性一個(gè)泵控FB寫好100臺(tái)泵就是100個(gè)實(shí)例不用重復(fù)寫邏輯?？删S護(hù)性修改FB內(nèi)部邏輯所有實(shí)例同步更新不用逐個(gè)程序段去改?？蓞f(xié)作性程序結(jié)構(gòu)清楚團(tuán)隊(duì)分工明確你寫電機(jī)FB、我寫閥門FB最后拼裝即可。這里要區(qū)分一下PLC的模塊化與高級(jí)語言里的“函數(shù)庫”思想是一致的。你寫C語言不會(huì)把同一個(gè)函數(shù)復(fù)制100份而是定義函數(shù)再調(diào)用。PLC里的UDT和FB就是PLC世界的“結(jié)構(gòu)體定義”和“類方法”。2. 結(jié)構(gòu)體UDT把松散的數(shù)據(jù)綁在一起UDTUser Defined Type在西門子TIA Portal里叫“PLC數(shù)據(jù)類型”在三菱GX Works3里叫“結(jié)構(gòu)體”在歐姆龍Sysmac Studio里也叫“結(jié)構(gòu)體”。名字不同意思一樣把一組不同類型但邏輯相關(guān)的數(shù)據(jù)打包成一個(gè)整體。2.1 UDT到底是什么打個(gè)比方你要管理一個(gè)倉庫最原始的方式是拿一個(gè)本子把所有貨物的名稱、數(shù)量、位置、入庫日期都記在流水賬里。找一樣?xùn)|西要翻半天。UDT相當(dāng)于你把倉庫劃分成若干貨架每個(gè)貨架上有固定的格子每種貨物放在自己專屬的位置上。你只要知道貨架編號(hào)就能直接找到所有相關(guān)信息。在PLC里定義一個(gè)電機(jī)相關(guān)的UDT大概包含這些成員Motor_UDT ├── CMD命令區(qū) │ ├── StartCmd : Bool │ ├── StopCmd : Bool │ ├── ResetCmd : Bool ├── ST狀態(tài)區(qū) │ ├── Running : Bool │ ├── Fault : Bool │ ├── Ready : Bool ├── PARAM參數(shù)區(qū) │ ├── StartDelay : Time │ ├── RatedCurrent : Real │ └── OverloadThreshold : Real └── STAT統(tǒng)計(jì)區(qū) └── TotalRunTime : Real有了這樣一個(gè)UDT你在創(chuàng)建電機(jī)變量時(shí)不需要再單獨(dú)建立十幾個(gè)獨(dú)立的Bool、Real變量而是直接聲明一個(gè)Motor1 : Motor_UDT。電機(jī)1的所有信息都通過Motor1.CMD.StartCmd、Motor1.ST.Running這種層級(jí)方式訪問清爽又直觀。2.2 在TIA Portal里定義UDT以西門子S7-1200/1500為例三菱、歐姆龍的操作思路完全一致定義步驟是在項(xiàng)目樹中找到“PLC數(shù)據(jù)類型”右鍵→“添加新數(shù)據(jù)類型”取個(gè)名字比如Pump_UDT。然后在打開的編輯表中輸入成員名稱選擇數(shù)據(jù)類型填初始值和注釋。這里有個(gè)關(guān)鍵點(diǎn)成員順序會(huì)直接影響數(shù)據(jù)的存儲(chǔ)布局。雖然對(duì)運(yùn)行邏輯影響不大但對(duì)在線監(jiān)控時(shí)的可讀性影響很大建議按“命令→狀態(tài)→參數(shù)→預(yù)留”的順序排列和現(xiàn)場端子排布保持一致的對(duì)應(yīng)關(guān)系。2.3 UDT的進(jìn)階玩法嵌套與數(shù)組UDT之間可以互相嵌套。比如你定義了一個(gè)Motor_UDT然后要做一個(gè)多電機(jī)的泵站可以再定義PumpStation_UDT ├── Motor1 : Motor_UDT ├── Motor2 : Motor_UDT ├── Motor3 : Motor_UDT └── InletValve : Valve_UDT這樣整個(gè)泵站就是一個(gè)變量所有子設(shè)備的數(shù)據(jù)都在其中。HMI組態(tài)時(shí)變量表結(jié)構(gòu)也能保持同樣的層級(jí)關(guān)系觸摸屏那邊的變量連接效率也更高。UDT數(shù)組也極其實(shí)用。比如有4臺(tái)泵你直接定義Pump : Array[1..4] of Pump_UDT然后程序里可以用FOR循環(huán)遍歷查找當(dāng)前運(yùn)行狀態(tài)統(tǒng)計(jì)運(yùn)行中泵數(shù)量 FOR i : 1 TO 4 DO IF Pump[i].ST.Running THEN RunningCount : RunningCount 1; END_IF; END_FOR;用數(shù)組的思路配合后文要講的FB是實(shí)現(xiàn)設(shè)備輪換、組啟動(dòng)、組停止的利器。2.4 UDT定義的注意事項(xiàng)UDT看似簡單但實(shí)際使用中很容易踩坑。我總結(jié)幾條經(jīng)驗(yàn)預(yù)留擴(kuò)展區(qū)在UDT末尾加一段Reserve : Array[0..15] of Byte。項(xiàng)目后期要增加通道、增加參數(shù)時(shí)直接使用預(yù)留區(qū)可以避免修改UDT定義導(dǎo)致CPU停機(jī)或背景DB結(jié)構(gòu)變化。命名要有區(qū)分度“CMD”和“ST”這兩個(gè)區(qū)組名很好用一看就知道是命令還是狀態(tài)。不要取“DATA1、DATA2、DATA3”這種序號(hào)式命名維護(hù)時(shí)猜猜猜太痛苦。注釋寫單位Real類型成員必須寫上單位比如RatedCurrent : Real注釋寫成“額定電流單位A”。否則幾個(gè)月后你自己看著這個(gè)變量都不知道該填什么數(shù)。3. 功能塊FB有記憶的程序塊FB是Function Block翻譯為“函數(shù)塊”或“功能塊”。它和FCFunction最大的區(qū)別在于FB擁有自己獨(dú)立的數(shù)據(jù)存儲(chǔ)區(qū)也就是背景數(shù)據(jù)塊Instance DB。簡單說FB有“記憶”FC沒有“記憶”。3.1 FB和FC怎么選入門工程師最容易搞混的就是FB和FC。我習(xí)慣用一個(gè)“儲(chǔ)物柜”的比喻FC就像一個(gè)沒有儲(chǔ)物柜的臨時(shí)工你給他一個(gè)輸入他現(xiàn)場算完給你一個(gè)輸出干完就走什么都不留。FB則自己帶一個(gè)專屬儲(chǔ)物柜干完活會(huì)把中間變量、狀態(tài)值工整地放進(jìn)柜子里存好下次再進(jìn)來能接著上次的狀態(tài)繼續(xù)干活。實(shí)際項(xiàng)目中設(shè)備級(jí)控制邏輯——如電機(jī)啟停、閥門動(dòng)作、伺服定位——一律用FB因?yàn)樵O(shè)備有“當(dāng)前狀態(tài)”數(shù)學(xué)計(jì)算、數(shù)據(jù)類型轉(zhuǎn)換、簡單比較——用FC就夠因?yàn)檫@類功能不依賴歷史狀態(tài)。三菱PLC里也有類似的區(qū)分FB還是叫FB和西門子的FB一個(gè)概念但三菱沒有嚴(yán)格對(duì)應(yīng)FC的“無狀態(tài)”函數(shù)概念早期多用子程序和宏歐姆龍則既支持功能塊也支持無記憶的功能。各大品牌思路一致只是叫法略有不同。3.2 FB的接口設(shè)計(jì)先想好“外立面”FB的接口就是它的“外立面”是別人調(diào)用時(shí)能看到的窗口。設(shè)計(jì)FB接口時(shí)分這么幾類VAR_INPUT輸入由外部傳入如啟動(dòng)命令、停止命令、使能信號(hào)。VAR_OUTPUT輸出由FB內(nèi)部計(jì)算后輸出給外部如運(yùn)行指示、故障指示、輸出到接觸器的指令。VAR_IN_OUT輸入輸出兼有適合傳結(jié)構(gòu)體。這個(gè)很關(guān)鍵——你可以把整個(gè)Pump_UDT作為IN_OUT傳給FBFB內(nèi)部可以直接讀寫它的成員。VAR_STATFB內(nèi)部的靜態(tài)變量保存在背景DB中掉電保持或掃描間保持。VAR_TEMP臨時(shí)變量執(zhí)行完本周期就清零不保存。接口設(shè)計(jì)的核心原則是FB要盡量“自包含”。也就是說外部只負(fù)責(zé)給命令和讀狀態(tài)具體內(nèi)部怎么判斷、怎么延時(shí)、怎么互鎖都封裝在FB里。一個(gè)標(biāo)準(zhǔn)的泵控FB接口大概長這樣FUNCTION_BLOCK FB_PumpControl VAR_INPUT Enable : Bool; // 總使能 StartCmd : Bool; // 啟動(dòng)命令 StopCmd : Bool; // 停止命令 AutoMode : Bool; // 自動(dòng)模式 RunFb : Bool; // 運(yùn)行反饋 FaultSig : Bool; // 故障信號(hào) END_VAR VAR_OUTPUT RunCmd : Bool; // 運(yùn)行指令輸出 FaultOut : Bool; // 故障輸出 END_VAR VAR_IN_OUT PumpIO : Pump_UDT; // 泵的數(shù)據(jù)結(jié)構(gòu) END_VAR VAR_STAT step : Int; // 狀態(tài)機(jī)當(dāng)前步 tDelay : TON; // 延時(shí)定時(shí)器 END_VAR3.3 FB內(nèi)部邏輯狀態(tài)機(jī)寫法讓邏輯徹底清晰FB內(nèi)部邏輯組織我非常推薦“狀態(tài)機(jī)”寫法這也是搜索結(jié)果中“PLC編程狀態(tài)機(jī)寫法”這個(gè)熱詞對(duì)應(yīng)的核心內(nèi)容。狀態(tài)機(jī)的思想其實(shí)很簡單設(shè)備任何時(shí)刻都處在有限個(gè)狀態(tài)之一每個(gè)狀態(tài)只處理自己的事情條件滿足就切換狀態(tài)。用泵控來舉例狀態(tài)可以分成空閑IDLE→ 啟動(dòng)延時(shí)START_DELAY→ 運(yùn)行RUNNING→ 停止延時(shí)STOP_DELAY→ 故障FAULT。梯形圖寫這種狀態(tài)機(jī)會(huì)很啰嗦SCL會(huì)優(yōu)雅很多核心就是CASE語句CASE step OF 0: // IDLE IF StartCmd AND NOT RunFb AND NOT FaultSig THEN step : 1; tDelay(IN : FALSE); END_IF; 1: // START_DELAY tDelay(IN : TRUE, PT : PumpIO.PARAM.StartDelay); IF tDelay.Q THEN RunCmd : TRUE; step : 2; END_IF; IF StopCmd OR FaultSig THEN step : 0; END_IF; 2: // RUNNING IF FaultSig THEN RunCmd : FALSE; step : 3; ELSIF StopCmd OR NOT RunFb THEN RunCmd : FALSE; step : 0; END_IF; 3: // FAULT IF PumpIO.CMD.ResetCmd THEN step : 0; END_IF; END_CASE;特別提醒狀態(tài)機(jī)的變量只在狀態(tài)切換的瞬間賦值其他情況下不要反復(fù)寫否則一個(gè)掃描周期內(nèi)可能出現(xiàn)“狀態(tài)還沒啟動(dòng)延時(shí)延時(shí)定時(shí)器就被Clear”的古怪問題。這也是為什么靜態(tài)變量step要單獨(dú)聲明——它代表了FB的“記憶”。4. 實(shí)戰(zhàn)UDTFB組合完成一臺(tái)泵的模塊化控制理論講完下面用一套完整的三泵聯(lián)動(dòng)項(xiàng)目案例把UDT和FB的組合應(yīng)用串起來。這臺(tái)泵的需求不完全一樣兩用一備手動(dòng)/自動(dòng)切換故障自動(dòng)切泵運(yùn)行時(shí)間累計(jì)。4.1 第一步定義泵的數(shù)據(jù)結(jié)構(gòu)在TIA Portal的“PLC數(shù)據(jù)類型”里新建Pump_UDT。包含以下成員Pump_UDT ├── CMD命令區(qū) │ ├── StartRemote : Bool; // 遠(yuǎn)程啟動(dòng) │ ├── StopRemote : Bool; // 遠(yuǎn)程停止 │ ├── ResetFault : Bool; // 復(fù)位故障 │ ├── AutoMode : Bool; // 自動(dòng)模式1自動(dòng)/0手動(dòng) ├── ST狀態(tài)區(qū) │ ├── RunFb : Bool; // 運(yùn)行反饋 │ ├── FaultSig : Bool; // 故障信號(hào) │ ├── Running : Bool; // 運(yùn)行狀態(tài) │ ├── Fault : Bool; // 故障狀態(tài) ├── PARAM參數(shù)區(qū) │ ├── StartDelay : Time; // 啟動(dòng)延時(shí) │ ├── StopDelay : Time; // 停止延時(shí) │ ├── MinRunTime : Time; // 最小運(yùn)行時(shí)間 ├── STAT統(tǒng)計(jì)區(qū) │ └── TotalRunTime : Real; // 累計(jì)運(yùn)行時(shí)間小時(shí) └── Reserve預(yù)留區(qū) └── Reserve : Array[0..7] of Byte;注意這里我把“狀態(tài)區(qū)”和“統(tǒng)計(jì)區(qū)”分開了。為什么因?yàn)闋顟B(tài)區(qū)是實(shí)時(shí)刷新、掉電重置的統(tǒng)計(jì)區(qū)則需要保持后續(xù)編程時(shí)對(duì)掉電保持區(qū)域的規(guī)劃會(huì)更清晰。4.2 第二步封裝泵控FB新建FB命名FB_PumpControl。接口按3.2節(jié)設(shè)計(jì)內(nèi)部邏輯用狀態(tài)機(jī)。下面補(bǔ)充兩個(gè)關(guān)鍵環(huán)節(jié)。手動(dòng)/自動(dòng)切換AutoMode為TRUE時(shí)FB只接收外部聯(lián)鎖邏輯送來的StartRemote/StopRemoteAutoMode為FALSE時(shí)FB只接收就地按鈕信號(hào)。這里不建議手動(dòng)信號(hào)和自動(dòng)信號(hào)混用否則容易出現(xiàn)“自動(dòng)狀態(tài)下手動(dòng)按鈕也能啟泵”的安全隱患。累計(jì)運(yùn)行時(shí)間在RUNNING狀態(tài)下每個(gè)掃描周期做一次累加。如果直接每次加1單位是掃描周期非常不直觀。更穩(wěn)的做法是調(diào)用系統(tǒng)時(shí)鐘計(jì)算兩次掃描之間的時(shí)間差// 使用系統(tǒng)時(shí)間差累計(jì) nowTime : DINT_TO_LREAL( TIME_TO_DINT( T_PLC_MS() ) ); IF step 2 THEN PumpIO.STAT.TotalRunTime : PumpIO.STAT.TotalRunTime (nowTime - lastTime) / 3600000.0; END_IF; lastTime : nowTime;T_PLC_MS()是讀取CPU運(yùn)行毫秒數(shù)的系統(tǒng)函數(shù)不同的PLC品牌有各自的系統(tǒng)時(shí)鐘讀取方式但原理一樣。這個(gè)寫法比每周期加常數(shù)要精確得多也不會(huì)因?yàn)镃PU掃描周期波動(dòng)導(dǎo)致累計(jì)時(shí)間偏差。4.3 第三步實(shí)例化FB并建立泵組調(diào)度在主程序OB1中創(chuàng)建3臺(tái)泵的數(shù)據(jù)結(jié)構(gòu)和FB實(shí)例。以下是我在FC調(diào)用邏輯里的寫法VAR PumpData : Array[1..3] of Pump_UDT; fbPump1 : FB_PumpControl; fbPump2 : FB_PumpControl; fbPump3 : FB_PumpControl; END_VAR然后分別在網(wǎng)絡(luò)段里調(diào)用// 泵1 fbPump1( Enable : TRUE, StartCmd : PumpData[1].CMD.StartRemote, StopCmd : PumpData[1].CMD.StopRemote, AutoMode : PumpData[1].CMD.AutoMode, RunFb : PumpData[1].ST.RunFb, FaultSig : PumpData[1].ST.FaultSig, RunCmd PumpData[1].ST.Running, FaultOut PumpData[1].ST.Fault, PumpIO : PumpData[1] );3臺(tái)泵就是3個(gè)FB實(shí)例程序段幾乎一模一樣。后續(xù)如果要加第4臺(tái)泵復(fù)制一個(gè)調(diào)用加上對(duì)應(yīng)數(shù)據(jù)和變量5分鐘搞定。輪換邏輯放在另一個(gè)FC里做。核心思路是自動(dòng)模式下如果當(dāng)前運(yùn)行泵故障在泵組中查找“累計(jì)運(yùn)行時(shí)間最短”且“無故障”的泵作為下一臺(tái)啟動(dòng)對(duì)象。這個(gè)過程本質(zhì)上就是個(gè)數(shù)組遍歷加比較幾行SCL就搞定。模塊化的好處在這里體現(xiàn)得淋漓盡致輪換調(diào)度只關(guān)心泵的UDT.ST和UDT.STAT根本不用管每一臺(tái)泵具體是怎么啟動(dòng)的。4.4 與HMI聯(lián)動(dòng)變量表也模塊化用了UDT之后HMI組態(tài)的變量連接也會(huì)輕松很多。比如觸摸屏要顯示1號(hào)泵的運(yùn)行狀態(tài)變量地址就是PumpData[1].ST.Running。在WinCC或第三方HMI中可以直接導(dǎo)入PLC變量層級(jí)結(jié)構(gòu)保持和UDT一致。這意味著HMI畫面的開發(fā)也可以模板化建一個(gè)“泵操作面板”的畫面模板綁定PumpData[i]即可復(fù)制3份對(duì)應(yīng)3臺(tái)泵。HMI上最常見的操作——“復(fù)位故障”在FB內(nèi)部是這么處理的按下復(fù)位按鈕ResetFault置位FB在FAULT狀態(tài)下檢測到之后把故障狀態(tài)清掉、回到IDLE。這里要多說一句復(fù)位按鈕最好用“上升沿觸發(fā)”而不是電平觸發(fā)否則按鈕一直按著故障一出現(xiàn)就被瞬間復(fù)掉可能掩蓋真實(shí)故障。5. 常見問題與排查技巧實(shí)錄模塊化實(shí)踐不像書上寫的那么順風(fēng)順?biāo)畬?shí)際項(xiàng)目中總會(huì)遇到各種幺蛾子。下面這幾個(gè)問題是我和身邊同行交流后總結(jié)出的高頻坑。5.1 背景數(shù)據(jù)塊太多項(xiàng)目樹爆炸每調(diào)用一個(gè)FB就會(huì)生成一個(gè)背景DB。如果一個(gè)設(shè)備有幾十個(gè)FB實(shí)例項(xiàng)目樹里就會(huì)出現(xiàn)幾十個(gè)背景DB看著就腦仁疼。這也是很多工程師嫌棄FB的原因——“變量不好找嘛”。其實(shí)解決思路有兩個(gè)。一是使用多重背景在某個(gè)FB的靜態(tài)變量區(qū)聲明其他FB的實(shí)例例如在FB_PumpSystem的靜態(tài)區(qū)中聲明fbPump1 : FB_PumpControl這樣所有泵控FB的背景DB只有一份作為FB_PumpSystem的背景DB的子區(qū)域。二是把某些內(nèi)部狀態(tài)不重要的FB改用FC減少背景DB數(shù)量。但后者會(huì)犧牲“記憶”能力很多設(shè)備邏輯復(fù)用不了。我的建議是設(shè)備級(jí)FB可以考慮多重背景過程級(jí)調(diào)度邏輯用FC這種“FB管設(shè)備、FC管調(diào)度”的分工在實(shí)際項(xiàng)目中很順手。5.2 在線修改UDT后CPU直接STOP這個(gè)問題最容易讓人冷汗直冒。項(xiàng)目調(diào)試中你覺得UDT里缺一個(gè)參數(shù)于是在線修改了UDT定義然后點(diǎn)擊“下載”結(jié)果CPU從RUN切換到STOP現(xiàn)場設(shè)備全部停機(jī)。原因是UDT結(jié)構(gòu)變化會(huì)導(dǎo)致所有引用它的數(shù)據(jù)塊、背景DB的存儲(chǔ)布局全部變化CPU無法在不停止的情況下重新分配內(nèi)存。處理方式很明確項(xiàng)目上線前把UDT定義凍結(jié)禁止追加或刪除成員只允許改初始值或注釋。UDT尾部一定要加預(yù)留字節(jié)就是前面說的Reserve : Array[0..7] of Byte項(xiàng)目后期需要加數(shù)據(jù)時(shí)用完這8個(gè)字節(jié)日后再加能避免絕大多數(shù)的停機(jī)風(fēng)險(xiǎn)。如果要修改的UDT已經(jīng)在生產(chǎn)線上運(yùn)行務(wù)無比對(duì)好影響范圍停機(jī)窗口內(nèi)快速下載不熟練的情況下可以用“復(fù)制UDT為另一個(gè)新類型”的方式做增量邏輯驗(yàn)證驗(yàn)證通過再切換。5.3 狀態(tài)機(jī)執(zhí)行異常為什么設(shè)備偶爾卡在一個(gè)狀態(tài)狀態(tài)機(jī)的坑多半出在“邊沿處理”和“多周期競爭”上。比如START_DELAY狀態(tài)里tDelay.Q條件滿足了但同時(shí)StopCmd也來了這時(shí)候到底進(jìn)RUNNING還是回IDLECASE語句的判斷順序決定了結(jié)果。如果IF StopCmd OR FaultSig寫在IF tDelay.Q前面那就會(huì)優(yōu)先退回IDLE不會(huì)進(jìn)入RUNNING。這不是bug是邏輯順序問題但很容易讓后來接手的工程師困惑。排查方法很簡單把step變量加到監(jiān)控表里在線觀察設(shè)備卡在哪個(gè)狀態(tài)值。如果一直卡在某個(gè)狀態(tài)不跳多半是跳出條件不滿足——比如反饋信號(hào)一直沒到位如果狀態(tài)在反復(fù)橫跳多半是多個(gè)條件同時(shí)滿足、而CASE的優(yōu)先級(jí)和你預(yù)期的不一致。5.4 在線監(jiān)控看不到UDT數(shù)組里的成員S7-1200/1500默認(rèn)使用“優(yōu)化的塊訪問”在這種模式下監(jiān)控表里雖然能展開UDT數(shù)組但某些版本的TIA Portal在監(jiān)控時(shí)會(huì)顯示為“下標(biāo)不可用”。我見過不少工程師以為程序?qū)戝e(cuò)了急得團(tuán)團(tuán)轉(zhuǎn)。解決辦法一是把該數(shù)據(jù)塊或FB的“優(yōu)化的塊訪問”屬性取消改為非優(yōu)化訪問二是直接把要監(jiān)控的成員單獨(dú)建一個(gè)監(jiān)控DB用AT覆蓋或賦值的方式把關(guān)鍵狀態(tài)引出來三是充分利用TIA Portal的“監(jiān)控表格”功能把表達(dá)式替換成PumpData[1].ST.Running這種完整路徑。不同品牌PLC三菱、歐姆龍的在線監(jiān)控方式各有差異但核心思路一致——監(jiān)控路徑要完整、訪問屬性要匹配。5.5 命名規(guī)范一人一個(gè)風(fēng)格等于沒有規(guī)范模塊化程序最怕命名混亂。UDT叫MotorInfoFB叫FB_MOTOR變量名一會(huì)兒Pump1_State一會(huì)兒boPumpState這種程序即使結(jié)構(gòu)清晰讀起來依然費(fèi)勁。推薦的做法是建立一份項(xiàng)目級(jí)命名規(guī)范包含以下規(guī)則UDT命名用名詞Pump_UDT、Valve_UDT、Analog_UDT。FB命名用動(dòng)詞名詞FB_PumpControl、FB_ValveControl。變量名采用“設(shè)備名_信號(hào)含義”的格式比如Pump1_StartCmd、Pump1_FaultSig。注釋必須寫明功能狀態(tài)位還要標(biāo)注有效電平高電平有效/低電平有效模擬量要標(biāo)注工程量和單位。我見過一個(gè)泵站項(xiàng)目由于前人不寫注釋后面人接手后只能對(duì)著地址表猜變量含義平均每次故障排查要花三倍時(shí)間。程序是寫給后來的工程師包括三個(gè)月后的你自己看的不只是寫給PLC執(zhí)行的。結(jié)尾模塊化實(shí)踐這件事確實(shí)不是一蹴而就的。我個(gè)人的經(jīng)驗(yàn)是不要等到項(xiàng)目做大了才想起來重構(gòu)而是從下一個(gè)項(xiàng)目開始找一個(gè)最常出現(xiàn)的設(shè)備類型泵、閥門、電機(jī)都行先定義UDT再封裝FB哪怕一開始只有一兩個(gè)實(shí)例也要用調(diào)用的方式寫。你會(huì)發(fā)現(xiàn)前幾次封裝可能比直接寫梯形圖還慢因?yàn)橐伎冀涌?、狀態(tài)劃分、異常處理但一旦封裝完成后面就是復(fù)制-改參-實(shí)例化效率完全是另一回事。最后再分享一個(gè)小技巧把封裝好的UDT和FB放進(jìn)TIA Portal的“全局庫”中下次項(xiàng)目直接以“庫元素”的方式拖拽復(fù)用。這樣不僅能跨項(xiàng)目保持程序風(fēng)格一致還能把你自己沉淀下來的時(shí)間滯后邏輯、保護(hù)互鎖規(guī)則這些“項(xiàng)目魂”帶過去。用得越多庫越厚代碼質(zhì)量自然水漲船高。