干這行久了你會發(fā)現剛入行1-3年的PLC工程師真正卡住大家的往往不是多復雜的算法也不是什么冷門協(xié)議棧而是一堆老師傅閉著眼都會、但新人壓根沒被系統(tǒng)講過的現場細節(jié)。編程軟件會用、梯形圖會寫不代表設備能跑得穩(wěn)。設備一報警客戶電話打到手機上你蹲在電柜前心里發(fā)毛這才是前三年最真實的日常。我這么多年帶過的工程師幾乎都有過這種階段。所以我把入行1-3年最值得記的實戰(zhàn)經驗整理了90條原本打算每天更新幾條今天不打散先把其中最要命的幾組揉成一篇長文從接線物理層、掃描周期、通信排障一路聊到軸調試和安全聯鎖。這篇不是教科書是我在設備旁邊被磨出來的東西。1. 現場物理層接線、傳感器類型和屏蔽程序再對也架不住“硬件搗亂”很多新人出問題第一反應是打開程序反復檢查邏輯結果問題根本不在程序里。PLC這行有個不成文的規(guī)則先懷疑所有物理連接再懷疑程序。你寫得再漂亮的邏輯遇到一根虛接的線、一個配錯的傳感器、一條貼著動力線走的模擬量電纜照樣跑出讓人崩潰的現象。1.1 NPN/PNP傳感器配錯輸入信號“有就像沒有”的典型現場曾經有個設備調試現場新人小Z花了兩小時查一個氣缸到位信號程序監(jiān)視畫面里那個輸入點就是不變綠。他用萬用表量傳感器輸出端一會兒有24V一會兒沒有感覺信號明明在變。最后我讓他去看PLC輸入端子的公共端接法再對照傳感器型號——傳感器是NPN輸出而PLC輸入模塊是PNP型的接線方式信號電平方向完全對不上。萬用表能看到電壓跳變但PLC輸入采樣電路根本沒法正確識別。這里的基本原理其實不復雜NPN傳感器導通時輸出端被拉到低電平PNP傳感器導通時輸出端輸出高電平。PLC的輸入模塊分源型輸入和漏型輸入公共端接法決定了它到底需要高電平有效信號還是低電平有效信號。選型階段沒核對現場就只能臨時換傳感器、改接線或者加中間繼電器轉換耽誤半天工期。我的建議是項目前期做I/O點表時就把傳感器類型標進每一路備注里NPN還是PNP、兩線還是三線、輸出是常開還是常閉全部寫清楚。到了現場先用萬用表確認傳感器供電是24V還是12V再測輸出狀態(tài)最后才對PLC端子不要直接憑經驗接。有一種更隱蔽的情況是常開常閉選錯。設備在原點時傳感器被擋鐵壓住你選了常開程序里卻默認它沒被壓住結果一啟動直接報錯。這種問題排查起來很費勁因為信號“看起來”是對的只是邏輯和機械位置沒對應上。處理思路也一樣先確認機械動作狀態(tài)再對照程序里的有效信號狀態(tài)。1.2 端子松動、冷壓頭和屏蔽層決定設備壽命的往往不是程序我見過最讓人哭笑不得的一次停機事故原因是PLC輸出端子的螺絲沒擰緊設備運轉時震動導致端子偶發(fā)接觸不良。輸出繼電器吸合了但負載接觸器線圈偶爾得電偶爾失電整個氣缸動作像鬼畜一樣一頓一頓?？蛻粽fPLC壞了其實PLC委屈得很接線端子松了這件事拿把螺絲刀擰一圈就好但你在現場能排查一晚上。現在我?guī)俗鲅矙z電柜里每排端子的螺絲擰緊一遍是固定動作尤其是新裝設備運行一周后熱脹冷縮帶出來的松動太常見了。端子用冷壓端子壓好不用裸線直接鎖螺絲線徑和端子規(guī)格匹配寧可大一號也別湊合。還有一個經常被忽略的細節(jié)是信號線和動力線的布線隔離這在模擬量信號上體現得特別明顯。模擬量傳感器和變頻器驅動同一臺電機如果4-20mA的信號線跟變頻器輸出線走同一個線槽變頻器一啟動信號線就成了“天線”干擾直接被拽進PLC模擬量輸入模塊畫面上一會跳大數字一會跳零。我之前處理過一條包裝線上的壓力信號抖動查了半天最后把信號線從動力線槽里單獨拉出來屏蔽層在PLC側單端接地問題立刻消失。記住這句話屏蔽層必須單端接地兩端接地反而會形成地環(huán)路把干擾接得更牢。1.3 模擬量信號在變頻器啟動時亂跳實時性不是靠程序補出來的模擬量信號在變頻器啟動時亂跳很多人第一反應是在PLC里加濾波把采樣值平均掉。濾波確實能讓畫面穩(wěn)定但它會讓實際響應變慢精度也會打折。你要是做溫度控制慢幾秒可能問題不大要是做張力控制或者壓力PID濾波帶來的滯后會把你逼瘋。正確思路是先把信號鏈路搞干凈再考慮軟件濾波。從傳感器、變送器到PLC模擬量模塊全程用屏蔽雙絞線屏蔽層單端接地盡量遠離變頻器、電抗器和動力電纜。穿過電柜壁的時候走專門的格蘭頭別讓信號線和動力線從同一個孔進。如果現場實在沒法分開布線就在模擬量信號源端加隔離配電器把4-20mA信號隔離后再進PLC。成本不高但能省掉夜里兩點被電話叫醒的麻煩。對新手來說判斷是干擾還是信號真跳變有個土辦法把PLC切到停止模式用萬用表毫安檔直接量模擬量輸入端子的電流如果電流本身就在跳那就不是程序能解決的問題是信號鏈路臟。2. 掃描周期與程序結構前三年寫代碼后三年還債最容易還在這上面程序結構這件事剛入行時沒人覺得它重要能跑就行。但項目一多、設備一復雜爛結構的成本就全部顯現出來了。我見過太多設備程序一個循環(huán)掃描周期里塞了上千條指令所有設備邏輯互相穿插像一團毛線球。這不是寫代碼風格的問題是后面調試、維護、加裝功能時能不能活下來的問題。2.1 I/O映像區(qū)為什么實際端子上有信號程序里讀到的卻不是新的PLC的工作方式不是“程序每一步都實時讀取輸入端子”。絕大多數中小型PLC在一個掃描周期里先把所有輸入端子的狀態(tài)讀進內存的輸入映像區(qū)然后CPU執(zhí)行用戶程序程序里讀到的輸入狀態(tài)全部來自這個映像區(qū)掃描周期結束再把輸出映像區(qū)統(tǒng)一刷新到物理輸出端子。也就是說程序執(zhí)行過程中外部輸入信號發(fā)生了變化當前掃描周期內程序是“看不見”的要等下一個掃描周期才讀到。這個機制解釋了日常調試里常見的怪現象你用萬用表量PLC輸入端明明是24V程序監(jiān)視里那個位卻還是0。如果那個輸入信號恰好是在程序掃描中途才翻轉的那當前周期里它確實沒被采集。反過來程序里已經把輸出置1了但實際輸出端子還維持上一個掃描周期的狀態(tài)因為輸出刷新還沒開始。很多新手診斷故障時拿萬用表量完端子就直接下結論說PLC壞了其實是對掃描機制不熟悉。遇到這種“信號和邏輯對不上”的情況先問自己一句我是不是看錯了時刻脈沖信號捕捉則是另一個常見坑。有些快速脈沖信號比如編碼器或高速計數輸入掃描周期根本來不及響應。這時候不能靠普通輸入點硬采要會用高速計數功能或中斷輸入把脈沖直接送入計數通道。對剛入行的同行我有個建議遇到“偶爾丟信號”的輸入點不要只加大程序里的持續(xù)判斷先確認這個模塊是否支持中斷或硬件計數再決定程序怎么寫。2.2 OB、FC、FB怎么分模塊化不是寫代碼時的儀式感早期PLC程序只有很簡單的組織塊今天無論歐系還是日系PLC基本都支持功能塊、函數塊、中斷塊這類結構。很多新人不習慣拆分一個主循環(huán)里把所有設備的自動流程、報警處理、手動操作全寫完。前期設備簡單還行一旦中途加一臺設備、改一段工藝你就得在一千多行指令里找那幾行相關邏輯還不敢亂改怕順手牽羊把別的地方帶崩。我自己的習慣是把程序按設備域拆開每個工位的邏輯單獨做成一個功能塊主循環(huán)里只做調用和狀態(tài)匯總手自動切換單獨一塊報警處理和復位邏輯單獨一塊模擬量處理和PID控制單獨一塊。每個功能塊的輸入輸出接口定義清楚盡量不靠全局變量互相傳狀態(tài)能用參數傳的就用參數傳。這樣做有個直接好處現場排查時你只需要把目光鎖定在那個異常設備的塊上不需要翻遍整個程序。別人接手你的程序也不需要一邊猜一邊鼠標懸?？醋兞孔⑨尅９δ軌K和函數塊的區(qū)別也值得弄清楚。功能塊有背景數據塊能保存上一次掃描的狀態(tài)適合做電機控制、氣缸動作這類有“記憶需求”的邏輯函數塊沒有獨立的背景數據存儲適合做純計算、純轉換比如工程單位換算、模擬量濾波。新人最容易犯的錯是在函數塊里定義臨時變量保存中間狀態(tài)結果掃描周期結束變量值就丟了下一輪邏輯從頭再來時好時壞。凡是需要跨掃描周期保持的狀態(tài)一定要放進功能塊的靜態(tài)變量或背景數據塊里不是隨手找個臨時變量就完事。2.3 定時器、臨時變量和“數據快照”的坑定時器看起來簡單用起來坑不少。每種定時器都有精度和保持特性差異有的掉電歸零有的掉電保持當前計時值。設備在斷電再上電之后如果定時器復位了可能導致該報警的沒報警不該啟動的啟動了。做安全相關邏輯時定時器一定要選帶保持功能的類型并且在復位條件里寫明白“什么時候允許清掉計時值”。還有一個掃描周期帶來的計時誤差如果定時器精度是10毫秒而你的掃描周期在20毫秒左右波動那定時精度天然就鎖死在掃描周期這個量級上想靠定時器做高精度時間控制是不現實的。需要準確到毫秒級的時間戳直接用PLC的實時時鐘或者專用定時功能?，F場我曾經見過一排氣缸同步動作新人用普通定時器做各氣缸啟動延時氣缸多、掃描周期被拉長后明顯能看到動作一個接一個地“慢半拍”最后換成硬件時序控制才解決?！皵祿煺铡眴栴}我特別想強調。調試時把一批中間變量的“當前值”截圖保存等設備運行半小時后再對比截圖你會發(fā)現有些中間狀態(tài)已經悄悄變了。PLC里變量多程序里各種條件環(huán)環(huán)相扣你不建立數據快照的習慣出了問題連“之前哪個狀態(tài)不對”都說不清楚。進現場第一件事把關鍵輸入、輸出、報警變量的當前值截圖存起來這比事后回憶可靠得多。3. 通信排障別急著抓包IP、線纜、站號比協(xié)議更容易翻車PLC通信故障十個里面至少六七個不是協(xié)議本身的問題。新手上手就分析報文、看協(xié)議棧但實際現場里網線、水晶頭、IP地址、端口號、站號設置這些“土問題”才是重災區(qū)。排查順序搞反了效率低到自己懷疑人生。3.1 IP地址沖突設備時通時斷現場最典型的一課有一回客戶報障說觸摸屏和PLC通訊經常斷開重啟一下又好過一陣又斷。我過去一查網線沒問題PLC也在正常運行后來打開觸摸屏的系統(tǒng)設置看了眼IP地址192.168.0.10再看PLC還是192.168.0.10。同一臺交換機上掛著兩個相同IP的設備不打架才怪。一個設備通了另一個設備就容易被踢下線看起來就是“隨機掉線”。這種問題排查其實有固定套路把電腦接到同一臺交換機上用持續(xù)ping命令觀察然后一臺一臺拔設備拔到哪臺ping就穩(wěn)定了那臺就是沖突源。ping 192.168.0.10 -t為了不在現場重復踩這種坑我現在每個項目開工前先做一張IP地址分配表包括設備名稱、IP地址、子網掩碼、網關、安裝位置。PLC、觸摸屏、變頻器、上位機、遠程IO模塊全部登記清楚貼一張在電柜門上。后來接手維護的人第一眼就知道哪臺設備是哪個地址不需要一個個登錄進去翻。3.2 Modbus輪詢超時一個從站掉線整條總線陪葬串口通信里最常見的問題不是收發(fā)不通而是“數據刷新突然變慢”。現場某個從站設備壞了它不回復主站的請求但主站程序如果傻等它一段時間才超時整個輪詢周期就被拖住了。其他正常從站的數據等著轉發(fā)全部排隊觸摸屏上所有數據顯示都像卡了殼。這時候很多人的第一反應是“是不是總線壞了”其實只要把壞從站的通信線斷開其他數據立刻恢復流暢。針對這個問題路由器、觸摸屏、上位機程序里都有超時參數和重試次數設置。正確做法是給每個從站單獨設置超時時間并且做“故障從站剔除”邏輯連續(xù)幾次無響應就跳過它繼續(xù)輪詢后面的站同時報一個報警等它恢復后再重新納入輪詢。這樣單個設備故障不會殃及全車。新手調串口通信還有個更基礎的坑RS485的A、B兩根線接反。線接反了大多數從站是完全不通的但也有些設備會間歇性正常讓人誤以為是波特率或校驗位問題。先確認A、B線序再查參數。3.3 三層倒序排查法從物理層開始最后才碰協(xié)議前面說了一堆“土問題”我把自己常用的排查順序總結成一張表每次通信出問題都按這個順序過一遍層級檢查項典型現象物理層網線、水晶頭、RS485 A/B接線、屏蔽層接地、線纜與動力線間距完全不通、時通時斷、干擾誤碼配置層IP地址沖突、站號重復、波特率/數據位/校驗位不一致單個站掉線、部分站時好時壞、數據亂碼協(xié)議層寄存器地址、數據類型、字節(jié)序、功能碼數據能通但數值明顯不對、讀寫不到目標寄存器排查順序永遠是從上往下物理層先排除再檢查配置最后才是抓包分析協(xié)議。有一次調試一個分布式IO從站現場工程師抓了一下午報文懷疑是協(xié)議版本問題最后發(fā)現是網線水晶頭壓線的時候線序壓錯了只要設備跑起來震動一大就丟包。這個教訓很值錢協(xié)議層的問題通常穩(wěn)定且可復現物理層的問題往往是“偶發(fā)”的。你看到故障一會兒有一會兒沒有先懷疑連接和干擾別急著跟協(xié)議較勁。4. 軸調試的三個關鍵參數回零、脈沖當量、加減速少一個都不行PLC控制伺服或步進電機入門看著不難給脈沖就能轉。但真正把軸調得穩(wěn)穩(wěn)當當回零、脈沖當量、加減速時間這三個參數必須吃透。任何一個弄錯設備要么走位不準要么一開機就撞機。4.1 脈沖當量算錯后面的精度都是心理安慰脈沖當量的本質是“一個脈沖對應多少毫米或度的機械位移”。很多人覺得伺服驅動器里設了電子齒輪比就完事了但PLC程序里也必須知道目標位置對應的脈沖數。舉個例子某臺設備由伺服電機直連絲桿絲桿導程10毫米伺服電機每轉需要10000個脈沖減速比1:1那么脈沖當量就是10÷100000.001毫米/脈沖。你讓軸走到50毫米的位置PLC要輸出的就是50000個脈沖。如果在這里忘了算減速比比如減速比5:1實際計算就得把減速比乘進去10÷(10000×5)0.0002毫米/脈沖再輸出同樣脈沖時機械位置就會差出好幾倍。這類錯誤在設備調試時非常隱蔽因為軸確實在動只是走得遠不對、近不對程序卻完全“正確”。我建議新人把脈沖當量計算過程寫在程序注釋里包括導程、減速比、電機每轉脈沖數這樣以后回來看程序不用重新翻機械圖紙。調試時先用慢速、小距離試走再用千分表實際測量機械位移對比程序里的理論值。不要一上來就給大距離快速運行不然算錯了直接撞機。4.2 回零方式和零位信號位置誤差的源頭多半在這里設備的絕對位置從哪里來絕大多數情況下從回零開始。如果用接近開關或光電開關做回零開關開關的安裝位置必須穩(wěn)固信號邊沿要干凈?；亓愠绦虿荒芤皇盏介_關信號就急停因為機械慣性會讓軸沖出幾個毫米正確做法是先減速再低速爬行找開關信號的穩(wěn)定沿如果伺服編碼器有Z相信號最好在Z相到來的那個位置作為最后零點這樣重復精度會高很多。回零方向也很容易踩坑。開機回零時軸要先向開關所在方向移動如果程序里回零方向和設備實際方向相反軸就會朝限位那邊狂奔。正式設備上第一次回零我向來是把速度設成慢速手指放在急停上再按啟動確認方向對了再用正常速度。這不是膽小是保命。回零完成后還要做一次軟限位校驗確認當前位置沒有超過軟件允許范圍。4.3 加減速、軟限位和急停調機前必須先定下來加減速時間設置不合理步進電機最容易丟步伺服電機最容易過沖報警。我之前調一臺轉盤設備加速時間設得太短每次啟動都能聽到明顯的機械撞擊聲轉盤到位還會彈一下。后來把加速時間從50毫秒放寬到300毫秒再配合S形加減速曲線設備立刻安靜了定位精度反而更好。這個經驗是加速時間不是越小越好縮小之前先問自己機械剛性扛不扛得住。軟件限位是軸控制里絕對不能省的一層保護。PLC程序里寫清楚兩個軟限位值當軸位置接近邊界時先減速報警越過邊界直接禁止運動輸出。軟限位千萬不能只依賴驅動器那邊萬一上位機發(fā)了一個大位置指令驅動器和PLC的限位判斷狀態(tài)不一致就可能出事。我見過一個項目PLC程序里完全沒做軟限位全靠驅動器報警停住后來驅動器參數被誤改了一次軸直接頂到機械硬限位。從那以后我的軸控制程序里永遠把軟限位放在最前面哪怕報警提示難看也絕不少寫。5. 聯鎖與安全設計設備可以慢但不能出事程序寫得再巧妙安全設計不到位一切等于零。尤其是正反轉、急停、運行狀態(tài)下改程序這三件事入行頭三年最容易在這上面付出真金白銀的代價。5.1 正反轉互鎖程序里鎖了硬件回路還要鎖控制電機正反轉時PLC里的兩個輸出點必須做互鎖同一個時刻只能有一個輸出為ON這是程序層面的基本要求。但程序互鎖不是全部。如果正轉接觸器和反轉接觸器都吸合了哪怕只是一瞬間三相電源就會短路接觸器的主觸點可以燒得粘在一起。硬件層面的做法是正轉接觸器的常閉觸點串進反轉接觸器的線圈回路反轉接觸器的常閉觸點串進正轉接觸器的線圈回路。這樣即使PLC程序出錯、輸出點卡死硬件機械互鎖也能切斷另一路控制回路。做這類設備時一定要把“機械互鎖”當作保底措施來看待。PLC輸出點有擊穿或者宕機的可能程序邏輯再嚴謹也只是軟件層面的概率事件。硬件互鎖多花幾根線但能把“燒接觸器”變成“不可能發(fā)生的事”。5.2 急停不能只活在PLC程序里要能物理切斷控制回路很多新人處理急停的方式是急停按鈕接到PLC輸入點程序里檢測到急停后就停掉運動輸出。這種做法問題很大。PLC本身可能死機程序可能跑飛輸出模塊可能故障這些情況下光靠程序來響應急停等于紙上談兵。真正的急停回路應該做到急停按鈕直接切斷控制回路里關鍵接觸器和繼電器線圈的供電而不是等PLC來“減速停車”。急停按鈕通常帶機械鎖存功能按下去后不會自己彈回來必須旋轉或拉拔復位。急停回路串接在所有危險運動的主接觸器線圈前方一旦急停觸發(fā)主接觸器直接掉電電機失去動力。同時急停輸入點也接進PLC讓程序感知急停狀態(tài)做后續(xù)的狀態(tài)復位和報警。關鍵是程序里要處理“急停復位后設備不能自動重新啟動”的邏輯一般需要操作員按一下復位按鈕再手動啟動。否則急停一復位電機瞬間又跑起來比急停本身還危險。另外還有安全繼電器的問題。如果設備涉及安全等級認證急停、安全門這些都必須過安全繼電器PLC程序只能做邏輯配合不能替代安全回路。這個錢花不花我建議看設備有沒有人員接觸風險。裁切、沖壓、搬運這類有擠壓風險的設備安全回路絕對不能省。5.3 現場改程序的三個鐵律備份、驗證、記錄現場調試時改程序是常態(tài)但怎么改、改完怎么驗證很多新人都比較隨便。最危險的改法是在設備運行狀態(tài)下直接修改邏輯甚至強制輸出。我理解有時候是客戶催得急但我見過太多次因為臨時改一條指令設備突然動作把模具打壞的事故。改程序前先按一下急停把設備切到手動確認所有運動軸處于安全位置然后再下載程序。下載完成后先空載模擬一遍確認動作順序符合預期再上工件試運行。備份同樣不能省。每次修改前把當前程序另存一份文件名帶上日期和修改內容。調試現場環(huán)境亂一晚上可能反復改十幾次沒有版本管理手一滑就把改好的程序覆蓋了。我見過同事在凌晨改完程序忘了保存第二天設備上電還是老版本整個早上白白浪費。養(yǎng)成這個習慣只需要五分鐘但它能避免的麻煩遠超想象。記錄也重要。改了什么邏輯、為什么改、改了之后驗證過什么動作寫進項目變更記錄表。短期看好像是增加工作量長期看這是項目交接、售后維護、故障回溯最值錢的資料。懸而未決的問題翻一翻變更記錄很多都能找到線索。這批內容先寫到這剩下那幾十條里還有關于PLC選型、I/O點表規(guī)劃、HMI變量分組、程序注釋規(guī)范、故障診斷緩沖區(qū)怎么讀、在線監(jiān)視和強制輸出的正確姿勢這些我后續(xù)會按主題一批批放出來。說句實在話入行前三年誰沒在半夜被電話叫醒過。我直到現在還會在包里揣著一條網線、一個U盤和一個寫滿IP分配的筆記本。技術是一回事習慣是另一回事。這90條里一大半并不是什么“大招”而是把每個普通環(huán)節(jié)做對。希望今天的這些能幫你少熬幾個通宵。