干設備遠程運維這幾年我最常被問到的一句話是“你們現(xiàn)場那臺PLC的數(shù)據(jù)到底是怎么弄到云平臺上去的”以前我給出的標準答案是“PLC加工業(yè)網(wǎng)關”兩件套PLC管控制邏輯網(wǎng)關管協(xié)議轉(zhuǎn)換和數(shù)據(jù)轉(zhuǎn)發(fā)。后來我換了一種做法直接用一臺把上云能力做進本體里的PLC——Tenlink TM1200。不管你是給數(shù)控機床做數(shù)據(jù)采集還是想把變頻器、溫控表、傳感器連進云端看板這篇文章都值得花十分鐘看一眼。它不是照著產(chǎn)品手冊念參數(shù)而是我基于手冊跑完實際項目之后把這臺上云PLC的采集思路、配置路徑、典型坑位逐層拆開講的完整復盤。1. 這臺上云PLC到底改變了什么傳統(tǒng)“PLC加網(wǎng)關”模式的痛點1.1 傳統(tǒng)模式的三大痛點先說清楚以前怎么干活。大部分老產(chǎn)線的設備監(jiān)控是這么搭的現(xiàn)場PLC負責采集傳感器信號和執(zhí)行邏輯觸摸屏放在機臺上讓人看。數(shù)據(jù)想上云就必須在PLC旁邊再加一臺工業(yè)網(wǎng)關。網(wǎng)關通過Modbus RTU、Modbus TCP或者OPC UA去讀PLC里的寄存器把數(shù)據(jù)重新打包成MQTT協(xié)議再發(fā)給云平臺。這套架構在中小項目里跑起來沒有問題但項目一旦鋪開痛點就非常明顯。第一是鏈路長故障點翻倍。PLC到網(wǎng)關之間有一條串口線或者網(wǎng)線網(wǎng)關那邊又要一路4G或者以太網(wǎng)。哪一端接觸不良、電磁干擾、網(wǎng)關死機云平臺上的設備狀態(tài)就變成離線。我在現(xiàn)場排查過很多次“設備離線”的故障查到最后發(fā)現(xiàn)只是網(wǎng)關旁邊的電源適配器掛了。多一個盒子就多一個出問題的機會。第二是點位表維護非常痛苦。PLC里的寄存器定義一份文檔網(wǎng)關的配置工具里再做一次映射云平臺那邊還得再建一遍變量。現(xiàn)場設備一多點位改動一次就要同時在兩三個地方改很容易出現(xiàn)PLC里已經(jīng)改了地址、網(wǎng)關和云平臺還在用舊地址的情況最后數(shù)據(jù)對不上調(diào)半天才發(fā)現(xiàn)是映射沒同步。第三是調(diào)試協(xié)作效率太低。設備廠家、集成商、云平臺開發(fā)經(jīng)常是三個團隊在干活?，F(xiàn)場工程師在PLC里改了一段邏輯云端工程師不知道云端調(diào)整了報警閾值現(xiàn)場工程師也不清楚。兩邊對著一個“半透明”的鏈路來回溝通項目交付周期就被拖長了。1.2 TM1200的整合思路Tenlink TM1200這條產(chǎn)品線本質(zhì)上是在回答一個問題既然PLC本身就在采集數(shù)據(jù)為什么不把上云這件事也放進去所以它的定位不是“帶網(wǎng)口的PLC”而是“PLC本體加上數(shù)據(jù)網(wǎng)關加云連接終端”三合一。本地控制邏輯照常跑數(shù)字量、模擬量采集照常做同時內(nèi)置的數(shù)據(jù)引擎會把采集到的寄存器值、IO狀態(tài)和診斷信息直接同步到云端平臺。整個過程不再需要單獨一臺網(wǎng)關在邊上轉(zhuǎn)譯。這里面的關鍵設計在于兩條鏈路是分開的。邏輯控制走掃描周期數(shù)據(jù)上云走獨立的數(shù)據(jù)發(fā)布通道。就算云平臺暫時連不上本地控制也不會受影響PLC該執(zhí)行梯形圖還是執(zhí)行梯形圖。這個特性對產(chǎn)線運行非常重要自動化設備可以允許數(shù)據(jù)短暫不顯示但絕對不能允許因為通信問題把控制邏輯帶崩。1.3 誰最需要這種產(chǎn)品從我接觸到的項目看適合用TM1200的人群很典型。設備制造商OEM是最匹配的。他們賣出去的包裝機、注塑機、灌裝機分布在各個客戶現(xiàn)場以前設備出了問題只能售后出差或者等客戶打電話描述現(xiàn)象。用了上云PLC以后遠程就能看到這臺設備的運行狀態(tài)、當前報警碼、主軸溫度曲線很多故障電話還沒打完故障原因就已經(jīng)定位了。第二類是系統(tǒng)集成商。他們在改造老產(chǎn)線時經(jīng)常要在一個柜子里同時處理PLC、變頻器、觸摸屏、電表、溫控表多種設備。TM1200可以充當Modbus主站把這些第三方設備的數(shù)據(jù)集中讀回來再上云柜內(nèi)接線反而簡化了。第三類是終端工廠的設備科。工廠需要統(tǒng)計設備OEE、開機率、故障時長核心是判斷“設備當前在不在干活”。有了云平臺上的實時狀態(tài)這些指標不用再讓班組長手工填表系統(tǒng)自動就能算出來。2. 數(shù)據(jù)采集的底層功底Modbus輪詢、OPC UA接口與點位映射2.1 先看硬件IO和模擬量通道講上云之前先回到PLC最本職的工作采集。TM1200本體上帶有數(shù)字量輸入輸出和模擬量通道。數(shù)字量輸入用來接按鈕、限位開關、繼電器觸點數(shù)字量輸出直接驅(qū)動接觸器、電磁閥、指示燈。模擬量輸入支持4-20mA和0-10V信號可以直接接溫度變送器、壓力變送器接入以后儀表本身的一個電流信號就變成了PLC里的一個整數(shù)。這里有一個很實際的調(diào)試經(jīng)驗模擬量信號的現(xiàn)場毛刺遠比想象中多。特別是變頻器附近屏蔽做得不好采樣值會上下跳。處理這類問題最好的辦法是在PLC程序里做一階低通濾波把突變信號平滑掉。濾波系數(shù)不要一味調(diào)大因為濾波越大響應越慢做溫度控制時反而會讓溫度PID波動加大。那類“plc溫度pid波動溫差大如何調(diào)節(jié)”的問題有一半其實不是PID參數(shù)問題而是信號本身沒處理好。2.2 Modbus主站向下去讀變頻器、電表、溫控表TM1200作為Modbus RTU主站可以通過RS485總線去輪詢現(xiàn)場的第三方設備。ABB的變頻器、西門子的變頻器、森蘭的通用變頻器、各種電表和溫控表絕大多數(shù)都支持Modbus RTU協(xié)議。配置的時候只需要弄清楚從站地址、波特率、數(shù)據(jù)位停止位校驗位然后把要讀的寄存器功能碼填進去。實際項目中我常用的方式把變頻器的運行頻率、輸出電流、母線電壓這些參數(shù)讀到PLC的保持寄存器里經(jīng)過量程轉(zhuǎn)換再傳給云平臺。比如某臺變頻器的頻率寄存器值是40001有些設備從40001開始數(shù)據(jù)類型是16位無符號整數(shù)實際值是寄存器值的10倍。這個10倍關系必須在PLC側(cè)處理完云平臺上顯示的才是真正可讀的58.5Hz而不是585。輪詢周期是必須算的不能拍腦袋。一個經(jīng)驗公式是單站輪詢時間等于收發(fā)幀時間加設備響應時間加上延遲乘上總站數(shù)。一臺響應時間50毫秒的變頻器波特率9600下讀一次4個寄存器大概需要30毫秒幀時間單站大約80毫秒十個站就是800毫秒。所以點位刷新周期設置在1秒以上才合理。如果又掛了溫控表又掛了電表建議把點位分成慢周期和快周期兩組慢的5秒一輪快的1秒一輪。2.3 OPC UA向上去對接MES/SCADA也能采集數(shù)控機床Modbus很好用但它是老協(xié)議?，F(xiàn)在新建工廠要么用西門子S7協(xié)議要么直接用OPC UA。TM1200集成了OPC UA服務器端對外暴露標準的OPC UA接口端口4840MES系統(tǒng)、SCADA系統(tǒng)、組態(tài)軟件比如WinCC都可以直接以OPC UA客戶端身份去讀取這臺PLC的數(shù)據(jù)。集成商最頭疼的“每個PLC廠商一種私有通信協(xié)議”的問題在OPC UA這里被統(tǒng)一掉了。更討巧的用法是讓TM1200作為OPC UA客戶端去采集那些本身支持OPC UA的新設備?，F(xiàn)在不少數(shù)控機床、智能傳感器、注塑機控制系統(tǒng)都直接內(nèi)置了OPC UA Server。用PLC去主動連它們的OPC UA接口不需要破線不需要知道寄存器地址拿到的是設備廠家定義好的結(jié)構化數(shù)據(jù)。對于“讀取傳感器、數(shù)控機床等設備的運行狀態(tài)數(shù)據(jù)判斷設備是否正?！边@類需求OPC UA采集是最省事的一條路。有一點要注意OPC UA走以太網(wǎng)涉及IP地址規(guī)劃、安全策略和證書配置。首次連接時雙方要互認證書現(xiàn)場調(diào)試時經(jīng)常因為證書不匹配導致連接失敗這個放到后面避坑章節(jié)細說。2.4 點位表設計從“485寄存器號”到“有意義的變量名”數(shù)據(jù)采集最終要落到一張點位表上。點位表不是寫給自己看的是給整個項目所有參與者看的。我在項目里的習慣是按“設備-子系統(tǒng)-參數(shù)”三層建模直接舉一個機床監(jiān)控的實例點位名稱來源寄存器數(shù)據(jù)類型量程轉(zhuǎn)換上報條件主軸電流變頻器4000116位無符號實際值寄存器值/10變化超過0.5A上報主軸溫度溫度變送器AIW0映射D20016位無符號4-20mA對應0-100℃變化超過1℃上報冷卻液液位液位開關DI1布爾無狀態(tài)翻轉(zhuǎn)立即上報變頻器運行頻率變頻器4000216位無符號實際值寄存器值/10變化超過0.2Hz上報設備運行狀態(tài)PLC內(nèi)部M100布爾無狀態(tài)翻轉(zhuǎn)立即上報點位命名規(guī)范直接決定云平臺看板后面好不好維護。直接叫“溫度”的點位到第三個月你自己都會忘掉它是哪臺設備的溫度。前綴建議帶設備編號和子系統(tǒng)比如“M01_Spindle_Temp”后面看板排序、報表導出、報警追溯都省心。3. 數(shù)據(jù)上行鏈路的設計邏輯邊緣處理、斷網(wǎng)補償與設備安全3.1 云連接方式和數(shù)據(jù)格式TM1200的上云通道有兩條有線網(wǎng)口和4G模塊。兩種方式都行看現(xiàn)場條件。固定產(chǎn)線建議走有線信號穩(wěn)定移動設備或者偏遠站點直接上4G模塊插一張物聯(lián)網(wǎng)卡就能用。上云協(xié)議用的是MQTT數(shù)據(jù)包以JSON格式打包。MQTT是輕量級發(fā)布訂閱協(xié)議長連接保持非常適合PLC這種“數(shù)據(jù)量不大但要求實時性”的場合。一條典型的上行數(shù)據(jù)長這樣{ device: TM1200-20240601, timestamp: 2025-01-15T10:23:4508:00, points: { M01_Spindle_Temp: 52.3, M01_Spindle_Current: 18.5, M01_Status: 1 } }時間戳一定要帶時區(qū)而且最好是設備本地時間。不要用云平臺接收時間當數(shù)據(jù)時間因為斷網(wǎng)補傳的時候數(shù)據(jù)時間和接收時間完全是兩回事。3.2 邊緣規(guī)則引擎不是所有數(shù)據(jù)都有必要上傳很多第一次做上云項目的人容易犯一個錯誤把所有PLC變量全部按1秒周期往上推。結(jié)果一個站點一小時產(chǎn)生幾千條數(shù)據(jù)流量費看著就心疼云平臺收到的數(shù)據(jù)大部分還都是重復的。TM1200內(nèi)部有邊緣規(guī)則配置要利用起來。我的做法是分三類處理設備狀態(tài)類點位狀態(tài)一旦翻轉(zhuǎn)立即上報不上報周期。因為客戶在云平臺上最關心的就是設備有沒有停機、有沒有報警這類信息講究時效性一秒都不能拖。過程量點位比如溫度、壓力、電流設置變化死區(qū)上報。溫度穩(wěn)定在52到53度之間波動時不需要一直上報變化超過1度再上報即可。這樣既保證趨勢曲線連續(xù)又砍掉大量重復數(shù)據(jù)。統(tǒng)計類數(shù)據(jù)比如開機時長、總產(chǎn)量按固定周期定時上報就行上報周期根據(jù)業(yè)務需求定一般用5分鐘或者10分鐘。報警判斷我強烈建議放在PLC本地做不要等云平臺判斷。PLC掃描周期毫秒級云平臺規(guī)則引擎秒級本地判斷能捕捉到更短促的故障瞬間。報警條件、恢復條件、報警級別都在PLC程序里寫清楚觸發(fā)以后把狀態(tài)位推上云云平臺只負責展示和通知。3.3 斷網(wǎng)緩存和續(xù)傳4G信號不好是現(xiàn)場常態(tài)尤其工廠里鋼結(jié)構多信號屏蔽嚴重。TM1200的數(shù)據(jù)鏈路里設計了斷網(wǎng)緩存機制本地有一個數(shù)據(jù)暫存區(qū)斷網(wǎng)期間數(shù)據(jù)按設定周期繼續(xù)寫入恢復網(wǎng)絡后按時間順序補傳。斷網(wǎng)補償是無縫的但云平臺側(cè)要配合做一件很重要的事區(qū)分“遲到數(shù)據(jù)”和“實時數(shù)據(jù)”。建議協(xié)議里帶時間戳渲染時如果發(fā)現(xiàn)數(shù)據(jù)時間戳比當前時間晚超過一定閾值比如10秒就把它歸入歷史數(shù)據(jù)不能覆蓋當前最新狀態(tài)。這樣才能保證看板上顯示的狀態(tài)始終是最新時刻的現(xiàn)場情況。3.4 工控安全的幾個基本動作設備上云之后安全邊界就變成了一條數(shù)字邊界。我列幾個必須做到的基礎項TLS加密傳輸、設備證書認證、云平臺賬號權限隔離、默認密碼強制修改。TM1200本身支持證書配置和加密通信上電第一步建議就把默認密碼改掉再把設備綁定到指定項目組不要用一個裸奔的設備直接連云端。工業(yè)現(xiàn)場網(wǎng)絡如果是開放式辦公網(wǎng)復用最好做VLAN隔離把PLC、數(shù)控機床這些生產(chǎn)設備單獨劃一個網(wǎng)段辦公網(wǎng)訪問不到只有云平臺通過白名單訪問。這個不復雜但很多小廠沒人管安全風險就在這。4. 從接線到云看板走通第一條數(shù)據(jù)我實測的完整配置路徑4.1 硬件接線和檢查拿到TM1200之后第一次上電前的檢查順序我建議按這幾步走。電源接線要看好極性DC24V電源正負極別接反。一個容易忽略的細節(jié)是開關電源的功率余量。如果同一柜子里接觸器、繼電器頻繁動作電源瞬間跌落會導致PLC重啟所以我一般會選額定功率1.5倍以上的開關電源。RS485接線要按標準來A/B兩根線別接反屏蔽層單端接地所有設備手拉手串接不要星型連接?？偩€兩端接終端電阻如果總線上有十臺設備線又比較長終端電阻不接就會出現(xiàn)數(shù)據(jù)錯亂。波特率統(tǒng)一設置設備之間不一致就通不上。網(wǎng)線的坑反而常見很多現(xiàn)場“模塊識別不了”的問題最后查出來是網(wǎng)線只壓了四根芯。檢查網(wǎng)線的時候直接看燈交換機端口燈亮且是綠色鏈路基本沒問題。4.2 在PLC里準備好數(shù)據(jù)字典上電完成后先在PLC程序里把要上云的變量梳理出來。比如采集一路溫度信號模擬量通道AIW0經(jīng)過量程轉(zhuǎn)換寫入保持寄存器D200梯形圖大概是這樣一個思路讀模擬量原始值減去偏移量乘工程系數(shù)存到D200再觸發(fā)一個上云標記。這步真正要花心思的是寄存器規(guī)劃。這一點和傳統(tǒng)PLC的使用習慣非常一致——類似三菱FX3U的D0到D8默認斷電不保持需要保持的數(shù)據(jù)要放到斷電保持寄存器區(qū)。TM1200做數(shù)據(jù)字典的時候哪些數(shù)據(jù)斷點后要保持、哪些不保持要提前規(guī)劃好否則設備斷電重啟云平臺會收到一批清零的初始值。4.3 建立變量表和上云映射接著在配置工具里建立變量映射表。把D200命名為“M01_Spindle_Temp”選擇數(shù)據(jù)類型為16位無符號整數(shù)設置量程上下限是0到100攝氏度再從溫度變送器的說明書里核對4mA對應0度、20mA對應100度。映射關系里最容易出問題的是數(shù)據(jù)類型。Modbus寄存器默認是16位但溫度值如果超過65535或者有小數(shù)要求就可能要組合成32位浮點數(shù)。這時候數(shù)據(jù)類型選錯了云平臺上讀到的就是亂碼一樣的大數(shù)。遇到這種情況第一反應不是懷疑PLC壞了而是查數(shù)據(jù)類型配置。4.4 本地模擬測試在沒有真實變頻器或者溫控表的情況下我習慣用一個Python腳本先模擬一個Modbus從站把整條采集鏈路打通。用pymodbus庫跑一個小服務開放幾個寄存器TM1200作為主站去讀讀回來的數(shù)據(jù)能出現(xiàn)在云平臺上說明這整條鏈路是通的。from pymodbus.server import StartTcpServer from pymodbus.datastore import ModbusSlaveContext, ModbusDataBlock # 模擬一個Modbus TCP從站開放3個保持寄存器 store ModbusSlaveContext( zero_modeTrue, diModbusDataBlock.create([0] * 32), coModbusDataBlock.create([0] * 32), hrModbusDataBlock.create([100, 585, 18.5 * 10]), # 對應溫度、頻率、電流 irModbusDataBlock.create([0] * 32) ) StartTcpServer(store, address(0.0.0.0, 502))這個腳本跑在調(diào)試電腦上TM1200的Modbus主站就去連這臺電腦的IP地址讀三個寄存器。能讀到再接真實的變頻器讀不到先查網(wǎng)絡再查協(xié)議參數(shù)。一步步縮小范圍比一次性接好全部設備再排錯要快得多。4.5 云平臺側(cè)創(chuàng)建設備和看板云平臺側(cè)的操作就比較常規(guī)了創(chuàng)建產(chǎn)品添加設備填設備ID和密鑰然后把點位表一次性導入批量綁定到數(shù)據(jù)字典?？窗逶O計建議先畫一個草圖搞清楚現(xiàn)場到底關心什么。設備狀態(tài)卡片放在最顯眼的位置下面是關鍵溫度曲線和報警列表報表做成每日匯總發(fā)給班組長。5. 與傳統(tǒng)PLC生態(tài)的關系編程習慣、觸摸屏和品牌PLC混用5.1 編程方式怎么上手很多工程師拿到一臺新PLC第一個問題是“我用三菱的會不會不習慣”。TM1200的編程環(huán)境基于IEC 61131-3標準支持梯形圖、結(jié)構化文本、功能塊圖幾種語言。梯形圖是老工程師的母語結(jié)構化文本適合做算法兩者可以在同一個工程里混用這個自由度比傳統(tǒng)單一品牌PLC要好。上手階段最容易忽略的反而不是語法而是“變量名觀念”。傳統(tǒng)PLC寫習慣了地址直接寫X0、Y0、D100。上云PLC更強調(diào)變量名程序里盡量用有意義的符號名IO地址只是底層的物理映射。習慣了這個寫法以后程序可讀性直線提升后期維護的人會感謝你。5.2 一臺PLC能不能接多個觸摸屏能而且不只是本地經(jīng)常有人問“一個PLC可以接兩個觸摸屏嗎”答案是能。傳統(tǒng)方案里以太網(wǎng)型觸摸屏只要在同一網(wǎng)段多臺可以同時連接同一臺PLC串口屏則通過擴展從站方式對接。TM1200給了第三種選擇它自帶云端畫面發(fā)布能力相當于給你加了一塊“云觸摸屏”。操作人員在手機或平板上打開云平臺就是一塊隨時隨地可訪問的觸摸屏。本地和云兩端都顯示同一套生產(chǎn)數(shù)據(jù)客戶車間經(jīng)理在辦公室就能看到機臺畫面遠程診斷也借助它解決了很多問題。5.3 當TM1200遇到西門子S7-200Smart、三菱FX3U、匯川AM763現(xiàn)實項目里TM1200不一定是一臺獨立運行的PLC它經(jīng)常作為“上云數(shù)據(jù)網(wǎng)關”疊加在原有PLC系統(tǒng)之上。比如客戶現(xiàn)場已經(jīng)有西門子S7-200Smart在跑控制邏輯不想替換就可以把S7-200Smart的通信口配置成Modbus RTU從站TM1200作為Modbus主站去讀它的數(shù)據(jù)再轉(zhuǎn)發(fā)到云平臺。這種情況下TM1200不參與控制只做數(shù)據(jù)采集和上云是性價比最高的改造路徑。三菱FX3U同理通過485BD板擴展的通信口可以走Modbus RTU協(xié)議地址映射關系在FX3U說明書里有詳細的對照表。匯川AM763這類新PLC本身雖帶以太網(wǎng)但如果你不想引入它的私有協(xié)議和編程環(huán)境TM1200同樣可以走Modbus TCP或者OPC UA去采集。這里還想回應那個“匯川AM763無法識別本地IO模塊”的熱搜問題這類新PLC的本地IO模塊識別失敗一般不是PLC壞了而是固件版本和模塊版本不匹配或者模塊插槽位置跳過了起始槽。無論用哪個品牌新PLC到貨第一件事就是確認固件版本升級到與模塊匹配的版本再下裝程序。5.4 遠程調(diào)試和固件升級TM1200支持云端遠程下載PLC程序這是讓我覺得真正省心的一項能力。以前改一段梯形圖就得跑一次現(xiàn)場現(xiàn)在只要在授權范圍內(nèi)遠程就能下裝。下裝前建議做一次完整備份包括程序、點位表、云映射配置防止下到一半發(fā)現(xiàn)改錯了還能一鍵回滾。固件升級要格外小心升級過程中絕對不允許斷電。升級前把程序和配置備份到本地然后再執(zhí)行。如果升級過程中網(wǎng)絡中斷設備可能會進入異常狀態(tài)有些情況下需要返廠恢復所以擴容或者升級操作建議安排在停機窗口內(nèi)做。6. 現(xiàn)場調(diào)試踩過的坑485總線、報警風暴和遠程維護的邊界6.1 485總線丟包和亂碼的排查鏈路Modbus RTU在現(xiàn)場最典型的問題就是丟包和亂碼我給出一個完整的排查順序。現(xiàn)象是變頻器數(shù)據(jù)偶爾讀到錯誤值比如頻率突然變成0或者變成幾千。第一步查物理層屏蔽層是否接了而且還接了地、終端電阻是否到位、線纜是不是雙絞線。第二步查參數(shù)配置從站地址、波特率、校驗位、數(shù)據(jù)位十之八九是兩臺設備參數(shù)不一致。第三步用Modbus調(diào)試工具抓幀報文出現(xiàn)CRC錯誤代表干擾嚴重報文正常再判斷寄存器類型、功能碼是否正確。現(xiàn)象優(yōu)先檢查項處理方案數(shù)據(jù)偶爾跳變屏蔽層接地、雙絞線、變頻器干擾降波特率、加485隔離器完全讀不到數(shù)據(jù)A/B正反、站號、波特率逐項核對用調(diào)試工具抓幀能讀到但數(shù)值錯誤寄存器類型、數(shù)據(jù)類型、倍率對照設備說明書逐字節(jié)解析溫度/電流波形毛刺模擬量濾波、信號源波動PLC側(cè)加一階低通濾波最后一條經(jīng)驗當現(xiàn)場實在找不到問題時試試把波特率從19200降到9600。低速傳輸抗干擾能力明顯更強代價只是刷新慢一點但在絕大多數(shù)工業(yè)傳感器場景下完全夠用。6.2 報警風暴怎么避免設備上云第一周是報警風暴的高發(fā)期?？蛻羰謾C一晚上收到幾百條報警推送直接想把系統(tǒng)關掉。原因很簡單報警閾值設得離正常工作點太近正常波動就觸發(fā)了。處理報警要從三個層面一起想閾值、回差、防抖。閾值不能只看正常工作值要看看設備調(diào)試期間出現(xiàn)過最大最小的瞬時值留足余量?；夭罹褪腔謴椭挡荒艿扔陂撝禍囟葓缶?0度只能到78度才恢復不然溫度剛好在79到80之間來回竄報警恢復會像呼吸燈一樣反復閃。防抖則是連續(xù)采集3秒都越限才觸發(fā)報警現(xiàn)場偶發(fā)的干擾脈沖不會造成誤報。PID溫差波動大的問題也類似先看采樣周期再看濾波最后調(diào)P和I。溫度系統(tǒng)普遍慣性大P值太大容易震蕩I值太大容易出現(xiàn)漂移原則是“先調(diào)P到穩(wěn)定不振蕩再加I消除靜差”不要一上來參數(shù)全改。6.3 遠程維護的安全邊界遠程調(diào)試能力是雙刃劍方便的同時意味著接通了一條遠程執(zhí)行的通道。我給自己立過幾條規(guī)矩賬號分級程序維護賬號和普通查看賬號分開。查看賬號只能看數(shù)據(jù)看板維護賬號才能遠程下裝?，F(xiàn)場下載程序的時候通知產(chǎn)線提前停機或換線不要在生產(chǎn)時段遠程改程序。所有人的操作都留日志云平臺上誰在什么時間改了哪臺設備一查便知。改之前完整備份改壞了能現(xiàn)場回退。做好這幾點遠程維護就是效率工具而不是風險敞口。6.4 云端數(shù)據(jù)“看起來不對”時先檢查哪一步客戶反饋“云平臺溫度和現(xiàn)場儀表差了很多”的時候我的排查順序固定是這樣先看量程設置4-20mA對應0-100度還是0-200度這一項占一半以上問題再看數(shù)據(jù)類型16位無符號和32位浮點讀出來的完全是兩個數(shù)字接著查倍率關系寄存器里存的是不是實際值的10倍最后才懷疑硬件采集問題。按這個順序多數(shù)“數(shù)據(jù)不對”的問題五分鐘就能定位。最后聊一點個人體會。用過TM1200之后我對“上云PLC”這個概念的理解變了很多。以前總覺得上云是PLC之外的事要加網(wǎng)關、加軟件、加人維護現(xiàn)在看上云本來就應該是PLC能力的一部分?，F(xiàn)場數(shù)據(jù)在哪產(chǎn)生就在哪變成云端數(shù)據(jù)。如果正準備給老產(chǎn)線做數(shù)字化改造我的建議是別急著鋪一堆網(wǎng)關和邊緣盒子先拿一臺TM1200把一個設備的點位表、云看板、報警邏輯跑通再考慮規(guī)模復制。這條路的調(diào)試成本比想象中低很多。