去年我?guī)е鴪F隊做完京東物流中心的分揀控制系統(tǒng)改造整套方案用的就是西門子S7-1500PLC平臺。這個項目讓我對1500在物流倉儲場景里的表現(xiàn)有了完整認識從硬件選型、Profinet組網(wǎng)到分揀邏輯的編寫再到和WCS系統(tǒng)聯(lián)調的每個環(huán)節(jié)都有不少值得復盤的東西。這篇文章就把整個實戰(zhàn)過程里的設計思路、關鍵參數(shù)、踩過的坑一并寫出來給準備上自動化分揀項目的朋友做個參考。項目本身是一個區(qū)域內的大型物流分揀中心處理的包裹類型多、流量大高峰期的目標是每小時分揀兩萬件以上。傳輸線覆蓋入庫、出庫、環(huán)線分揀、異常處理等環(huán)節(jié)設備類型包括皮帶輸送機、交叉帶分揀環(huán)線、頂升移載機、堆垛機、動態(tài)稱重、掃碼和RFID識別設備控制規(guī)模中等偏上。整體控制系統(tǒng)在保證處理能力的同時還要兼顧柔性——因為618、雙11這種大促場景下流量瞬間會翻幾倍。1. 項目整體設計與控制架構1.1 為什么最終選擇了S7-1500系列剛拿到需求的時候其實很多人問過我一個問題你們用S7-300甚至S7-1200不也行嗎價格還便宜。這話有道理但這個項目不一樣核心原因有三點。第一是性能余量。分揀環(huán)線上小車節(jié)拍高編碼器和光電信號的掃描頻率要求很高S7-300在處理高速計數(shù)和復雜中斷時CPU占有率容易頂?shù)脚R界值。而S7-1500的CPU采用新的處理器架構位運算大約能做到1到10納秒級別整數(shù)運算和浮點運算性能比300快一個數(shù)量級。我們用CPU 1516-3 PN/DP做主控實際運行下來CPU負載長期穩(wěn)定在35%上下即使大促瞬間流量上來也沒出現(xiàn)過掃描周期超標的問題。第二是Profinet生態(tài)的成熟度。1500原生支持Profinet IO配合遠程IO站ET200SP現(xiàn)場布線工作量能減少一半。輸送線這種設備布置分散的場合用Profinet拉一圈光纖或者屏蔽網(wǎng)線再把ET200SP放在電控柜里就近接IO比傳統(tǒng)硬接線省太多時間后期查故障也容易。第三點是通信集成靈活性。S7-1500內置了OPC UA服務器雖然我們當時跟WCS的通信走的是Socket/TCP但后面做過一個小試驗用OPC UA對接上位機數(shù)據(jù)采集系統(tǒng)配置起來非常省事這在老款300上是沒法想象的。當然了選1500也不是沒有代價。最直接的是成本比1200高出一截而且如果團隊之前只寫過300/1200的程序TIA Portal的開發(fā)習慣要改不少。但從整個項目周期和維護角度來看這個投入是值得的。1.2 物流中心的工藝流程與控制層級劃分打開一張典型物流中心布局圖你會發(fā)現(xiàn)它像一條立體流水線入庫區(qū)收貨包裹經(jīng)過稱重掃描進入主輸送線然后進入自動化立體倉庫或者直接流向分揀環(huán)線。分揀環(huán)線通過小車把每個包裹運到對應格口滑入滑道后裝車出庫。每個環(huán)節(jié)之間還有大量的緩存區(qū)、移載機、轉彎機、提升機。我們整個控制架構分三層管理層WMS倉儲管理系統(tǒng)負責訂單和庫存WCS倉儲控制系統(tǒng)負責統(tǒng)一調度設備?？刂茖右許7-1500 PLC為核心負責現(xiàn)場設備的實時控制、邏輯互鎖、信號采集。設備層電機、變頻器、光電開關、掃碼器、RFID讀頭、傳感器等。每個PLC分區(qū)負責一個相對獨立的區(qū)域比如入庫區(qū)、立體庫區(qū)、環(huán)線分揀區(qū)、出庫區(qū)。分區(qū)之間通過Profinet和工業(yè)以太網(wǎng)進行數(shù)據(jù)交換避免一個區(qū)域故障拖垮全場的控制。層與層之間最關鍵的接口是WCS到PLC的任務下發(fā)。WCS根據(jù)WMS的訂單信息計算出“哪個包裹走哪條路徑、進哪個格口”把任務包發(fā)給PLC。PLC執(zhí)行完把結果反饋給WCS。這個交互的實時性和可靠性決定了整套系統(tǒng)的吞吐上限。2. 硬件配置與網(wǎng)絡搭建實戰(zhàn)2.1 PLC主機與遠程IO的選型配置定位到我們負責的分揀環(huán)線區(qū)域主機我們用了一塊CPU 1516-3 PN/DP訂貨號是6ES7516-3AN02-0AB0配了獨立的電源模塊和數(shù)字量輸入輸出模塊。說實話物流場景IO數(shù)量其實很可觀一個區(qū)域幾百個點位很正常所以本地機架只放了一部分剩下的全部通過Profinet拉ET200SP遠程IO站來解決。ET200SP模塊我強烈推薦原因有兩個一是它體積緊湊一個站可以塞下大量IO模塊二是它的熱插拔維護很友好某個IO模塊壞了不需要斷電直接換掉就能恢復。分揀線在高峰期絕對不能停機這種能力太重要了。數(shù)字量輸入主要接的是各類光電開關、接近開關、安全門開關輸出主要接繼電器、接觸器、變頻器使能信號。模擬量用的不多主要是幾個位置傳感器的0-10V信號。高速計數(shù)模塊我們破例用了幾路用于環(huán)線小車定位編碼器的脈沖計數(shù)這個后面細說。從成本控制角度可以不用每個柜子都能放一個PLC子站而是考慮就近放射狀布置。但是每個Profinet從站要注意地址分配不能沖突同時線的長度和拓撲也要計算一下。Profinet每段距離100米超過后要用SCALANCE交換機做中繼拓展同時注意設備名稱和IP地址要一一對應否則在線發(fā)現(xiàn)設備時你會瘋掉的。2.2 關鍵現(xiàn)場設備的接入方式與通信協(xié)議物流中心設備種類多接口協(xié)議也不統(tǒng)一這是整個項目中比較花時間的地方。這里把幾個關鍵設備的接入方式列出來。變頻器控制輸送線和交叉帶設備的驅動主要以SEW和西門子G120變頻器為主。G120直接走Profinet IO報文類型選標準報文1通過控制字和狀態(tài)字實現(xiàn)啟停、調速、故障復位。SEW的變頻器則有Profinet和現(xiàn)場總線兩種模式我們用Profinet組態(tài)時需要安裝對應GSD文件否則TIA Portal里找不到設備。掃碼器與RFID分揀環(huán)線上的掃碼器負責識別包裹條碼。我們用的掃碼器支持Profinet和以太網(wǎng)TCP/IP兩種方式最終選了以太網(wǎng)TCP/IP直連交換機。PLC通過TCP通信指令讀取掃碼器發(fā)送的數(shù)據(jù)幀解析條碼內容再匹配任務隊列。RFID讀寫頭則通過RS485接PLC集成的通信模塊主要用在立體庫和托盤入庫環(huán)節(jié)。智能相機和讀碼器數(shù)據(jù)采集尺寸測量用了智能相機它計算出包裹的長寬高后會通過TCP/IP將數(shù)據(jù)發(fā)送給PLCPLC再根據(jù)這些信息判斷包裹是否符合分揀要求并更新WCS的數(shù)據(jù)庫。這里分享一個選型心得能走Profinet的設備盡量走Profinet因為現(xiàn)代西門子系統(tǒng)的診斷功能強大網(wǎng)絡通斷一目了然。而像掃碼器這種高頻數(shù)據(jù)交互設備用TCP/IP更快但要求PLC側通信程序編得足夠高效避免阻塞循環(huán)掃描。2.3 網(wǎng)絡架構設計與IP規(guī)劃網(wǎng)絡規(guī)劃是整個系統(tǒng)穩(wěn)定運行的基礎可以說網(wǎng)絡配置如果不合理后面調試全是坑。我把全廠PLC、HMI、上位機、掃碼器、WCS服務器全部劃到一個工業(yè)以太網(wǎng)里具體規(guī)劃如下。主控制器之間用SCALANCE XC208交換機做環(huán)網(wǎng)環(huán)網(wǎng)具備冗余功能一臺交換機掉電網(wǎng)絡能在幾十毫秒內切換。環(huán)線分揀區(qū)、入庫區(qū)、出庫區(qū)各放一臺交換機然后匯聚到中心機房的骨干交換機。所有IO設備通過Profinet連接到對應區(qū)的PLCIP地址按區(qū)域、設備類型分層規(guī)劃例如10.10.10.x是環(huán)線區(qū)PLC10.10.20.x是環(huán)線區(qū)IO設備10.10.30.x是環(huán)線區(qū)掃碼器。IP規(guī)劃看起來簡單但做不好很痛苦。項目調試期間出現(xiàn)過兩臺掃碼器IP沖突導致環(huán)線數(shù)據(jù)時斷時續(xù)。排查了半天才發(fā)現(xiàn)因為掃碼器出廠IP是192.168.1.x現(xiàn)場安裝時有一臺忘了改就直接用了跟環(huán)線本地網(wǎng)絡的另一個設備撞在一起。所以進場第一天就要把IP規(guī)劃表打印出來貼到電控柜里每接一個設備就核對一次不要偷懶。還有一個重要問題是Profinet的設備名稱。每個IO設備要和組態(tài)里的設備名稱完全一致而不是IP一致。改IP不會影響Profinet通信但設備名稱錯了就一定連不上這個和很多老工程師的習慣不太一樣需要提醒團隊特別注意。3. 核心控制程序的架構設計與實現(xiàn)3.1 分區(qū)化程序架構與模塊化思路拿到1500之后一個最大的感受是TIA Portal的工程項目管理比Step 7好太多。我習慣把整個項目按功能拆分成若干個OB、FB、FC塊分門別類管理讓看程序的人不會一頭霧水。以分揀環(huán)線控制為例程序結構大致是這樣OB1主程序循環(huán)掃描組織所有FB調用。OB10/OB20定時中斷用于周期性任務比如設備心跳檢測、定時數(shù)據(jù)上報。FB100輸送線啟停邏輯封裝每臺輸送機對應一個背景數(shù)據(jù)塊。FB200分揀任務處理接收WCS下發(fā)的任務包解析條碼匹配格口。FB300小車位置跟蹤和環(huán)線驅動控制處理編碼器脈沖計算小車在環(huán)線上的坐標。FC500報警處理超時、堵包、通信故障統(tǒng)一歸檔和顯示。模塊化編程最大的好處是故障定位快。比如環(huán)線某臺小車報位置丟失直接打開FB300的背景DB看小車的坐標值和編碼器值跟現(xiàn)場實際位置一對比問題基本就浮出水面。如果是傳統(tǒng)那種把所有邏輯寫在一起的梯形圖查這個故障可能得花幾個小時。3.2 分揀任務分配與數(shù)據(jù)同步邏輯分揀系統(tǒng)的核心邏輯是“任務包的生成、匹配和釋放”。WCS下發(fā)一個任務包里面包含包裹的條碼、目標格口號、優(yōu)先級等信息。PLC把這些任務包存儲在數(shù)據(jù)塊里形成一個待處理隊列。環(huán)線上每個小車都綁定一個任務包載貨后確認綁定成功進入分揀區(qū)域后根據(jù)目標格口號決定是否在該格口傾翻卸載。關鍵邏輯我寫成了模擬場景幫助理解可以把環(huán)線想象成一列火車每個車廂是一個小車每節(jié)車廂可以裝一個包裹到了某個站臺格口時才卸貨。但火車的站臺數(shù)量太多不能每個站臺都停所以火車的速度要恒定PLC根據(jù)車廂當前位置當車廂到達對應站臺坐標時輸出一個短暫的翻板信號包裹順勢滑下。實際上這里最麻煩的是數(shù)據(jù)同步。因為環(huán)線小車在高速運動PLC必須在極短時間內完成“小車坐標-目標格口-傾翻信號”的匹配。我們用高速計數(shù)模塊讀取編碼器脈沖每轉一圈對應多少毫米的位移是固定的CPU在一個掃描周期內就算出了小車的實際坐標再與格口坐標表比較。這個坐標表存放在DB中不同格口的坐標在調試初期通過“試跑-修正-再試跑”的方式標定。3.3 輸送線分合流與防堵包控制輸送線在物流中心里看似最簡單但分合流位置的防碰撞邏輯才是真正考驗編程功底的環(huán)節(jié)。舉一個常見的合流段場景兩條支線匯入一條主線如果兩條線上各有一個包裹同時到達匯合點就會發(fā)生碰撞輕則包裹損壞重則設備卡死。防碰撞邏輯簡單來說就是“先到先過后到等待”。在匯合點前一段距離安裝兩對光電開關分別檢測兩條支線上是否有包裹接近。PLC的邏輯是當A線光電檢測到包裹且B線也檢測到包裹時根據(jù)兩條線上包裹離匯合點的距離決定哪一方的輸送機先動作另一方則暫停。一旦先行的包裹離開了匯合點后方的輸送機再啟動。這個邏輯本身不難難點在于參數(shù)調試。輸送機的啟停有加減速延時太早或太晚判斷都會導致包裹在匯合點附近停位不準。我們通過逐步調整檢測光電的安裝位置和程序中的定時器延時參數(shù)最終把合流效率控制在最高同時沒有出現(xiàn)過一次碰撞事件。堵包檢測也非常重要。物流中心的輸送線經(jīng)常因為包裹卡在軌道上導致后方包裹堆疊如果不及時停機會造成大面積的設備損壞。我在每段輸送機的末端都編了一個堵包定時器如果末端光電一直有貨超過設定時間就判定堵包前序輸送機自動停機并上報報警。這個設定時間不能太短否則正常排隊緩存的包裹也會被誤判為堵包也不能太長否則起不到保護作用。經(jīng)過實際調整我們通常把時間設定在10到15秒之間。4. 聯(lián)調階段撕過的坑與排查實戰(zhàn)4.1 現(xiàn)場總線頻頻掉站誰動了我的Profinet聯(lián)調初期環(huán)線從站頻繁出現(xiàn)設備名稱不可用的報警尤其是某幾個ET200SP站幾分鐘掉一次然后又自動恢復。這種時斷時續(xù)的問題最讓人頭大因為故障不像斷線那么規(guī)則。排查過程按順序走先看物理連接確認網(wǎng)線頭壓接牢固水晶頭屏蔽層良好。再看IP和名稱在TIA里檢查組態(tài)名稱和現(xiàn)場設備是否一致。查看交換機的端口統(tǒng)計發(fā)現(xiàn)有一個端口CRC錯誤包特別多。問題最后就出在這根網(wǎng)線上?，F(xiàn)場施工時動力電纜和網(wǎng)線走在同一個線槽里電磁干擾是一方面更慘的是網(wǎng)線有一段被金屬線槽的毛刺壓傷屏蔽層破損導致信號質量差。重新敷設一根網(wǎng)線故障立刻消除。這件事給我的教訓就是Profinet對物理線路質量的要求比想象中高得多?，F(xiàn)場施工時一定要要求弱電和強電分開走線最好用帶屏蔽的工業(yè)網(wǎng)線兩端屏蔽層良好接地。有條件的話所有Profinet接口都用帶金屬外殼的RJ45接口頭不要圖便宜用普通網(wǎng)線接口頭。4.2 掃碼數(shù)據(jù)亂碼與丟字的處理掃碼器和PLC的TCP通信正常但程序讀出來的條碼時對時錯有時候少一個字符有時候亂碼。剛開始懷疑是掃碼器讀碼能力的問題但掃碼器自身的網(wǎng)頁診斷界面顯示讀取結果全部正常。最后定位到通信程序的處理上。掃碼器發(fā)送的數(shù)據(jù)是一段ASCII字符串以CRLF結尾但PLC側接收時數(shù)據(jù)包被分成了兩段到達。如果程序里按第一次接收到的數(shù)據(jù)直接解析就出現(xiàn)讀碼不完整的情況。解決辦法是在通信程序中增加一個緩沖數(shù)組把每次到達的數(shù)據(jù)先存到緩沖區(qū)等到檢測到結束符CRLF后再統(tǒng)一解析。這樣無論TCP數(shù)據(jù)分多少段到達最終都能拼出一個完整的條碼。這個坑很典型凡是做串口或者TCP數(shù)據(jù)采集的朋友大概率都會遇到。4.3 環(huán)線小車定位失步的糾偏邏輯交叉帶分揀環(huán)線調試時最讓人崩潰的是小車定位飄移。表現(xiàn)在運行一段時間后小車實際停位和程序計算坐標之間有偏差導致部分格口不卸貨或者卸到錯誤格口。原因在于編碼器脈沖計數(shù)和機械系統(tǒng)兩者之間會積累誤差比如小車打滑、皮帶拉伸、編碼器安裝松動等。我們最后加了兩道糾偏邏輯第一道是原點校準。環(huán)線固定一個原點位置小車每運行一圈經(jīng)過原點時將PLC里的脈沖計數(shù)強制歸零這樣每圈最多只積累一圈的誤差不會無限累積。第二道是電子修正。我們在環(huán)線兩個校準點之間測量出實際距離在PLC里記錄修正系數(shù)后續(xù)計算坐標時乘以這個系數(shù)讓計算距離和機械位移盡可能一致。實測下來兩道糾偏一起工作小車定位誤差控制在正負10毫米以內徹底解決了錯分問題。4.4 TIA Portal在線監(jiān)控時的幾個注意點TIA Portal確實好用但也不是沒脾氣。項目調試期間我們遇到過在線連接TIA后PLC程序運行緩慢的情況后來查了一下是因為在線監(jiān)控的變量太多尤其是數(shù)組監(jiān)控導致PLC的通信負載變大。解決辦法是盡量用變量表監(jiān)控不要直接監(jiān)控整個DB塊尤其在實時性要求高的邏輯部分。另外1500的一個很大的亮點是它自帶的Web診斷頁面。不需要裝任何軟件通過瀏覽器輸入PLC的IP地址就能看到設備狀態(tài)、診斷緩沖區(qū)的報警記錄。這個對現(xiàn)場維護人員非常友好現(xiàn)在遇到問題我都是第一時間讓現(xiàn)場同事打開Web頁面截圖給我遠程看排查效率提高不少。5. 維護階段的調整經(jīng)驗與避坑建議項目從聯(lián)調通過到現(xiàn)在已經(jīng)運行了一年多期間經(jīng)歷過大促流量考驗也有一些小問題值得記錄。5.1 流量沖擊下的程序穩(wěn)定性調整第一次大促前我們其實挺忐忑的因為實際流量比日常測試翻了好幾倍。果不其然運行第一天就出現(xiàn)了環(huán)線積貨報警。排查后發(fā)現(xiàn)是最開始設置的堵包判定時間太保守大流量下緩存區(qū)本來就是滿的被誤判成堵包觸發(fā)了全線停機保護。調整方案是重新梳理各緩存段的容量和實際流量把堵包判定時間適當延長同時增加“高位緩存預警”功能在緩存即將滿之前先通知WCS減少前方來料而不是直接停機。調整后系統(tǒng)在大促期間運行平穩(wěn)沒有再因為這個原因停過機。5.2 備件管理與程序備份的規(guī)范操作西門子PLC項目的維護最忌諱的是程序版本亂。項目交付時我們?yōu)槊總€區(qū)域PLC做了獨立的項目歸檔并在電控柜內和本地服務器各放了一份。后續(xù)現(xiàn)場改過任何邏輯都必須同步更新歸檔并且版本號遞增。發(fā)生過一次現(xiàn)場工程師改了程序沒備份半年后PLC存儲卡故障恢復回來的程序竟然是半年前的初始版本把之前優(yōu)化的參數(shù)全丟了。從那以后備份這件事我是強行要求歸檔打卡記錄的。備件方面建議關鍵模塊CPU、電源、ET200SP接口模塊至少存放一套備件并定期上電測試備品備件是否正常。PLC元器件一般不會突然失效但現(xiàn)場環(huán)境粉塵多、濕度不穩(wěn)定長期停用的備件也可能受潮損壞。每次大促前我都會安排現(xiàn)場測一遍備件確認都能正常上電。5.3 從項目里總結的幾條實用經(jīng)驗最后分享幾條通用性比較強的經(jīng)驗無論是做物流中心還是做其他產(chǎn)線自動化我覺得都適用。一是PLC的選型不要只看點數(shù)要看CPU的處理能力和通信能力。物流中心這種設備密集、數(shù)據(jù)交互頻繁的場景通信性能往往比IO點數(shù)更能決定系統(tǒng)上限。二是程序結構一定要設計好尤其是報警邏輯和故障停機邏輯?，F(xiàn)場維護人員文化水平參差不齊程序越清晰故障恢復越快。我們當時把所有設備報警都集中到一個全局報警塊里統(tǒng)一顯示在HMI上HMI的報警頁面支持按區(qū)域、按設備篩選維護人員基本不需要翻梯形圖就能定位問題。三是不要迷信“自動跑通”就結束了一定要模擬各種故障場景。簽單前我們專門留出幾天做故障模擬測試人為制造通信故障、堵包、光電失靈、變頻器報警驗證系統(tǒng)是否能安全停機并給出正確報警。這些測試暴露了不少問題比如有個地方停機后重新啟動輸送機上已經(jīng)存在的包裹被漏檢導致任務數(shù)據(jù)錯亂。后來在啟動邏輯里增加了上電后的“緩存區(qū)貨物掃描”步驟解決了這個問題。四是多和現(xiàn)場的設備廠家溝通。我們的很多參數(shù)比如變頻器的加減速時間、輸送機的機械節(jié)拍都是先聽設備廠家的建議再結合現(xiàn)場實測微調。不要自己拍腦袋定參數(shù)機械特性和電氣參數(shù)不匹配的話調試周期只會更長。