搞工業(yè)自動化的朋友一定都有這種經歷現(xiàn)場立著一臺西門子觸摸屏屏幕上實時刷著溫度、壓力、產量這些關鍵參數(shù)但旁邊那臺辦公電腦上卻沒有博途只有Python環(huán)境。想把屏幕上的數(shù)據(jù)接出來做報表、做預警、做歷史曲線第一個念頭就是直接用程序去“讀觸摸屏”。但這兒的門道比想象中要多不少尤其是數(shù)據(jù)類型里最常見的Dint32位整型和LReal64位雙精度浮點。這兩個數(shù)據(jù)類型的解析方式和普通整數(shù)、單精度浮點數(shù)完全不是一個路子我之前第一次上手時就因為字節(jié)序和地址偏移這兩個問題卡了整整一個下午。先說結論用Python Snap7讀西門子觸摸屏背后的數(shù)據(jù)是完全可以的但真正讀的不是觸摸屏本身而是觸摸屏所綁定的PLC。Snap7作為一個開源的S7通信庫通過以太網直接和PLC對話把DB塊里的數(shù)據(jù)拿到手而我們看到的觸摸屏畫面本質上是PLC數(shù)據(jù)塊的“鏡像”。這篇文章我結合自己的實戰(zhàn)經歷把從環(huán)境搭建、連接配置、Dint與LReal的讀取代碼、地址偏移計算、字節(jié)序轉換到各種常見坑完整梳理一遍。不管是設備維護人員、MES對接工程師還是剛接觸工控的Python開發(fā)者照著這套流程都能把數(shù)據(jù)跑起來。1. 先把問題看清楚讀的到底是什么1.1 觸摸屏上的數(shù)據(jù)實際存放在哪里很多剛從IT轉過來接觸工業(yè)現(xiàn)場的程序員第一反應是“觸摸屏里應該有數(shù)據(jù)”。這個想法可以理解但和西門子的實際架構是有出入的。在標準的西門子自動化系統(tǒng)中觸摸屏HMI面板和PLC是兩臺獨立設備觸摸屏的角色是人機交互界面PLC的角色是邏輯運算和數(shù)據(jù)存儲。屏幕上顯示的那個流量計數(shù)值本質是PLC某個DB塊里的變量——HMI通過組態(tài)軟件把這個變量的地址映射到畫面上的一個文本顯示控件。所以數(shù)據(jù)真正的“老家”是PLC的內存區(qū)觸摸屏只是臨時把數(shù)據(jù)展示出來。這就引出一個關鍵結論Snap7連接的目標不是觸摸屏的IP而是PLC的IP。我在一個設備改造項目里最開始就試圖用觸摸屏的IP去連接結果一直超時后來翻看了觸摸屏的組態(tài)工程——畫面變量列表里每個變量都標注了PLC的DB號和偏移地址這才明白過來。因此在做任何采集程序之前最值得做的事是找到觸摸屏組態(tài)里的“變量列表”或者“連接設置”把每個畫面變量背后的PLC數(shù)據(jù)區(qū)信息理清楚。這步做扎實了后面寫代碼就是純粹的體力活。也有個別例外情況比如部分新款HMI面板支持數(shù)據(jù)記錄功能可以把歷史數(shù)據(jù)寫到自身存儲介質里比如配方數(shù)據(jù)、報警記錄。這類數(shù)據(jù)確實存在觸摸屏上但Snap7走的是S7通信協(xié)議核心交互對象是PLC的存儲區(qū)觸摸屏自己的記錄數(shù)據(jù)一般需要走文件導出或者OPC UA通道。因此本文的核心場景仍然是觸摸屏所綁定的PLC實時數(shù)據(jù)。1.2 Dint和LReal到底是什么數(shù)據(jù)類型Dint這個寫法初次接觸會覺得有點陌生。它是Double Integer的縮寫代表32位有符號整數(shù)取值范圍從-2147483648到2147483647。相比西門子PLC里常見的INT16位整數(shù)范圍-32768到32767Dint能表達的數(shù)字范圍大得多。為什么觸摸屏上經常用Dint典型的例子是累計產量。一個計數(shù)器如果長期累加很快就能突破32767的上限用INT必然溢出用Dint則可以跑到21億多對絕大多數(shù)產線來說足夠了。LReal則是Long Real的縮寫是64位雙精度浮點數(shù)對應到C語言里的double也對應到Python里的float——因為Python的float本身就是雙精度。很多傳感器比如稱重、流量、溫度變送器的測量值要求很高精度如果用32位REAL單精度浮點數(shù)有效數(shù)字只有7位大數(shù)加小數(shù)時精度損失很嚴重。舉個例子一個讀數(shù)在100000.123456附近的重力傳感器REAL類型可能只能讀成100000.13而LReal類型能精確保留到小數(shù)點后六位以上。這就是LReal存在的意義。準確理解這兩個類型不僅是類型轉換的問題更直接關系到通信時的字節(jié)長度。Dint在S7協(xié)議中占用4個字節(jié)LReal占用8個字節(jié)。這個“4字節(jié)”和“8字節(jié)”是所有地址偏移計算的基礎——DB塊里一個Dint變量后面緊跟著另一個變量時第二個變量的起始偏移量至少要在前一個變量的基礎上加4如果中間還有LReal變量則要加8。后面關于地址偏移的討論全部建立在這兩個字節(jié)長度上。2. 環(huán)境準備Snap7安裝與PLC通信配置2.1 安裝Python Snap7庫并驗證底層驅動Snap7是一個開源的S7以太網通信庫原生語言是C官方提供了Python綁定python-snap7。安裝方式走標準的pip流程。pip install python-snap7這個包在安裝時會自動攜帶對應平臺的本地動態(tài)庫文件Windows下是snap7.dllLinux下是libsnap7.so所以一般情況下裝完就能直接用。我個人的建議是裝完后立即跑一段最簡測試確認底層驅動真的可用免得后面寫了一大堆代碼才發(fā)現(xiàn)環(huán)境有問題。import snap7 client snap7.client.Client() client.create() print(Snap7 client created successfully) client.destroy()如果導入snap7模塊時報錯比如提示找不到動態(tài)庫直接去Snap7官方GitHub的Release頁面手動下載對應操作系統(tǒng)的庫文件放到系統(tǒng)搜索路徑里即可。這種情況在Windows精簡環(huán)境下出現(xiàn)過幾次安裝Visual C運行庫后基本能解決。2.2 開啟PLC的PUT/GET通信授權這一步極其關鍵而且踩坑率極高。S7-1200和S7-1500系列PLC在默認安全設置下是禁止外部設備通過以太網直接讀寫數(shù)據(jù)塊的。如果你的Snap7程序出現(xiàn)“連接成功但讀取超時”或“完全連不上”這類現(xiàn)象十有八九是PLC的通信權限沒有打開。需要做的操作是在博途TIA Portal里打開PLC的設備組態(tài)進入“屬性 - 保護與安全 - 連接機制”勾選“允許來自遠程對象的PUT/GET通信訪問”。不同版本的博途菜單名稱略有差異有些版本顯示為“Permit access with PUT/GET communication”但位置基本都在保護與安全相關配置里。S7-300和S7-400老款PLC默認允許遠程通信但也要檢查CPU屬性里的保護級別。如果保護級別設置為“完全保護”外部訪問同樣會被拒絕。另外某些老版本固件的S7-300需要在組態(tài)軟件里明確勾選“允許外部讀寫”否則Snap7只能讀不能寫。值得注意的是修改PLC通信權限之后需要重新編譯并下載硬件配置必要時還要做一次停機重啟。這涉及設備停機時間現(xiàn)場操作時一定要提前和相關人員溝通確認。2.3 確認Rack機架號和Slot槽號Snap7的connect方法有三個關鍵參數(shù)IP地址、機架號、槽號。client snap7.client.Client() client.connect(192.168.0.1, 0, 1)這三個參數(shù)一個都不能錯。對于S7-300系列常見的配置是機架0、槽號2對于S7-1200和S7-1500系列常見的配置是機架0、槽號1。但這個不是絕對的比如某些緊湊型CPU或者第三方機架槽號可能有差異。最穩(wěn)妥的方式是打開博途的設備組態(tài)在左側設備樹中查看CPU的實際機架和槽位。如果手頭沒有博途也可以嘗試幾個常見組合連接成功的那個組合大概率就是對的。判斷Rack和Slot是否正確的標志是connect方法不報錯而且后續(xù)的db_read有正常返回。如果connect直接拋異常先別懷疑網絡優(yōu)先檢查IP、Rack、Slot這三項。3. 核心代碼用Snap7讀取Dint和LReal數(shù)據(jù)3.1 基礎連接與DB讀取框架確認通信環(huán)境沒問題后就可以正式寫采集代碼了。先來看最基礎的連接和讀取框架。import snap7 from snap7.util import get_dint, get_lreal def connect_plc(ip, rack0, slot1): client snap7.client.Client() client.connect(ip, rack, slot) return client client connect_plc(192.168.0.10) # 讀取DB號、起始偏移、字節(jié)長度 data client.db_read(db_number1, start0, size4) print(data.hex())db_read是Snap7讀取數(shù)據(jù)塊的核心方法參數(shù)分別是DB塊編號、起始偏移地址、要讀取的字節(jié)長度。返回的是一個字節(jié)數(shù)組也就是PLC原始數(shù)據(jù)的“底片”。我們所有的數(shù)據(jù)類型解析都是在拿到這個字節(jié)數(shù)組之后進行的。我習慣先把原始字節(jié)打印成十六進制用肉眼核對一遍再寫解析邏輯。這樣能第一時間發(fā)現(xiàn)地址對不對、長度夠不夠也能直觀感受大端字節(jié)序。比如PLC里存了一個整數(shù)10實際讀出來的字節(jié)可能是00 00 00 0A而不是0A 00 00 00這就是大端和小端的區(qū)別后面細說。3.2 讀取Dint數(shù)據(jù)的兩種方式拿到原始字節(jié)后解析Dint有現(xiàn)成的工具函數(shù)也可以自己用struct手動解析。先看最直接的方式。# 方式一使用snap7.util自帶的get_dint data client.db_read(db_number1, start0, size4) dint_value get_dint(data, 0) print(fDint value at DB1.DBD0: {dint_value})get_dint接收兩個參數(shù)第一個是字節(jié)數(shù)組第二個是在數(shù)組內部的起始偏移注意這個偏移是數(shù)組內偏移不是PLC的DB地址偏移。它會自動按照西門子的大端規(guī)則把4個字節(jié)解析成32位有符號整數(shù)。再來看自己手動解析的方式。# 方式二使用struct手動解析 import struct data client.db_read(db_number1, start0, size4) dint_value struct.unpack(i, data[:4])[0] print(fDint value: {dint_value})這里的i就是大端Big-Endian有符號32位整數(shù)。是字節(jié)序標記i是C語言int的對應格式。為什么必須加因為西門子PLC的S7協(xié)議在網絡傳輸時使用的是大端字節(jié)序高字節(jié)在前、低字節(jié)在后而x86架構的電腦默認是小端低字節(jié)在前。所以如果寫成i不加結構是以小端解析同一個4字節(jié)數(shù)據(jù)解析出來的整數(shù)就完全不對。get_dint內部做的就是這件加的事所以推薦直接用工具函數(shù)。一個小技巧測試階段可以用已知值驗證。比如手動在博途里給某個Dint變量寫入12345然后運行程序看讀出來的值是不是12345。如果是說明地址和字節(jié)序都對了如果不是先別改解析代碼回頭檢查地址偏移。3.3 讀取LReal數(shù)據(jù)的完整示例LReal占8個字節(jié)讀取流程和Dint類似但解析時的格式和工具函數(shù)不同。# 使用snap7.util自帶的get_lreal data client.db_read(db_number1, start0, size8) lreal_value get_lreal(data, 0) print(fLReal value: {lreal_value})手動解析的寫法import struct data client.db_read(db_number1, start0, size8) lreal_value struct.unpack(d, data[:8])[0] print(fLReal value: {lreal_value})d對應大端雙精度浮點數(shù)占8個字節(jié)。Python的float就是雙精度所以解析出來的值可以直接參與后續(xù)的數(shù)學運算、入庫、展示。這里要提醒一個容易犯的錯LReal是8字節(jié)REAL是4字節(jié)。在DB塊里它們對應的符號名分別是“LReal”和“Real”如果你的變量表里寫的是REAL卻用get_lreal去讀讀出來的字節(jié)長度就不對數(shù)據(jù)會錯位。讀取時size參數(shù)必須和類型嚴格匹配Dint用4LReal用8REAL用4INT用2。3.4 連續(xù)讀取DB塊內的多個變量現(xiàn)場需求通常不是只讀一個變量。比如某個DB塊里偏移0處是一個Dint類型的累計數(shù)偏移4處是一個LReal類型的壓力值偏移12處是一個Dint類型的設備狀態(tài)。這時候最合理的做法是一次性讀取整段數(shù)據(jù)然后分別解析。# 一次性讀取DB1從偏移0開始的16個字節(jié) data client.db_read(db_number1, start0, size16) total_count get_dint(data, 0) # 偏移0讀4字節(jié) pressure get_lreal(data, 4) # 偏移4讀8字節(jié) device_status get_dint(data, 12) # 偏移12讀4字節(jié) print(total_count, pressure, device_status)為什么說這是一次“區(qū)塊讀取”因為從偏移0到偏移16正好覆蓋了這三個變量的全部字節(jié)4Dint 8LReal 4Dint 16。這種做法的優(yōu)勢是減少網絡交互次數(shù)只發(fā)一個請求、收一個響應就能拿到多個變量的數(shù)據(jù)。如果每個變量單獨db_read一次數(shù)據(jù)量小還能接受變量多起來網絡開銷會明顯增加現(xiàn)場通信負載高的情況下還可能丟包。地址偏移的計算一定要拿紙筆推演別在腦子里想象。我踩過一次很典型的坑一個DB塊偏移0是INT占2字節(jié)偏移2是Dint占4字節(jié)但我在讀Dint時想當然地用了偏移4結果把Dint的低兩位和下一個REAL的高兩位拼在一起讀出來的數(shù)值完全不可信。3.5 封裝一個通用讀取器把上面這些邏輯封裝成一個可復用的類是讓代碼真正落地的好辦法。下面是我在多個項目里用的一套結構。import snap7 from snap7.util import get_int, get_dint, get_real, get_lreal class S7DataReader: def __init__(self, ip, rack0, slot1): self.client snap7.client.Client() self.client.connect(ip, rack, slot) def read_dint(self, db_number, offset): data self.client.db_read(db_number, offset, 4) return get_dint(data, 0) def read_lreal(self, db_number, offset): data self.client.db_read(db_number, offset, 8) return get_lreal(data, 0) def read_int(self, db_number, offset): data self.client.db_read(db_number, offset, 2) return get_int(data, 0) def read_real(self, db_number, offset): data self.client.db_read(db_number, offset, 4) return get_real(data, 0) def read_segment(self, db_number, start, size): return self.client.db_read(db_number, start, size) def disconnect(self): self.client.disconnect() # 使用示例 reader S7DataReader(192.168.0.10) dint_val reader.read_dint(1, 0) lreal_val reader.read_lreal(1, 4) print(dint_val, lreal_val) reader.disconnect()這個類的好處是每個類型對應一個方法名字直觀調用方便。我在實際項目中還會在read_segment里加一個超時重試機制比如請求異常時自動重連一次來處理現(xiàn)場偶發(fā)的通信抖動。4. 實戰(zhàn)中的故障排查與避坑記錄4.1 連接失敗但IP能ping通這是出現(xiàn)頻率最高的問題。能ping通說明網絡鏈路是通的但Snap7連接失敗通常繞不開這三個原因第一Rack或Slot參數(shù)不對。我見過一個現(xiàn)場工程師為了省事把所有設備的Rack都填成0結果S7-300連得上S7-1500死活連不上因為后者的實際槽號不是1。解決方法是打開博途設備組態(tài)確認或者試錯幾個組合。第二PLC未開放PUT/GET通信權限。這個在S7-1200/1500上尤其常見。博途里有個默認勾選項是禁止外部讀寫很多人沒注意到導致Snap7連上了但一讀寫就超時。必須到“保護與安全 - 連接機制”里勾選允許外部訪問。第三防火墻攔截?，F(xiàn)場電腦若開啟Windows防火墻可能攔截Snap7使用的102端口需要在防火墻中放行。還有更隱蔽的情況PLC所在的工業(yè)網段與辦公網段做了VLAN隔離Snap7的請求根本到達不了PLC。這類問題要聯(lián)合網絡管理員排查而不是單純在代碼層面解決。4.2 讀出來的數(shù)值明顯不對怎么定位數(shù)值不對一般問題出在地址偏移或字節(jié)長度不匹配。我曾經遇到一個案例設備狀態(tài)字在觸摸屏上顯示正常但程序讀出來是負數(shù)。后來對照博途的變量表才發(fā)現(xiàn)那個變量在組態(tài)里定義的是INT程序卻用Dint去讀了。4字節(jié)的Dint讀取包含了這個INT變量的兩個字節(jié)又把下一段數(shù)據(jù)的字節(jié)也拼了進來自然就錯了。排查這個問題的標準動作是“對照變量表 十六進制打印”。先把db_read拿到的原始字節(jié)打印成hex然后和博途變量表里該變量的真實值做對比。比如在博途里給某個Dint寫入0x12345678協(xié)議層面讀出來應該就是12 34 56 78這樣的原始字節(jié)。如果看到的是78 56 34 12說明你用了小端解析如果完全不是這幾個字節(jié)說明地址都錯了壓根不是這個變量。4.3 字節(jié)序問題導致的數(shù)值反轉字節(jié)序錯誤的表現(xiàn)非常典型變量值是1程序讀出來可能是16777216也就是0x01000000被當成小端解析成了0x00000001不對應該是256的倍數(shù)之類的。具體來說如果我認定了4字節(jié)00 00 00 01用i解析得到1用i小端解析則得到16777216。有些新手會把這種值當成“數(shù)據(jù)錯亂”其實是解析端字節(jié)序問題。解決辦法很簡單統(tǒng)一使用snap7.util里的get_dint、get_lreal、get_real、get_int這些工具函數(shù)它們內部已經固定好大端解析規(guī)則。如果確實要用struct手動解析所有格式都必須加上前綴比如i、d、f、h。4.4 優(yōu)化DB塊讀不出數(shù)據(jù)這個問題很隱蔽代碼完全沒錯但讀取結果要么超時要么全零。調查后發(fā)現(xiàn)DB塊組態(tài)時啟用了“優(yōu)化的塊訪問”O(jiān)ptimized block access。在優(yōu)化模式下變量的地址不是簡單地從0開始順序排列而是由編譯器自動排布對外部通信而言等于“不可見”。Snap7這類工具訪問優(yōu)化DB時無法通過固定的偏移地址讀取任何有效內容。解決方式在博途里選中對應的DB塊在屬性中取消“優(yōu)化的塊訪問”選項保存編譯后重新下載到PLC。注意取消優(yōu)化后DB塊內變量的實際地址會發(fā)生重排那么所有依賴該DB塊的讀寫程序、HMI變量綁定都要跟著更新否則會出現(xiàn)張冠李戴。這個改動的影響面較大現(xiàn)場操作前建議先導出變量表備份。關于優(yōu)化DB和非優(yōu)化DB還有一個判斷方法在博途DB編輯器的“監(jiān)視”視圖中優(yōu)化DB的偏移列通常顯示為灰色或不顯示具體數(shù)字非優(yōu)化DB則有一個明確的OFFSET值序列。4.5 觸摸屏和PLC都連接成功但讀出的數(shù)據(jù)對不上號一個容易忽略的點現(xiàn)場可能有多臺PLC和多臺觸摸屏所有設備的IP都在同一個網段。如果程序里只改了觸摸屏IP卻沒注意觸摸屏綁定的PLC可能換了CPU或者有冗余切換就容易出現(xiàn)“程序讀到的是A車間數(shù)據(jù)你以為自己在讀B車間”的情況。這種問題在代碼層面無解必須在現(xiàn)場確認設備對應關系最簡單的方法是在博途的在線診斷里查看觸摸屏當前連接的實際PLC名稱和型號。5. 進階把數(shù)據(jù)解析流程做得更可靠5.1 用變量定義文件自動生成解析邏輯當項目的DB塊里有幾十個甚至上百個變量時手寫解析代碼的風險和成本都太高。我的做法是把變量表導出為結構化文件JSON或Excel然后在程序里自動生成解析邏輯。邏輯本身不復雜核心是“變量名 偏移 數(shù)據(jù)類型”這三個要素一一對應。下面是一個JSON配置的示例{ db_number: 1, variables: [ {name: total_count, offset: 0, type: DINT}, {name: pressure, offset: 4, type: LREAL}, {name: device_status, offset: 12, type: DINT}, {name: temperature, offset: 16, type: LREAL} ] }對應的解析器可以借助循環(huán)完成。import json import snap7 from snap7.util import get_dint, get_lreal, get_real, get_int def parse_config(config_path): with open(config_path, r, encodingutf-8) as f: cfg json.load(f) return cfg def read_variables_by_config(client, cfg): db cfg[db_number] start 0 # 最大偏移 類型長度 total_size max(v[offset] for v in cfg[variables]) total_size 8 block_data client.db_read(db_numberdb, start0, sizetotal_size) result {} parse_map { DINT: (get_dint, 4), LREAL: (get_lreal, 8), REAL: (get_real, 4), INT: (get_int, 2) } for v in cfg[variables]: func, size parse_map[v[type]] result[v[name]] func(block_data, v[offset]) return result這個方案后期擴展非常方便新增一個變量只需要改配置文件的對應行不必動代碼。而且配置文件可以和觸摸屏組態(tài)的變量表保持同步從源頭降低了地址錯位的概率。5.2 通信超時與異常斷線重連機制工業(yè)現(xiàn)場的以太網環(huán)境并不總是穩(wěn)定。電機的啟停、變頻器的干擾、交換機的端口協(xié)商都可能導致PLC和上位機之間的連接短暫中斷。如果程序不做任何容錯一次斷線就會讓采集進程崩潰或數(shù)據(jù)流中斷。我在封裝讀取器時習慣加一個自動重連機制。基本邏輯是捕獲Snap7的通信異常等待幾秒后重新連接重連成功后繼續(xù)執(zhí)行后續(xù)讀取操作。class RobustS7Reader(S7DataReader): def __init__(self, ip, rack0, slot1, max_retry3): super().__init__(ip, rack, slot) self.max_retry max_retry def read_with_retry(self, db_number, offset, read_func, size): for i in range(self.max_retry): try: data self.client.db_read(db_number, offset, size) return read_func(data, 0) except Exception as e: print(fRead failed, retry {i1}/{self.max_retry}: {e}) time.sleep(1) raise RuntimeError(Max retries exceeded)這里的關鍵是read_func這個參數(shù)它可以是get_dint、get_lreal等解析函數(shù)這樣這個方法就能被所有類型復用。實際使用時把read_dint和read_lreal改成調用read_with_retry即可。5.3 數(shù)據(jù)采集寫入數(shù)據(jù)庫的思路數(shù)據(jù)讀出來只是第一步大多數(shù)場景需要寫入數(shù)據(jù)庫或者推送MES。最簡單的做法是配合pandas和SQLAlchemy把每次采集到的數(shù)據(jù)轉成DataFrame按批次寫入。import pandas as pd from sqlalchemy import create_engine # 采集一批數(shù)據(jù) row {timestamp: datetime.now(), total_count: total_count, pressure: pressure} df pd.DataFrame([row]) df.to_sql(production_data, conengine, if_existsappend, indexFalse)如果是高頻數(shù)據(jù)比如每秒采集一次建議做成內存隊列批量落庫避免每條數(shù)據(jù)都開一次數(shù)據(jù)庫連接。如果現(xiàn)場已經有OPC UA網關Snap7的定位可以更靈活Snap7作為PLC數(shù)據(jù)采集層把數(shù)據(jù)推到MQTT或Redis再讓上層應用消費形成一套完整的工業(yè)數(shù)據(jù)鏈路。6. 最后補充幾句實操心法Snap7讀西門子數(shù)據(jù)的整體流程說到底就是三件事通信授權打開、地址算對、字節(jié)序解析對。這三件事都不難但每個環(huán)節(jié)都有隱藏的坑。從我個人經驗來看最容易出問題的不是代碼層面而是工程信息不透明——你拿不到準確的DB變量表或者拿到的是過期版本。所以在動手前我一定會先做兩件事一是拿到最新的PLC程序變量表二是用“讀4字節(jié)hex打印”的方式驗證一兩個已知變量。這兩步的投入只要十幾分鐘卻能把后面好幾個小時的排查時間省下來。另外如果是給長期運行的產線做采集不要忽略異常斷線重連和重復數(shù)據(jù)去重。工業(yè)現(xiàn)場設備重啟、固件升級、觸摸屏程序下載這些操作都可能讓PLC短暫離線采集程序如果扛不住這些小震動會產生數(shù)據(jù)空洞或重復記錄。給自己留一個簡單的手工驗證指令比如在命令行里跑一段單獨的讀取腳本檢查當前連通狀態(tài)排查問題時特別管用。這套方案目前在我的多個項目里穩(wěn)定運行覆蓋了S7-1200、S7-1500和部分S7-300設備。如果你正準備用Python對接西門子觸摸屏背后的數(shù)據(jù)照著上面的步驟一步步來先跑通一個Dint變量再擴展到LReal最后做成通用采集器整個流程會非常順。遇到問題也歡迎對照本文的排查清單逐項核對大部分疑難雜癥都能定位到明確原因。