簡(jiǎn)介面向歐姆龍PLC及自動(dòng)化設(shè)備通信開發(fā)的FINS協(xié)議動(dòng)態(tài)庫資源包適合使用Delphi、VC、VB等語言編寫工業(yè)控制軟件的工程師。FINS協(xié)議支持寄存器讀寫、遠(yuǎn)程I/O操作與設(shè)備診斷該動(dòng)態(tài)庫實(shí)現(xiàn)多串口并發(fā)及多線程通信可避免阻塞主程序適用于多設(shè)備同時(shí)交互的自動(dòng)化場(chǎng)景。資源共42個(gè)文件壓縮包大小1.32MB主體包括4個(gè)DLL動(dòng)態(tài)庫與4個(gè)頭文件另含CHM操作手冊(cè)、Delphi/VB/VC三套示例工程以及相關(guān)源文件、演示程序便于開發(fā)者對(duì)照學(xué)習(xí)調(diào)用方式與參數(shù)設(shè)置。已有874人學(xué)習(xí)。通過手冊(cè)可系統(tǒng)掌握函數(shù)調(diào)用與錯(cuò)誤處理三套演示程序覆蓋通信配置、數(shù)據(jù)讀寫與界面交互等常見流程DLL實(shí)例可直接引用或修改后集成到項(xiàng)目中能顯著縮短歐姆龍?jiān)O(shè)備通信功能的開發(fā)周期提升現(xiàn)場(chǎng)調(diào)試與維護(hù)效率。1. 為什么需要FINS動(dòng)態(tài)庫從一次通信故障說起某公司新上線一套數(shù)據(jù)采集系統(tǒng)需要把產(chǎn)線上幾臺(tái)歐姆龍PLC的DM區(qū)數(shù)據(jù)實(shí)時(shí)撈到組態(tài)畫面上。開發(fā)的同學(xué)拿著協(xié)議文檔照葫蘆畫瓢寫了將近兩百行Socket代碼結(jié)果一到現(xiàn)場(chǎng)就頻繁“超時(shí)”查了三天才發(fā)現(xiàn)DM區(qū)地址被當(dāng)成CIO區(qū)地址解析響應(yīng)幀里多出的一個(gè)字節(jié)沒被吃掉整個(gè)通信鏈路全亂了。這類問題幾乎都出在對(duì)FINS協(xié)議本身理解不透或者是在重復(fù)造輪子。如果你正在做上位機(jī)、MES對(duì)接或者設(shè)備數(shù)據(jù)采集一個(gè)封裝好的FINS動(dòng)態(tài)庫能幫你把鏈路管理、地址轉(zhuǎn)換、超時(shí)重試和數(shù)據(jù)解析全部收斂起來。這份資源值得花時(shí)間摸透下面直接講協(xié)議和實(shí)戰(zhàn)。2. 先看協(xié)議再動(dòng)手FINS幀結(jié)構(gòu)與動(dòng)態(tài)庫的選型邏輯2.1 FINS協(xié)議本質(zhì)命令/響應(yīng)幀的大端結(jié)構(gòu)FINS是歐姆龍PLC以太網(wǎng)通信的指令協(xié)議既有基于UDP的實(shí)現(xiàn)也有基于TCP的實(shí)現(xiàn)。絕大多數(shù)動(dòng)態(tài)庫都選擇FINS/TCP因?yàn)樗芴烊猾@得連接狀態(tài)感知鏈路斷了能立刻發(fā)現(xiàn)不用像UDP那樣靠超時(shí)去猜。端口固定為9600這是公開約定不是秘密但很多人不知道的是FINS/TCP并不是直接丟命令幀而是先建立一個(gè)TCP連接然后發(fā)送四個(gè)ASCII字符“FINS”再跟上本機(jī)節(jié)點(diǎn)地址做完這層握手之后才能發(fā)讀寫指令。這段握手過程會(huì)被封裝進(jìn)動(dòng)態(tài)庫所以從使用者角度看只需要調(diào)用一個(gè)Connect方法。FINS命令幀的結(jié)構(gòu)在動(dòng)態(tài)庫內(nèi)部是固定拼好的但理解它能幫你排錯(cuò)。一個(gè)典型幀由12字節(jié)的固定頭加數(shù)據(jù)域組成關(guān)鍵字段包括ICF、目標(biāo)網(wǎng)絡(luò)號(hào)DNA、目標(biāo)節(jié)點(diǎn)號(hào)DA1、目標(biāo)單元號(hào)DA2、源網(wǎng)絡(luò)號(hào)SNA、源節(jié)點(diǎn)號(hào)SA1、源單元號(hào)SA2、命令序號(hào)SID以及命令碼MRC/SRC。ICF為0x80表示請(qǐng)求響應(yīng)這個(gè)值一旦傳錯(cuò)PLC收到命令但不會(huì)回包現(xiàn)象就是超時(shí)。整幀使用大端字節(jié)序也就是高字節(jié)在前這跟多數(shù)常見的x86上位機(jī)習(xí)慣正好相反。還有一點(diǎn)命令碼是兩字節(jié)組合讀取DM區(qū)是0101寫入是0102別把這兩個(gè)值寫反。依賴動(dòng)態(tài)庫時(shí)最怕黑匣子所以我一般會(huì)選那種把SID和命令碼暴露出來的庫。SID是0到255的遞增循環(huán)值用于把命令和響應(yīng)配對(duì)。如果庫沒有暴露這個(gè)字段至少日志里要能看到。否則并發(fā)讀寫時(shí)響應(yīng)錯(cuò)位你根本不知道哪條命令對(duì)應(yīng)哪條響應(yīng)這種場(chǎng)景我見過不止一次。2.2 內(nèi)存區(qū)編號(hào)與地址換算DM、CIO、WR、HR歐姆龍PLC的內(nèi)存區(qū)在FINS協(xié)議里用不同的內(nèi)存區(qū)代碼區(qū)分。常見的有DM區(qū)對(duì)應(yīng)0x82CIO區(qū)字單位對(duì)應(yīng)0xB0CIO區(qū)位單位對(duì)應(yīng)0x31WR區(qū)對(duì)應(yīng)0xB1HR區(qū)對(duì)應(yīng)0xB2。新手最容易犯的錯(cuò)是把PLC程序里的“D100”直接當(dāng)成100號(hào)地址傳給庫。實(shí)際上D100在協(xié)議里是DM區(qū)地址100這個(gè)映射沒問題但很多人會(huì)把“W100”也當(dāng)成數(shù)字100傳進(jìn)去結(jié)果W100是CIO區(qū)的字地址和DM區(qū)完全是兩套編號(hào)。我在實(shí)際項(xiàng)目里見過一個(gè)案例某開發(fā)者想讀CIO區(qū)的第100個(gè)字直接從PLC程序里抄了輸出線圈號(hào)過來沒轉(zhuǎn)成CIO字地址讀出來全是0。原因很簡(jiǎn)單CIO區(qū)的地址范圍是0000到6143W0.00這種位地址要拆成字偏移和位偏移。動(dòng)態(tài)庫一般會(huì)提供兩種接口一種是直接按區(qū)讀寫需要你傳內(nèi)存區(qū)代碼另一種是針對(duì)DM區(qū)做了特化比如ReadDm方法內(nèi)部把內(nèi)存區(qū)代碼固定為0x82你只需要傳字偏移和數(shù)量。第二種接口用起來省心但也會(huì)把不懂得人擋在門外。地址換算是動(dòng)態(tài)庫的核心交付物。我建議你在拿到庫之后第一時(shí)間用PLC編程軟件建一個(gè)測(cè)試程序把幾個(gè)已知地址寫滿固定值然后用庫去讀看能不能原樣讀回來。這一步能同時(shí)驗(yàn)證三件事內(nèi)存區(qū)代碼是否正確、地址偏移是否計(jì)算準(zhǔn)確、字節(jié)序轉(zhuǎn)換是否到位。否則后面排查起來底層每個(gè)環(huán)節(jié)都像黑匣子很難定位問題。2.3 動(dòng)態(tài)庫封裝的邊界為什么不是直接發(fā)Socket有些人覺得FINS協(xié)議幀格式固定自己在C#或者Python里拼個(gè)Socket也就兩百行沒必要用動(dòng)態(tài)庫。這個(gè)判斷在只有一個(gè)PLC、讀一個(gè)地址、不要求重連的場(chǎng)景下成立但一旦進(jìn)入生產(chǎn)環(huán)境問題立刻變多上位機(jī)崩潰重啟后怎么恢復(fù)連接、PLC斷電后再上電怎么自動(dòng)重連、讀寫阻塞時(shí)怎么處理超時(shí)、多個(gè)線程同時(shí)讀寫怎么保證不串包。這些邏輯看起來簡(jiǎn)單實(shí)際寫起來全是細(xì)節(jié)。動(dòng)態(tài)庫的價(jià)值在于把狀態(tài)管理收攏。我見過直接Socket方案的翻車現(xiàn)場(chǎng)重啟上位機(jī)后端口處于TIME_WAIT狀態(tài)連不上PLC必須等兩分鐘才能恢復(fù)。動(dòng)態(tài)庫往往在底層設(shè)置了地址重用選項(xiàng)甚至實(shí)現(xiàn)了自動(dòng)重連隊(duì)列這些在裸Socket里都要自己造。另外FINS動(dòng)態(tài)庫通常還內(nèi)置了響應(yīng)校驗(yàn)收到響應(yīng)后檢查錯(cuò)誤碼非零就拋異常或者返回錯(cuò)誤號(hào)省去你逐幀比對(duì)。選型時(shí)我會(huì)看三個(gè)維度第一是否同時(shí)支持FINS/TCP和FINS/UDPUDP用在跨網(wǎng)段或PLC型號(hào)較老的場(chǎng)景第二是否允許自定義節(jié)點(diǎn)地址和單元號(hào)這決定它能不能適配多PLC組網(wǎng)第三是否暴露錯(cuò)誤碼和詳細(xì)日志沒有日志的庫在生產(chǎn)環(huán)境基本沒法用。滿足這三點(diǎn)再考慮易用性。3. 動(dòng)態(tài)庫實(shí)戰(zhàn)從連接到讀寫一個(gè)完整流程3.1 加載DLL與初始化連接參數(shù)拿到動(dòng)態(tài)庫后第一步是在你的項(xiàng)目中引用它。以最常見的C#上位機(jī)為例使用DllImport方式加載庫入口點(diǎn)對(duì)應(yīng)庫導(dǎo)出的函數(shù)。一個(gè)標(biāo)準(zhǔn)的初始化流程包括設(shè)置本機(jī)網(wǎng)絡(luò)號(hào)、本機(jī)節(jié)點(diǎn)地址、單元號(hào)以及目標(biāo)PLC的網(wǎng)絡(luò)號(hào)、節(jié)點(diǎn)地址、單元號(hào)最后傳IP和端口。下面這段代碼展示的是典型的FinsConnect調(diào)用[DllImport(FinsLib.dll, EntryPoint FinsConnect)] public static extern int FinsConnect( byte localNet, byte localNode, byte localUnit, byte remoteNet, byte remoteNode, byte remoteUnit, string ipAddress, int port); // 調(diào)用示例 int handle FinsConnect(0, 1, 0, 0, 10, 0, 192.168.1.10, 9600); if (handle 0) { Console.WriteLine($連接失敗錯(cuò)誤碼{handle}); }這段代碼里返回值handle是庫內(nèi)部維護(hù)的連接句柄。后續(xù)所有讀寫操作都要帶上這個(gè)句柄它代表一條邏輯鏈路。網(wǎng)絡(luò)號(hào)和節(jié)點(diǎn)地址不是隨便填的本機(jī)節(jié)點(diǎn)地址要跟以太網(wǎng)模塊上配置的保持一致目標(biāo)節(jié)點(diǎn)地址對(duì)應(yīng)PLC的FINS節(jié)點(diǎn)號(hào)不是IP地址。單元號(hào)通常填0表示CPU單元如果是通信模塊或者特殊單元需要查對(duì)應(yīng)的單元號(hào)。端口9600是FINS/TCP的默認(rèn)值除非PLC端改過否則不要?jiǎng)?。連接失敗時(shí)的錯(cuò)誤碼每個(gè)庫定義不同但一般負(fù)值代表系統(tǒng)級(jí)錯(cuò)誤正數(shù)代表PLC返回的應(yīng)用錯(cuò)誤。我習(xí)慣在封裝層把錯(cuò)誤碼轉(zhuǎn)成中文提示方便現(xiàn)場(chǎng)排查。初始化成功之后庫內(nèi)部已經(jīng)完成了FINS握手而不只是建立了TCP連接。3.2 讀DM區(qū)數(shù)據(jù)并解析命令幀與響應(yīng)幀讀取DM區(qū)數(shù)據(jù)是最高頻的操作。庫通常提供兩種粒度讀單個(gè)字、讀連續(xù)多個(gè)字。連續(xù)讀取的效率遠(yuǎn)高于循環(huán)讀單個(gè)地址因?yàn)橐粋€(gè)命令幀就能把一整段地址帶回來?？聪旅孢@個(gè)示例讀取從DM100開始的10個(gè)通道byte[] buffer new byte[10 * 2]; int ret FinsReadDm(handle, 100, 10, buffer, buffer.Length); if (ret 0) { for (int i 0; i 10; i) { ushort value (ushort)((buffer[i * 2] 8) | buffer[i * 2 1]); Console.WriteLine($DM[{100 i}] {value}); } }FinsReadDm的參數(shù)依次是連接句柄、起始DM地址、要讀取的字?jǐn)?shù)、存放數(shù)據(jù)的字節(jié)數(shù)組、數(shù)組長度。注意buffer的長度是字?jǐn)?shù)乘以2因?yàn)槊總€(gè)通道占兩個(gè)字節(jié)。返回值0表示成功非零表示失敗。數(shù)據(jù)解析這里做了手工大端轉(zhuǎn)換buffer[偶數(shù)位]是高字節(jié)左移8位后和低字節(jié)按位或。這里最容易踩的坑是字節(jié)序。如果你的上位機(jī)是x86平臺(tái)直接用BitConverter.ToUInt16取出來的值往往是反的因?yàn)锽itConverter在本機(jī)上是小端解析。我一般不用BitConverter而是手動(dòng)移位或調(diào)用庫自帶的ConvertToUInt16方法。有些庫返回的事先轉(zhuǎn)換好的int數(shù)組那就沒有這個(gè)問題。讀取數(shù)量方面FINS協(xié)議一次能讀的字?jǐn)?shù)上限在不同PLC型號(hào)上有差異常見上限是96字節(jié)也就是48個(gè)字。如果庫沒有自動(dòng)分包你要自己把大跨度讀取拆成多段避免超限報(bào)錯(cuò)。3.3 寫入控制字和批量讀寫進(jìn)階寫入操作和讀取對(duì)稱命令碼換成0102數(shù)據(jù)域里帶上要寫入的內(nèi)容。寫入單個(gè)字時(shí)要先把ushort拆成高字節(jié)和低字節(jié)再組裝進(jìn)命令幀。批量寫入更實(shí)用例如一次寫入一組配方參數(shù)?？聪旅娴恼{(diào)用把三個(gè)連續(xù)DM地址寫入指定值ushort[] values new ushort[] { 100, 200, 300 }; byte[] payload new byte[values.Length * 2]; for (int i 0; i values.Length; i) { payload[i * 2] (byte)(values[i] 8); // 高字節(jié) payload[i * 2 1] (byte)(values[i] 0xFF); // 低字節(jié) } int ret FinsWriteDm(handle, 50, values.Length, payload, payload.Length); if (ret 0) { Console.WriteLine(寫入成功); }寫入前建議先確認(rèn)對(duì)應(yīng)DM地址在PLC程序里沒有被其他指令作為只讀區(qū)使用。有些PLC程序在掃描周期內(nèi)會(huì)重寫DM區(qū)上位機(jī)寫完立刻被PLC程序覆蓋看起來就像寫入沒生效這不是通信問題而是邏輯問題。我在現(xiàn)場(chǎng)碰到過好幾次最后都是查看PLC梯形圖才找到原因。批量寫還有一個(gè)值得注意的點(diǎn)就是數(shù)據(jù)一致性。如果配方有多個(gè)字節(jié)PLC可能在某次掃描周期讀取時(shí)看到一半新值一半舊值。規(guī)避方法是先把數(shù)據(jù)寫到一個(gè)臨時(shí)DM區(qū)全部寫完后再用一個(gè)專門的控制位觸發(fā)PLC內(nèi)部數(shù)據(jù)搬移。這個(gè)控制位本身也通過FINS指令寫入。動(dòng)態(tài)庫解決不了業(yè)務(wù)一致性問題但作為使用者你必須有這個(gè)意識(shí)。3.4 斷開連接與異常處理程序退出或者PLC斷電時(shí)需要主動(dòng)斷開連接釋放庫內(nèi)部占用的資源。斷開接口一般叫FinsDisconnect傳入句柄即可。如果庫支持自動(dòng)重連斷開后再次調(diào)用Connect即可但要注意重連前確認(rèn)舊句柄已被釋放否則可能出現(xiàn)句柄泄漏。FinsDisconnect(handle); handle 0;異常處理方面動(dòng)態(tài)庫的錯(cuò)誤碼通常分為幾類超時(shí)、連接重置、PLC返回錯(cuò)誤、參數(shù)非法。超時(shí)是最難排查的因?yàn)樗赡苁蔷W(wǎng)絡(luò)問題也可能是節(jié)點(diǎn)地址配錯(cuò)導(dǎo)致的“沒人理”。連接重置多半是PLC重啟或者網(wǎng)線斷開。參數(shù)非法則要檢查內(nèi)存區(qū)代碼和地址是否在允許范圍內(nèi)。我在設(shè)計(jì)封裝層時(shí)會(huì)把錯(cuò)誤碼轉(zhuǎn)成自定義異常并在異常消息里帶上上下文比如操作類型、目標(biāo)地址、IP、時(shí)間戳這樣日志里能直接定位那一刻發(fā)生了什么。4. 避坑FINS動(dòng)態(tài)庫常見的五個(gè)翻車點(diǎn)4.1 連接超時(shí)網(wǎng)絡(luò)號(hào)和節(jié)點(diǎn)地址要對(duì)齊現(xiàn)象FinsConnect或第一次Read時(shí)一直等到超時(shí)返回錯(cuò)誤碼是超時(shí)類錯(cuò)誤ping PLC的IP能通。原因FINS節(jié)點(diǎn)地址和網(wǎng)絡(luò)號(hào)不匹配PLC收到了幀但發(fā)現(xiàn)目標(biāo)節(jié)點(diǎn)不是自己直接丟棄。解決從PLC側(cè)面或編程軟件里讀出正確的節(jié)點(diǎn)號(hào)確認(rèn)它是1還是10還是別的值。另外本機(jī)節(jié)點(diǎn)地址也不要設(shè)置成0很多動(dòng)態(tài)庫把0當(dāng)作無效值連接前檢查一下。還有個(gè)小坑有些PLC上電后節(jié)點(diǎn)號(hào)會(huì)變動(dòng)比如程序下載后再上電FINS節(jié)點(diǎn)地址恢復(fù)成默認(rèn)值。我在一個(gè)項(xiàng)目里遇到夜晚PLC自動(dòng)復(fù)位第二天通信失敗的情況就是因?yàn)槌绦蚶镉簿幋a了舊的節(jié)點(diǎn)號(hào)。從那以后我把節(jié)點(diǎn)地址設(shè)計(jì)成可配置項(xiàng)存到配置文件中而不是寫死在代碼里。4.2 字節(jié)序翻車大端與小端的血淚經(jīng)驗(yàn)現(xiàn)象讀取到DM區(qū)數(shù)值看起來像是“顛倒了”比如PLC里寫0x1234上位機(jī)讀出來0x3412。原因FINS協(xié)議使用大端字節(jié)序而多數(shù)x86平臺(tái)默認(rèn)小端直接用BitConverter轉(zhuǎn)換就會(huì)得到反序。解決手動(dòng)用移位拼接高低字節(jié)或者調(diào)用庫提供的轉(zhuǎn)換方法。不要依賴BitConverter也不要試圖自己改PLC端的數(shù)據(jù)排列FINS協(xié)議的字節(jié)序改不了。這個(gè)坑還有一個(gè)變種在寫入時(shí)忘記把ushort拆成高字節(jié)在前結(jié)果寫進(jìn)去的值變成亂碼。批量寫入時(shí)尤其容易犯因?yàn)檠h(huán)里逐個(gè)拼字節(jié)稍不留神就把高低字節(jié)放反。我建議在封裝層寫一個(gè)統(tǒng)一的DataConverter類提供ushortToBytes、bytesToUshort、intToBytes等方法所有讀寫都走這一層避免在不同項(xiàng)目里復(fù)制粘貼邏輯造成不一致。4.3 端口TIME_WAIT導(dǎo)致重連失敗現(xiàn)象程序第一次連接正常退出后再啟動(dòng)就連接不上要等一兩分鐘才行。原因TCP關(guān)閉后端口進(jìn)入TIME_WAIT狀態(tài)默認(rèn)等待約兩分鐘而FINS/TCP固定使用9600端口裸Socket不設(shè)置地址重用就會(huì)撞上。解決動(dòng)態(tài)庫內(nèi)部如果實(shí)現(xiàn)了SO_REUSEADDR通常能繞過這個(gè)問題如果繞不過檢查連接前是否先釋放舊句柄或者在系統(tǒng)層面調(diào)整TCP回收時(shí)間。生產(chǎn)環(huán)境最好做成優(yōu)雅退出不要直接殺掉進(jìn)程。4.4 讀取頻率過高把PLC拖成慢響應(yīng)現(xiàn)象上位機(jī)一個(gè)循環(huán)100ms里面讀30個(gè)地址塊PLC的程序掃描周期變大甚至出現(xiàn)看門狗報(bào)警。原因FINS讀寫指令會(huì)占用PLC通信處理資源頻繁小包讀取會(huì)讓通信任務(wù)高負(fù)荷運(yùn)行。解決把多個(gè)不連續(xù)地址合并成連續(xù)段讀取減少命令數(shù)量或者把讀取周期從100ms拉長到300ms?，F(xiàn)實(shí)中大部分DM區(qū)數(shù)據(jù)變化不會(huì)那么快100ms輪詢只是心理安慰。我在某項(xiàng)目里試過用100ms輪詢讀96個(gè)地址發(fā)現(xiàn)PLC掃描周期從10ms惡化到25ms最終改成500ms批量讀取加數(shù)據(jù)變化檢測(cè)掃描周期回到10ms以內(nèi)。動(dòng)態(tài)庫本身不會(huì)限制頻率但使用者要了解現(xiàn)場(chǎng)PLC的負(fù)載能力。4.5 調(diào)試工具與動(dòng)態(tài)庫搶端口現(xiàn)象開了歐姆龍自帶的通信測(cè)試工具再跑你的程序就連接失敗。原因這些工具也使用FINS/TCP 9600端口要么搶占了端口要么因?yàn)楸緳C(jī)節(jié)點(diǎn)地址沖突導(dǎo)致PLC不響應(yīng)。解決調(diào)試時(shí)不要同時(shí)打開兩套連接或者讓PLC端改用FINS/UDP方式通信UDP沒有固定端口占用問題。還有一種做法是給本機(jī)網(wǎng)卡配置多個(gè)IP不同工具綁定不同IP源頭避讓。5. 進(jìn)階用法把庫用得更穩(wěn)的四個(gè)小技巧5.1 用隊(duì)列把讀寫請(qǐng)求串行化動(dòng)態(tài)庫雖然內(nèi)部可能支持多線程但實(shí)際PLC側(cè)并不喜歡同時(shí)收到多個(gè)命令幀。我在封裝層會(huì)再加一層隊(duì)列所有讀寫請(qǐng)求排入隊(duì)列由一個(gè)后臺(tái)線程依次處理。這樣做還能天然實(shí)現(xiàn)請(qǐng)求超時(shí)管理如果某次請(qǐng)求超過500ms沒有響應(yīng)就跳過它并記錄日志而不是把它變成阻塞調(diào)用拖慢整個(gè)主線程。5.2 用錯(cuò)誤碼做細(xì)粒度診斷不要只打印“通信失敗”。把庫返回的錯(cuò)誤碼查表翻譯成可讀信息再附加當(dāng)前操作類型和地址范圍?，F(xiàn)場(chǎng)排查時(shí)日志里出現(xiàn)“寫入DM100-119失敗錯(cuò)誤碼33數(shù)據(jù)超過范圍”這種信息比“寫入失敗”四個(gè)字有用得多。我習(xí)慣把日志分為連接級(jí)、命令級(jí)和錯(cuò)誤級(jí)三級(jí)平時(shí)只輸出錯(cuò)誤級(jí)排查時(shí)打開詳細(xì)日志。5.3 數(shù)據(jù)變化時(shí)再上報(bào)輪詢改訂閱如果上位機(jī)只關(guān)心特定幾個(gè)變化的值可以在庫之上做一層“讀取快照對(duì)比”。每一輪讀取結(jié)束后把數(shù)據(jù)與上次快照比對(duì)發(fā)生變化才觸發(fā)后續(xù)處理。這樣既保持了讀取邏輯簡(jiǎn)單又避免了每輪都把數(shù)據(jù)噴到上層。本質(zhì)上是把通信頻率降下來效果卻等同于高頻監(jiān)測(cè)。5.4 從一次故障中學(xué)到的事一次現(xiàn)場(chǎng)調(diào)試某設(shè)備總是運(yùn)行十幾分鐘后通信中斷查到最后發(fā)現(xiàn)是PLC程序里某個(gè)功能塊把FINS節(jié)點(diǎn)地址給改寫了。從那時(shí)候起我每次對(duì)接新設(shè)備都強(qiáng)制走一遍流程先單獨(dú)驗(yàn)證一個(gè)已知地址的讀寫再上批量操作每次修改PLC程序后重新核對(duì)節(jié)點(diǎn)地址任何連接參數(shù)都做成配置文件而不是硬編碼。這套習(xí)慣讓后續(xù)項(xiàng)目省了不少冤枉路。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取