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