簡介本資源為寧德時代CATL電池生產(chǎn)線項目所用的西門子S7-1500 PLC完整工程程序包面向自動化工程師、PLC程序員及智能制造產(chǎn)線調(diào)試人員聚焦動力電池產(chǎn)線控制邏輯實現(xiàn)與標(biāo)準(zhǔn)化編程實踐。包內(nèi)含150個文件涵蓋99個XML格式的PLC符號表與硬件組態(tài)數(shù)據(jù)、13個BMP格式的GSDML設(shè)備圖標(biāo)如Matrix系列、InSight視覺系統(tǒng)、BIS讀碼器等、9個PNG界面圖、以及AP15_1工程文件、DB數(shù)據(jù)塊、CFS配置文件等核心可執(zhí)行組件總大小23.07MB基于TIA Portal V15平臺開發(fā)支持梯形圖與SCL雙語言編程。已有605人學(xué)習(xí)下載資源嚴(yán)格遵循CATL Program Standard V1.0規(guī)范包含產(chǎn)線標(biāo)準(zhǔn)模塊化結(jié)構(gòu)、典型工藝段控制邏輯如電芯上料、模組堆疊、激光焊接、EOL測試等環(huán)節(jié)、設(shè)備通信協(xié)議配置及可視化圖標(biāo)資源便于快速部署、二次開發(fā)與產(chǎn)線維護。1. 項目概述與設(shè)計目標(biāo)1.1 核心需求解析CATL電池產(chǎn)線對PLC程序的“硬指標(biāo)”寧德時代的電池生產(chǎn)線尤其是模組段和PACK段是我接觸過對控制系統(tǒng)要求最苛刻的場景之一。這里的“苛刻”不是一句空話而是落在實實在在的指標(biāo)上節(jié)拍快、設(shè)備密度高、通訊對象雜、追溯體系嚴(yán)。這幾個詞放在一起對PLC程序從架構(gòu)到細(xì)節(jié)的考驗都是非常直接的。先說節(jié)拍。電池模組線的單工位節(jié)拍經(jīng)常按秒算有的工序要求一個循環(huán)在10到15秒內(nèi)完成包含了掃碼、定位、夾緊、焊接、檢測、松開、放行一整套動作。PLC程序掃描周期、通訊處理時間、運動控制執(zhí)行時間任何一環(huán)慢了都會直接體現(xiàn)在節(jié)拍上。這時候CPU的處理能力就非常關(guān)鍵這也是我堅持用西門子S7-1500系列的核心理由之一。再說追溯。電池行業(yè)對數(shù)據(jù)追溯的要求近乎偏執(zhí)從電芯上料掃碼開始每一節(jié)電芯的條碼、工藝參數(shù)、測試結(jié)果、組裝位置都要跟MES系統(tǒng)實時交互而且數(shù)據(jù)要保存、要能回溯。一旦某個模組在售后端出了問題要能通過條碼反查到當(dāng)時的焊接參數(shù)、擰緊力矩、測試數(shù)據(jù)。這就意味著PLC程序里必須有大面積的通訊處理和數(shù)據(jù)邏輯這塊活用梯形圖寫會寫到懷疑人生SCL是更好的選擇。1.2 系統(tǒng)組成與控制架構(gòu)選型我參與的那條產(chǎn)線工藝段覆蓋了極耳裁切、疊片/卷繞、熱壓、激光焊接、Busbar焊接、EOL測試、氣密測試和模組下線。設(shè)備類型非常雜有機器人上下料工位有伺服定位平臺有大量氣缸夾具有視覺引導(dǎo)系統(tǒng)有法蘭克或者庫卡機器人有各類擰緊軸還有一堆傳感器和儀表。這套系統(tǒng)如果全部靠一臺PLC硬扛那是自找麻煩。正確的做法是分層分布式控制。整線用的方案是S7-1500 CPU1515-2PN級別起步作為主站配合ET200pro分布式IO放在設(shè)備旁邊伺服驅(qū)動用S120或者V90通訊協(xié)議以PROFINET為骨干Modbus TCP用于跟第三方儀表和部分老設(shè)備對接擰緊軸和掃碼槍走獨立的以太網(wǎng)接口或者PN從站。為什么一定要用S7-1500來扛這個活原因很實際電池產(chǎn)線的IO點位分布太廣從線首到線尾可能橫跨一兩百米分布式IO必不可少同時伺服軸數(shù)量多十幾臺伺服同步跑需要穩(wěn)定的總線通訊再加上MES、Andon、能源管理系統(tǒng)這些上位機接口S7-1500的PN接口數(shù)量和通訊處理能力在這種場景下是真的扛得住。中低端PLC想要同時處理這么多路通訊和如此密集的IO刷新早就卡得不成樣子了。1.3 程序分工SCL和梯形圖不是“二選一”講程序架構(gòu)之前我要先糾正一個常見的誤區(qū)SCL和梯形圖不是競爭關(guān)系用哪個也不是為了炫技而是被現(xiàn)實推著走的選擇。SCLStructured Control Language結(jié)構(gòu)化控制語言在編程思路上接近Pascal或者類C語言適合干那種“有算法、有計算、有數(shù)組、有數(shù)據(jù)處理”的活。比如模組坐標(biāo)換算、擰緊數(shù)據(jù)判定、參數(shù)配方的選擇與下發(fā)、跟MES的數(shù)據(jù)打包與解析。這些邏輯用梯形圖畫出來不但網(wǎng)絡(luò)多、可讀性差而且容易埋邏輯錯誤。梯形圖LAD則是電工和現(xiàn)場調(diào)試工程師最熟悉的語言它的優(yōu)勢是“所見即所得”適合干那種需要人直接看懂、需要快速排查問題的活。比如急停回路的邏輯、安全門聯(lián)鎖、氣缸手動操作的互鎖、手自動切換條件。梯形圖每個網(wǎng)絡(luò)就是一條明確的邏輯鏈維護人員拿著萬用表對著圖紙就能查線拿著梯形圖就能查邏輯。所以我的做法很明確算法類、數(shù)據(jù)處理類、通訊處理類用SCL邏輯聯(lián)鎖、回路控制、手動操作、報警匯總用梯形圖。兩種語言各管一攤程序讀起來清楚維護人員查故障也方便不會出現(xiàn)“寫程序的人走了沒人能改”的尷尬局面。2. 為什么是S7-1500從性能到通訊的全面考量2.1 處理速度與存儲空間電池產(chǎn)線最底層的底氣選控制器從來不是一個拍腦袋的事情尤其對于電池產(chǎn)線這種動輒幾十個伺服軸、上千個IO點的系統(tǒng)。S7-1500的底氣第一在于處理速度和存儲容量第二在于通訊能力。先聊速度。S7-1500的位運算、字運算速度直觀感受就是整個程序掃描周期更短通訊任務(wù)幀間隔更穩(wěn)定。在模組線上工位節(jié)拍按秒算一個工位從掃碼到機構(gòu)動作再到數(shù)據(jù)上傳每一步之間的時序都得卡得很準(zhǔn)。PLC掃描周期稍微長一點或者通訊數(shù)據(jù)偶爾延遲一拍輕則報警重則設(shè)備暫停等待。我舉個例子你就明白了一個焊接工位掃碼槍讀到電芯條碼PLC需要基于這個條碼查配方、做坐標(biāo)補償、把目標(biāo)位置發(fā)給機器人或者焊接控制器。從條碼觸發(fā)到焊機執(zhí)行整個鏈路的時間預(yù)算往往只有幾百毫秒。如果PLC在每個周期里還要忙著處理大量無關(guān)的通訊請求和冗余的IO掃描這中間的時間就很難控制住。S7-1500的CPU在處理密集邏輯和通訊并發(fā)時基本不會出現(xiàn)“有心無力”的情況。再說存儲。電池產(chǎn)線的程序工程量非常大一個工段往往有幾十個FB、上百個DB每個DB里還塞滿了配方、報警文本、追溯數(shù)據(jù)緩存。程序加上數(shù)據(jù)所需的空間不是幾KB能打住的。S7-1500的工作存儲器和裝載存儲器容量足夠大不用天天操心“程序?qū)憹M了怎么辦”。2.2 通訊能力跟MES、擰緊軸、掃碼槍打交道的底氣電池產(chǎn)線是MES系統(tǒng)重度依賴的場景這句話我必須重復(fù)一遍。從電芯上料掃碼開始每一節(jié)電芯的條碼、工藝參數(shù)、測試結(jié)果、組裝位置都要跟MES系統(tǒng)實時交互。MES要不要放行、有沒有換型指令、工藝參數(shù)有沒有變更這些都要通過PLC與上位機的實時通訊來傳遞。S7-1500支持PROFINET、PROFIBUS、以太網(wǎng)、Modbus TCP等多種通訊方式而且PN接口數(shù)量多、通訊性能強大不需要額外加通訊模塊就能同時掛載多個從站和上位機。這一點在實際項目中非常重要因為從站設(shè)備多了以后每個從站的刷新時間、通訊周期都會受到影響。S7-1500的PN接口在處理高密從站場景時穩(wěn)定性明顯優(yōu)于上一代產(chǎn)品。舉一個具體場景模組堆疊工位需要跟6臺掃碼槍、2臺視覺相機、MES系統(tǒng)、1臺擰緊控制器同時通訊。數(shù)據(jù)量不算特別大但頻率很高尤其是視覺相機的拍照結(jié)果和擰緊數(shù)據(jù)有時一秒鐘要處理好幾組。S7-1500在這種多路并發(fā)通訊下只要網(wǎng)絡(luò)拓?fù)湟?guī)劃合理、程序里對通訊指令做合理的時序分配就不會出現(xiàn)數(shù)據(jù)擁堵或者通訊超時的問題。這個能力是很多中低檔PLC做不到的。2.3 軟件生態(tài)TIA Portal讓SCL和梯形圖無縫協(xié)作博途TIA Portal是S7-1500的編程環(huán)境也是我非常熟悉的開發(fā)工具。很多人吐槽博途卡、大、占內(nèi)存但說句公道話對于大項目來說博途的項目管理能力和調(diào)試效率確實是同級別軟件里非常出色的。博途對S7-1500有一個特別好的支持在同一個程序塊里可以直接用SCL寫也可以切換到梯形圖寫。S7-1500的FB塊里甚至可以把一段邏輯用SCL寫、另一段邏輯用梯形圖寫所有接口變量在同一個符號表里統(tǒng)一管理。這種“混合編程”的自由度在工程上的實際意義非常大。我自己有個開發(fā)習(xí)慣先在臨時FC里用SCL把新的算法邏輯跑通用模擬數(shù)據(jù)驗證結(jié)果正確后再把邏輯固化到正式FB里。博途支持這種“先驗證再固化”的開發(fā)方式實測下來整個項目的程序開發(fā)周期能縮短三分之一以上。調(diào)試階段我更傾向于用梯形圖觀察大量IO變量和布爾量組合因為梯形圖可以直接看到每個觸點和線圈的實時狀態(tài)而一旦進入算法邏輯和數(shù)據(jù)處理就切到SCL的變量監(jiān)視方式直接看數(shù)值變化。兩種方式切換效率真的高。3. 程序整體架構(gòu)設(shè)計的核心思路3.1 四層程序結(jié)構(gòu)讓程序不再是一片“屎山”電池產(chǎn)線的程序一定要分層設(shè)計不然調(diào)試到后面就是災(zāi)難。我經(jīng)歷過那種所有邏輯揉在一個OB1里的大“屎山”你改一個工位的邏輯不知道碰壞多少別的東西查起問題來整個人都傻了。后來我所有項目都按四層結(jié)構(gòu)來規(guī)劃效果非常好。第一層是組織層也叫背景層。負(fù)責(zé)CPU啟動、初始化、集中報警匯總、節(jié)拍計時、在線監(jiān)控數(shù)據(jù)上傳。這一層的代碼量不大但決定了整個程序的“地基”穩(wěn)不穩(wěn)。第二層是工位管理層。每個工位對應(yīng)一個或幾個FB負(fù)責(zé)該工位的狀態(tài)機、手自動切換、配方選擇、報警管理。每個工位的FB獨立運行互不干擾內(nèi)部出問題只影響本工位不會把整線搞崩。第三層是功能層。把伺服、氣缸、掃碼、稱重、擰緊、視覺相機這些通用動作封裝成一個個標(biāo)準(zhǔn)FB。這一層的目標(biāo)是一次封裝、反復(fù)調(diào)用盡量減少重復(fù)代碼。比如氣缸控制FB控制了前進、后退、到位檢測、超時報警、互鎖條件同一個FB拉出來配置一下用在哪都是它。第四層是驅(qū)動層直接控制硬件輸出和讀取硬件輸入包括IO卡件的讀寫、模擬量采集、通訊指令的觸發(fā)。這一層離硬件最近也是最需要小心處理的一層。3.2 狀態(tài)機設(shè)計SCL寫狀態(tài)機比梯形圖舒服太多每個工位在程序里的本質(zhì)是一個狀態(tài)機。我把手動模式、自動模式、維護模式三種狀態(tài)分開互相之間切換必須有嚴(yán)格的握手和條件判斷不允許隨意跳轉(zhuǎn)。SCL寫狀態(tài)機的優(yōu)勢在于CASE語句。一個焊接工位的自動流程可以寫成CASE StepNo OF 0: // 等待啟動 IF StartCmd AND SafetyOK THEN StepNo : 10; END_IF; 10: // 取料 IF GripperOpenCmd THEN StepNo : 20; END_IF; 20: // 夾緊 IF ClampDone THEN StepNo : 30; END_IF; 30: // 焊接 IF WeldFinish THEN StepNo : 40; END_IF; 40: // 松開放行 IF UnclampDone THEN StepNo : 0; END_IF; END_CASE;這段邏輯用梯形圖當(dāng)然也能做但狀態(tài)多了以后梯形圖會變成一堆互鎖線圈和跳轉(zhuǎn)網(wǎng)絡(luò)讀起來像一張“蜘蛛網(wǎng)”調(diào)試和排故都很痛苦。SCL的CASE結(jié)構(gòu)任何人掃一眼就知道整個工位的動作流程。3.3 數(shù)據(jù)塊的復(fù)用性設(shè)計電池產(chǎn)線設(shè)備類型多但很多動作是重復(fù)的氣缸推進、夾緊、定位、掃碼、稱重、報警。我把每個工位的數(shù)據(jù)結(jié)構(gòu)統(tǒng)一成六個區(qū)域輸入?yún)^(qū)、輸出區(qū)、參數(shù)區(qū)、狀態(tài)區(qū)、報警區(qū)、追溯區(qū)。不管新項目還是改造項目只要結(jié)構(gòu)統(tǒng)一程序復(fù)制過來改改參數(shù)就能用。這個習(xí)慣幫我節(jié)約了大量重復(fù)開發(fā)時間。新的工位投產(chǎn)時先復(fù)制一個標(biāo)準(zhǔn)工位FB改一下IO映射和參數(shù)配置再根據(jù)具體工藝增加特殊邏輯開發(fā)周期大幅縮短。對于CATL這種客戶他們非?？粗爻绦虻囊?guī)范性和一致性因為這意味著后續(xù)維護成本低換人接手也快。4. SCL代碼在電池產(chǎn)線的典型應(yīng)用實例4.1 極耳焊接坐標(biāo)換算的SCL實現(xiàn)極耳焊接是模組段的關(guān)鍵工序焊點位置跟電芯極耳的實際狀態(tài)有關(guān)絕不是固定坐標(biāo)。這里需要根據(jù)電芯的條碼查配方、根據(jù)疊片數(shù)算補償量、再結(jié)合視覺反饋做微調(diào)。這段邏輯用梯形圖寫會非常痛苦用SCL寫就非常自然。下面是一段實際焊點坐標(biāo)換算的簡化版SCL示例我在真實項目中就是把類似邏輯封裝在FB里反復(fù)調(diào)用FUNCTION_BLOCK FB_WeldPosCalc VAR_INPUT CellCode : STRING; // 電芯條碼 LayerCount : INT; // 當(dāng)前模組的電芯層數(shù) VisionOffsetX : REAL; // 視覺反饋的X偏移 VisionOffsetY : REAL; // 視覺反饋的Y偏移 RecipeIndex : INT; // 配方索引號 END_VAR VAR_OUTPUT WeldPosX : REAL; // 實際焊點X坐標(biāo) WeldPosY : REAL; // 實際焊點Y坐標(biāo) ValidFlag : BOOL; // 坐標(biāo)有效標(biāo)志 END_VAR VAR_TEMP BaseX : REAL; BaseY : REAL; LayerOffset : REAL; TempReal : REAL; END_VAR // 1. 根據(jù)配方索引從配方DB中讀取基礎(chǔ)坐標(biāo) BaseX : RecipeDB.Recipe[RecipeIndex].BasePosX; BaseY : RecipeDB.Recipe[RecipeIndex].BasePosY; // 2. 層數(shù)補償每層電芯的高度差異換算成Y方向偏移 LayerOffset : INT_TO_REAL(LayerCount) * RecipeDB.Recipe[RecipeIndex].LayerStep; // 3. 疊加視覺修正量輸出最終坐標(biāo) WeldPosX : BaseX VisionOffsetX; WeldPosY : BaseY VisionOffsetY LayerOffset; // 4. 有效性判斷防止坐標(biāo)超出焊機工作范圍 IF (WeldPosX RecipeDB.Recipe[RecipeIndex].MinX) AND (WeldPosX RecipeDB.Recipe[RecipeIndex].MaxX) AND (WeldPosY RecipeDB.Recipe[RecipeIndex].MinY) AND (WeldPosY RecipeDB.Recipe[RecipeIndex].MaxY) THEN ValidFlag : TRUE; ELSE ValidFlag : FALSE; WeldPosX : 0.0; WeldPosY : 0.0; END_IF;這段代碼的邏輯很簡單但包含了一個非常重要的思想把“工藝公式”和“設(shè)備邏輯”分離開。配方DB里存的是工藝工程師會調(diào)的東西比如基礎(chǔ)坐標(biāo)、層補償量、范圍限制SCL代碼里則是固定的算法。工藝人員不用碰PLC程序只需要在HMI或者配方管理界面改數(shù)值就行。實際項目中我會在此基礎(chǔ)上加更多的安全邊界判斷比如坐標(biāo)突變報警、視覺反饋丟失報警、多個電芯坐標(biāo)一致性檢查等。這些邏輯用SCL寫出來非常自然用梯形圖寫則要多出至少五六倍的網(wǎng)絡(luò)可讀性還差一大截。4.2 擰緊數(shù)據(jù)采集與判定SCL與MES交互的硬骨頭電池模組里有大量的螺栓連接每一個螺栓基本都有扭矩要求。擰緊控制器通常用阿特拉斯、馬頭、丹納赫這些牌子一般自己會做擰緊結(jié)果的判斷但PLC這邊還得做二次判定和追溯數(shù)據(jù)整理。每條擰緊數(shù)據(jù)包含扭矩、角度、時間戳、條碼信息要把這些數(shù)據(jù)和當(dāng)前模組的條碼綁定再打包上傳MES。擰緊控制器通常通過PROFINET或者以太網(wǎng)跟PLC通訊。PLC側(cè)要寫通訊功能塊把擰緊控制器的數(shù)據(jù)塊映射到自己的DB里。然后用SCL做一個FB從DB中提取數(shù)據(jù)做二次判斷生成追溯報文發(fā)送給MES。FUNCTION_BLOCK FB_TightenData VAR_INPUT Trigger : BOOL; // 擰緊完成觸發(fā)信號 TorqueValue : REAL; // 實際扭矩值 AngleValue : REAL; // 實際角度值 TorqueLimitLo : REAL; // 扭矩下限 TorqueLimitHi : REAL; // 扭矩上限 AngleLimitLo : REAL; // 角度下限 AngleLimitHi : REAL; // 角度上限 END_VAR VAR_OUTPUT ResultOK : BOOL; // 擰緊結(jié)果合格 UploadEnable : BOOL; // 允許上傳 END_VAR IF Trigger THEN // 扭矩和角度都在范圍內(nèi)才算合格 IF (TorqueValue TorqueLimitLo) AND (TorqueValue TorqueLimitHi) AND (AngleValue AngleLimitLo) AND (AngleValue AngleLimitHi) THEN ResultOK : TRUE; UploadEnable : TRUE; ELSE ResultOK : FALSE; UploadEnable : TRUE; // 不合格也需要上傳追溯 END_IF; ELSE ResultOK : FALSE; UploadEnable : FALSE; END_IF;這個FB的輸入輸出可以擴展到多組擰緊軸用數(shù)組來存儲每一根軸的數(shù)據(jù)再配合FOR循環(huán)統(tǒng)一處理。這又是一波SCL的優(yōu)勢——循環(huán)處理數(shù)組比梯形圖里一個一個變量翻看得心應(yīng)手多了。4.3 節(jié)拍統(tǒng)計與OEE計算的SCL封裝電池產(chǎn)線對節(jié)拍的關(guān)注幾乎是一刻不停的?，F(xiàn)場調(diào)試階段工藝工程師、ME工程師、生產(chǎn)經(jīng)理每個人都在盯“單工位節(jié)拍是多少秒”“整線節(jié)拍多少秒”這就需要在PLC側(cè)做節(jié)拍統(tǒng)計。我用SCL寫了一組節(jié)拍統(tǒng)計FB能實時統(tǒng)計每個工位每個循環(huán)的時間自動記錄最長、最短、平均時間超過設(shè)定閾值就報警。這個FB里會記錄每個工位最后一次啟動時間計算循環(huán)總耗時通過浮點累加和計數(shù)算出平均節(jié)拍。這些數(shù)據(jù)可以供HMI查詢也可以按MES協(xié)議定期上傳。寫這種功能塊的難點不在算法在于數(shù)據(jù)的合理性判斷比如某個循環(huán)時間異常短可能是設(shè)備沒有按照流程走完就跳過了這不能算有效節(jié)拍數(shù)據(jù)。我一般會在FB內(nèi)部加一個最小節(jié)拍過濾低于最小值的循環(huán)不計入統(tǒng)計這樣一來統(tǒng)計結(jié)果就非常貼合實際產(chǎn)線表現(xiàn)。4.4 梯形圖在安全聯(lián)鎖與基本動作控制中的角色說句實話SCL再強安全聯(lián)鎖和基本動作我還是傾向于用梯形圖。為什么因為梯形圖直觀維護電工能看懂。急停、安全門、光柵、雙手啟動、復(fù)位回路這些邏輯必須讓人一眼看懂萬一設(shè)備出了假動作查起來才快。梯形圖的每個網(wǎng)絡(luò)就是一個確定的邏輯關(guān)系邏輯關(guān)系清晰可見不容易出錯。比如一個工位自動啟動的條件用梯形圖寫出來是這個味道急?；芈芬褟?fù)位安全門關(guān)閉光柵未被遮擋氣源壓力正常伺服驅(qū)動器無報警所有氣缸處于原始位遠程/本地模式正確這些條件全部“串”在一條梯形圖網(wǎng)絡(luò)里任何一個不滿足輸出就為FALSE禁止自動啟動。維護人員看到這臺網(wǎng)絡(luò)誰都能明白為什么設(shè)備不啟動拿萬用表量一下是哪個條件不滿足直接定位到具體傳感器或者硬件。如果用SCL寫成一個IF嵌套雖然邏輯上也成立但查詢排障的直觀性就差很多。5. 實操中的常見問題與排查方法5.1 SCL數(shù)組越界與訪問故障這是SCL編程最經(jīng)典的坑也是我入行時吃了大虧的地方。比如說配方數(shù)據(jù)我用數(shù)組來存但如果配方索引超出上限程序直接報“區(qū)域長度錯誤”嚴(yán)重的CPU直接進STOP?，F(xiàn)場設(shè)備還在生產(chǎn)CPU突然停機這個場面想想就頭大。解決辦法就是在寫所有數(shù)組訪問前都加索引判斷。先把索引限制在合法范圍內(nèi)再用一個單獨的狀態(tài)位告訴上位機“配方索引非法”。讀數(shù)組前先判斷別怕多幾行代碼。IF (RecipeIndex 1) AND (RecipeIndex 20) THEN // 合法索引正常讀取 BaseX : RecipeDB.Recipe[RecipeIndex].BasePosX; ELSE // 非法索引置為缺省值并報警 BaseX : 0.0; AlarmDB.RecipeIndexAlarm : TRUE; END_IF;自己平時寫SCL塊沒事就加邊界判斷這也是為什么我推薦所有SCL的數(shù)組訪問都要養(yǎng)成加判斷的習(xí)慣。5.2 數(shù)據(jù)類型不匹配導(dǎo)致的隱形問題SCL對數(shù)據(jù)類型的要求比梯形圖嚴(yán)格得多。INT和REAL混算、DINT和INT互轉(zhuǎn)、TIME和REAL比較這些搞不好就是程序跑飛或者數(shù)據(jù)錯亂。我印象最深的是一次擰緊角度上傳MES的問題。擰緊角度在PLC里是REAL類型精度沒問題但到MES上傳時轉(zhuǎn)成STRING結(jié)果小數(shù)點精度不對上傳的數(shù)據(jù)總是差一點點工藝人員拉著我查了好久最后發(fā)現(xiàn)是不同工程師寫的轉(zhuǎn)換函數(shù)精度設(shè)置不一致。后來定了一個規(guī)矩所有數(shù)值型參數(shù)進入通訊區(qū)域后一律用標(biāo)準(zhǔn)格式轉(zhuǎn)換函數(shù)統(tǒng)一處理不能在程序里各寫各的轉(zhuǎn)換邏輯。這個規(guī)矩立起來之后通訊數(shù)據(jù)格式的坑少了很多。5.3 與MES通訊中斷時的數(shù)據(jù)緩存電池產(chǎn)線要求跟MES的交互不能丟數(shù)據(jù)這是硬指標(biāo)?，F(xiàn)場網(wǎng)絡(luò)總會有抖動程序如果沒做緩存機制模組的追溯數(shù)據(jù)就可能丟掉。這對電池行業(yè)是不可接受的因為追溯鏈路斷了等于批次報廢。我在項目里都會在PLC側(cè)做一個FIFO緩存區(qū)。SCL里把待上傳的數(shù)據(jù)先存入緩存每次上電初始化時檢查緩存區(qū)是否為空如果有未上傳的數(shù)據(jù)優(yōu)先完成補傳再處理當(dāng)前新產(chǎn)生的數(shù)據(jù)。這個邏輯相對復(fù)雜但非常必要調(diào)試中起碼有一半時間都花在這上面。FIFO緩存區(qū)的實現(xiàn)可以用一個數(shù)組加上讀指針和寫指針SCL寫起來非常順手// 寫數(shù)據(jù) IF WriteIndex MaxBufferSize THEN Buffer[WriteIndex] : NewData; WriteIndex : WriteIndex 1; ELSE BufferFull : TRUE; END_IF; // 讀數(shù)據(jù) IF ReadIndex WriteIndex THEN UploadData : Buffer[ReadIndex]; ReadIndex : ReadIndex 1; ELSE // 緩存清空復(fù)位指針 ReadIndex : 0; WriteIndex : 0; END_IF;5.4 仿真與實機的差異S7-1500用PLCSIM模擬運行時很多IO時序和通訊行為模擬不出來尤其是伺服和擰緊軸的通訊。仿真跑通了不代表實機沒問題很多人仿真通過就以為萬事大吉結(jié)果到現(xiàn)場一調(diào)試伺服沒使能、掃碼槍數(shù)據(jù)格式不對各種問題都冒出來。我的經(jīng)驗是仿真只用來驗證邏輯不驗證硬件。寫好的SCL塊先扔進PLCSIM里把邊界條件測一遍看邏輯是否跟預(yù)期一致到了現(xiàn)場把所有跟硬件通訊相關(guān)的塊單獨檢查一遍通訊配置、設(shè)備地址、數(shù)據(jù)格式、超時設(shè)置逐項確認(rèn)。這個“先軟后硬”的順序至少能少走一半彎路。6. 項目調(diào)試與交付中的經(jīng)驗心得給CATL這種級別客戶做項目程序只是一部分文檔和交付標(biāo)準(zhǔn)同樣重要。程序得有清晰的注釋規(guī)范數(shù)據(jù)塊得有變量說明表報警文本要能直接定位到具體PLC地址。S7-1500的FB塊可以給每個輸入輸出寫注釋這個功能我強烈建議用起來后期維護時看注釋比看程序快十倍。報警文本的規(guī)范也很重要。一份好的報警文本要包含設(shè)備名稱、部件名稱、故障類型、可能原因、處理建議還得給出監(jiān)控的PLC地址這樣維修人員掃一眼報警就能定位到具體位置。我在項目里會把報警文本統(tǒng)一放在一個DB里每個報警條目配一個布爾觸發(fā)位這樣HMI畫面和程序邏輯解耦后期改報警文本不會動到程序邏輯。另外給客戶的程序最好把保密的部分做成加密塊把可維護的部分留出來。不是說不信任客戶而是電池廠的控制系統(tǒng)涉及到很多工藝Know-how程序?qū)用孀鲆粋€合理的邊界劃分對雙方都負(fù)責(zé)。7. SCL與梯形圖的選型平衡一種可復(fù)用的取舍方法最后再聊一下編程語言選型的平衡。很多剛?cè)胄械墓こ處熡幸粋€誤解覺得SCL是“高級語言”所以全部用SCL梯形圖就是落后。這個想法在電池產(chǎn)線這種大項目里很危險。語言只是工具效果才是目的。我有一套自己的取舍標(biāo)準(zhǔn)可以供你參考凡是涉及復(fù)雜計算、通訊協(xié)議解析、數(shù)組遍歷、數(shù)據(jù)打包、配方運算的SCL負(fù)責(zé)凡是涉及安全回路、手動操作、基本順序啟動、線圈互鎖的梯形圖負(fù)責(zé)。兩邊通過統(tǒng)一的FB接口規(guī)范互相調(diào)用整個項目的可維護性會非常高。還有一點想提醒大家程序不是寫給自己看的是寫給下一個維護的人看的也可能就是幾個月后的自己。你在SCL里寫了多復(fù)雜的算法如果注釋不寫變量命名亂糟糟三個月后回頭看自己都想打人。變量命名我是硬性要求所有自動變量、手動變量、報警變量起名必須帶前綴能用全稱不用縮寫縮寫也要統(tǒng)一縮寫表。這個習(xí)慣前期多花一點時間后期維護效率直線上升。8. 寫在最后做電池產(chǎn)線項目這幾年我最大的體會是控制系統(tǒng)的價值不在于你用多高級的語言、寫多炫酷的算法而在于程序穩(wěn)定、可維護、能扛住產(chǎn)線嚴(yán)苛的節(jié)拍和追溯要求。CATL這種客戶最看重的就是“穩(wěn)定”和“規(guī)范”四個字。再分享一個小細(xì)節(jié)電池產(chǎn)線的安全邏輯絕對不能省。急停、門鎖、光柵、安全PLC、安全繼電器該上的都得上了程序里也要做軟件層面的安全聯(lián)鎖。我在做每個工位的自動流程之前都會把該工位的安全條件列一張表形成一張真正的“安全矩陣”然后嚴(yán)格按矩陣在梯形圖里實現(xiàn)。這個做法做習(xí)慣了以后后面所有新工位在這個環(huán)節(jié)上都會很穩(wěn)幾乎不會在安全邏輯上返工。如果你正在做或者準(zhǔn)備做電池產(chǎn)線、新能源產(chǎn)線的自動化項目希望這篇文章能給你一些參考。SCL和梯形圖怎么選、程序怎么分層、通訊數(shù)據(jù)怎么處理、調(diào)試時先做哪一步這些問題的答案未必唯一但一定要有自己的方法論。有問題歡迎隨時交流后面我還會繼續(xù)分享電池產(chǎn)線相關(guān)的實際項目經(jīng)驗。本文還有配套的精品資源點擊獲取