去年給一套潔凈車間的空調(diào)電控柜做升級甲方需求提得很直白控制柜內(nèi)的溫度要看得到送風(fēng)管道末端、室內(nèi)回風(fēng)口、樓頂室外機的溫度也要同時匯總到主控屏上。說白了就是“本地溫度”和“遠程溫度”都要進同一套監(jiān)控系統(tǒng)。最開始團隊想沿用老辦法用NTC熱敏電阻加ADC采樣現(xiàn)場一勘探就放棄了——測點分散最近的就在柜內(nèi)最遠的在管路上走線超過40米模擬量信號在工業(yè)現(xiàn)場被變頻器干擾得沒法信。后來整案換成了PJ85718DM數(shù)字溫度傳感器搭配STM32F205RB做主控用一條單總線把本地和遠端的測點串起來問題才真正解決。這篇把項目里的選型邏輯、硬件接線、驅(qū)動實現(xiàn)、校準(zhǔn)方法以及排查過程完整復(fù)盤一遍給做嵌入式測溫、HVAC控制器或者設(shè)備狀態(tài)監(jiān)測的朋友當(dāng)個參考。1. HVAC里的“本地溫度”和“遠程溫度”不是兩套系統(tǒng)而是一個測點網(wǎng)絡(luò)1.1 項目需求拆解四個必須同時滿足的測點很多人第一次聽到“本地溫度和遠程溫度”會覺得是主控板上有兩套測溫邏輯一套測自己身邊一套測遠端。實際做HVAC項目時間長了就會發(fā)現(xiàn)絕大多數(shù)情況下這是同一個測點網(wǎng)絡(luò)里的兩類位置區(qū)別只在于物理距離和信號傳輸方式。我們這個項目一共規(guī)劃了四個測點組本地測點A電控柜內(nèi)部溫度緊挨著變頻器和主控板安裝用于控制柜內(nèi)散熱風(fēng)扇啟停溫度超過設(shè)定值要觸發(fā)聲光報警。遠程測點B送風(fēng)管道末端溫度距離主控柜約25米用于電加熱器和表冷器的輸出調(diào)節(jié)屬于PID控制回路的主反饋。遠程測點C室內(nèi)回風(fēng)口附近溫度距離主控柜約15米主要作為舒適度參考。遠程測點D樓頂室外機進風(fēng)溫度走線距離接近40米用于新風(fēng)補償和冬季低溫保護。四個測點的精度需求還不一樣。柜內(nèi)測點允許±1℃誤差管道和回風(fēng)測點因為參與控制希望誤差控制在±0.5℃以內(nèi)室外測點則要長期在-20℃到60℃的范圍內(nèi)工作還得防潮、防曬。采集周期也有差異PID反饋用的測點要1秒左右刷新一次柜內(nèi)報警測點2~3秒刷一次就夠。這四個需求疊在一起基本就把方案形態(tài)定死了必須是多點數(shù)字溫度采集而且通信方式要能容忍幾十米距離。單點模擬方案在這個場景里幾乎沒有勝算。1.2 為什么不用NTC和PT100而選了PJ85718DM選型階段我們把常用測溫方案列了一圈從NTC熱敏電阻、PT100鉑電阻到各種數(shù)字溫度傳感器都過了一遍。方案優(yōu)點在項目中的致命問題NTC ADC便宜、電路簡單、響應(yīng)快每路都要一個ADC通道4個測點就得額外擴展模擬量模塊長線傳輸受干擾明顯一致性差需要逐點校準(zhǔn)PT100 變送器精度高、線性好、抗干擾能力強成本高單個測點光變送器就不少錢接線復(fù)雜三線制/四線制很講究PJ85718DM單總線數(shù)字傳感器數(shù)字輸出、單IO口可掛多點、自帶CRC校驗、多點組網(wǎng)以地址區(qū)分單總線時序要求嚴格驅(qū)動層要自己寫選擇PJ85718DM的核心邏輯很直接四個測點分配到兩條總線上本地柜內(nèi)測點掛一條遠程三個測點串一條主控側(cè)只需要兩個GPIO口就能把全部溫度收回來。數(shù)字信號在40米線上傳輸抗干擾能力天然優(yōu)于模擬毫伏信號尤其是在變頻器、接觸器密集的工業(yè)電控柜環(huán)境里這個優(yōu)勢比什么高精度都更值錢。另外補充一點PJ85718DM在項目里用的是單總線工作模式每個傳感器都有唯一64位ROM識別碼。這意味著后續(xù)如果甲方要擴到十幾個測點不需要改主控板只需要往總線上并接新的探頭軟件里做一次搜索識別就行。1.3 STM32F205RB在這個項目里的角色選STM32F205RB當(dāng)主控不是因為它是最新最猛的芯片而是因為F205這顆料在工業(yè)控制器里屬于“穩(wěn)得一批”的存在。Cortex-M3內(nèi)核120MHz主頻128KB Flash加128KB SRAM外設(shè)接口數(shù)量在這個場景下嚴重富余。具體到功能分配兩路USART一路走RS485做Modbus RTU從站把溫度數(shù)據(jù)送給觸摸屏和上位機組態(tài)軟件另一路預(yù)留接串口透傳模塊用于將來往服務(wù)器上發(fā)數(shù)據(jù)。兩個GPIO口分別接兩條單總線。再配合幾個定時器做PWM輸出控制散熱風(fēng)扇轉(zhuǎn)速剩余IO口接按鍵和指示燈。128KB SRAM在一開始看起來有點浪費但實際開發(fā)中幫了大忙。溫度數(shù)據(jù)緩存、Modbus報文緩沖、透傳模塊AT指令響應(yīng)的環(huán)形隊列、顯示刷新用的顯存全部堆在內(nèi)存里完全沒有摳內(nèi)存的焦慮。FreeRTOS也輕松跑起來任務(wù)棧想給多大給多大整個項目寫完RAM占用率還不到一半。嵌入式和HVAC這兩個領(lǐng)域?qū)刂破鞯墓餐笫黔h(huán)境溫度范圍寬、電磁干擾大、生命周期長。STM32F205RB的工業(yè)級溫度和成熟外設(shè)庫剛好把這三件事都兜住了。2. 單總線驅(qū)動的核心細節(jié)PJ85718DM的時序、尋址與CRC校驗2.1 讀溫度前先把復(fù)位和讀寫時序搞清楚單總線這個東西名字聽起來就是“一根線傳數(shù)據(jù)”實際用起來最大的門檻不是協(xié)議概念而是微秒級的時序要求。它屬于半雙工、開漏輸出的通信方式主機和設(shè)備通過拉低、釋放總線來產(chǎn)生通信時隙因此外部必須有一個上拉電阻把總線默認電平拉到高。我們項目里用HAL庫做GPIO模擬核心函數(shù)就那么幾個。第一步是復(fù)位脈沖主機把總線拉低至少480微秒然后釋放傳感器會在60到240微秒內(nèi)拉低總線回應(yīng)一個存在脈沖表示“我在線”。uint8_t ow_reset(void) { uint8_t presence 0; GPIOB-BSRR GPIO_PIN_6; // 引腳拉低 delay_us(500); GPIOB-BRR GPIO_PIN_6; // 釋放總線 delay_us(70); presence (HAL_GPIO_ReadPin(GPIOB, GPIO_PIN_6) GPIO_PIN_RESET) ? 1 : 0; delay_us(420); return presence; }讀寫一個bit的時序稍微費點心思。寫0和寫1的區(qū)別是主機拉低之后釋放的時間點不同寫1要先拉低然后馬上釋放讓上拉電阻把總線拉高寫0則要一直保持低電平直到時隙結(jié)束。讀時序則是主機拉低1微秒后釋放然后在15微秒內(nèi)采樣總線電平此時如果傳感器想傳0它會主動拉低總線如果傳1則保持高電平。單總線的每個讀寫時隙大概60到120微秒延時差幾微秒有時候問題不大但在高溫、長線、多節(jié)點條件下時序余量會急劇縮小。驅(qū)動代碼里建議把所有延遲函數(shù)都改成基于定時器的微秒延時不要依賴循環(huán)空轉(zhuǎn)否則編譯器優(yōu)化等級一變時序全亂。提示具體延時參數(shù)一定要以所用批次芯片的數(shù)據(jù)手冊為準(zhǔn)。我們項目里同一封裝、不同批次的PJ85718DM存在脈沖寬度就略有差異驅(qū)動層保持了足夠裕量才好用。2.2 一條總線上掛多個傳感器64位ROM號與搜索算法單總線多點測溫靠的是每顆傳感器出廠時燒錄的64位ROM識別碼。這個ROM結(jié)構(gòu)固定8位家族碼、48位序列號、8位CRC校驗碼。主機通過發(fā)不同命令來操作總線上的某個或某幾個設(shè)備。常用命令有這么幾個0x33 讀ROM總線上只有單顆傳感器時讀取它的64位ROM。0x55 匹配ROM后面跟64位ROM只跟指定設(shè)備通信。0xCC 跳過ROM不指定地址對總線上所有設(shè)備廣播。0x44 啟動溫度轉(zhuǎn)換。0xBE 讀取暫存器拿到溫度原始值和配置字節(jié)。如果總線上掛了很多傳感器需要先枚舉出所有ROM。搜索算法一次只查一個bit通過兩次讀操作來判斷總線上設(shè)備在這一位的狀態(tài)00表示有分歧01和10表示該位唯一11表示總線上沒有設(shè)備。實際項目里我們不會每次上電都全量搜索而是在產(chǎn)線調(diào)試時搜索一次把各傳感器的ROM存到主控的配置表里后續(xù)直接按配置表匹配。CRC校驗在這里不是可選項。40米線上的干擾、接線端子氧化、上拉電阻老化都可能導(dǎo)致某一位翻轉(zhuǎn)。8位CRC雖然能力有限但對付這種偶發(fā)誤碼足夠。ROM讀取和暫存器讀取都需要做CRC校驗CRC多項式是x8x5x41對應(yīng)0x31。用查表法計算耗時幾微秒。2.3 本地與遠程測點的總線拓撲設(shè)計單總線接口雖然簡單拓撲設(shè)計卻有很多講究。推薦拓撲是“總線主干短支線”主干線從主控一直拉到最遠的傳感器每個傳感器通過盡量短的支線接入主干。本地測點在柜內(nèi)走線短問題不大。遠程測點的情況要復(fù)雜得多我們的做法是用一根屏蔽雙絞線從電控柜拉到室外機三顆傳感器都掛在這根雙絞線上支線控制在30厘米以內(nèi)。屏蔽層單端接地防止變頻器干擾耦合進總線。上拉電阻的選擇是單總線長線傳輸最容易翻車的地方。數(shù)據(jù)手冊上的推薦值一般是4.7kΩ但那是在理想短距離條件下的值?？偩€一長、節(jié)點一多線纜電容會把信號邊沿變慢4.7kΩ拉不上去數(shù)據(jù)就出錯。我們實測下來20米以內(nèi)4.7kΩ能用30米以上換2.2kΩ更穩(wěn)如果總線上掛了8顆以上傳感器可以直接降到1kΩ。上拉電阻取值基本上是在功耗和信號邊沿之間做權(quán)衡寧可用稍大的電流換穩(wěn)定也不要看著省了幾毫安結(jié)果讀回一堆85℃。供電方面強烈建議給傳感器外部供電也就是VDD和GND單獨接不要用寄生供電。寄生供電在長線、多節(jié)點場景下非常不可靠溫度轉(zhuǎn)換時需要的電流會直接把總線電壓拉出坑輕則讀取超時重則CRC全錯。3. 軟件架構(gòu)從底層驅(qū)動到Modbus/MQTT上報溫度數(shù)據(jù)怎么流轉(zhuǎn)3.1 單總線驅(qū)動放中斷還是主循環(huán)我的選擇是“狀態(tài)機定時器”單總線的微秒級時序和RTOS任務(wù)調(diào)度天然沖突。如果在一個RTOS任務(wù)里直接調(diào)用驅(qū)動一旦任務(wù)被更高優(yōu)先級搶占延時就不準(zhǔn)了。常見的解決辦法有兩種一是驅(qū)動執(zhí)行期間關(guān)閉調(diào)度器二是把單總線的整個讀寫過程改造成定時器中斷驅(qū)動的狀態(tài)機。我們項目用的是第二種。定時器中斷每10微秒觸發(fā)一次驅(qū)動層狀態(tài)機按順序推進復(fù)位移除延時、寫命令字節(jié)、讀數(shù)據(jù)字節(jié)。這樣RTOS任務(wù)只需要往隊列里丟一個“讀某ROM溫度”的請求然后等結(jié)果回調(diào)完全不影響系統(tǒng)里其他任務(wù)的實時性。狀態(tài)機雖然寫起來比順序代碼煩但它帶來兩個好處一是讀溫度變成異步操作主循環(huán)不會被一個長達幾十毫秒的ROM讀取過程卡住二是無論任務(wù)調(diào)度怎么折騰時序精度始終由硬件定時器保證這在長線多點場景下非常重要。3.2 一次性廣播轉(zhuǎn)換再逐個讀取采樣周期直接縮短到1秒剛開始實現(xiàn)時我們用的是最樸素的邏輯逐個傳感器發(fā)轉(zhuǎn)換命令每顆等待轉(zhuǎn)換完成再讀。四顆傳感器串行處理每一顆都要等約750毫秒轉(zhuǎn)換時間一輪下來接近4秒。對柜內(nèi)報警倒無所謂但對管道溫度反饋來說太慢了PID控制在4秒的純延遲下容易震蕩。優(yōu)化辦法其實很簡單利用單總線的廣播能力。先對整條總線發(fā)送跳過ROM加啟動轉(zhuǎn)換命令所有傳感器同時開始轉(zhuǎn)換主控等待800毫秒后再逐個匹配ROM讀取暫存器。這樣一輪采樣的時間就變成了“800毫秒轉(zhuǎn)換等待 4顆傳感器串行讀取”而每顆讀取只要幾毫秒整體周期控制在1秒以內(nèi)。這是個非常劃算的優(yōu)化強烈建議每個用單總線做多點測溫的項目都這么做。ow_reset(); ow_write_byte(0xCC); // 跳過ROM廣播 ow_write_byte(0x44); // 啟動溫度轉(zhuǎn)換 delay_ms(800); // 等待所有傳感器轉(zhuǎn)換完成 for (int i 0; i sensor_count; i) { ow_reset(); ow_write_byte(0x55); // 匹配ROM for (int j 0; j 8; j) { ow_write_byte(sensor_rom[i][j]); } ow_write_byte(0xBE); // 讀暫存器 // 讀取9字節(jié)計算溫度做CRC校驗 }16位原始溫度值的處理也要小心補碼問題。PJ85718DM分辨率是12位LSB對應(yīng)0.0625℃帶符號數(shù)。把兩個字節(jié)拼成int16_t再乘以0.0625就能得到浮點溫度。這里有個坑是不能先把有符號數(shù)無腦左移8位再相加補碼符號擴展錯了負溫度會變成很大的正溫度-10℃直接變成25606℃。3.3 數(shù)據(jù)緩存與軟件濾波報警、顯示、PID各自用不同策略原始溫度轉(zhuǎn)換出來之后不能直接丟給控制邏輯。我把每個測點維護了一個結(jié)構(gòu)體記錄原始溫度、濾波后溫度、上次采樣時間、狀態(tài)標(biāo)志正常/開路/CRC錯誤/超時再按用途分發(fā)數(shù)據(jù)。濾波策略上我分了三檔報警邏輯用“瞬時值越限遲滯”不需要平滑避免掩蓋真實風(fēng)險。顯示用滑動平均窗口5次大約5秒更新一次看起來不跳字。PID反饋用輕度濾波窗口2到3次即可。濾波太狠會引入相位滯后管道溫度變化本來就慢窗口大了PID會遲鈍。每次采完數(shù)據(jù)還會做一次合理性檢查比如溫度超出-55℃到125℃物理范圍或者和上次采樣差超過15℃直接標(biāo)記為無效數(shù)據(jù)。無效數(shù)據(jù)不進控制回路但保留原始值方便上位機查通信問題。3.4 上報鏈路Modbus RTU給觸摸屏JSON透傳給遠程平臺HVAC項目里現(xiàn)場觸摸屏和上位機組態(tài)軟件幾乎都認Modbus RTU協(xié)議。STM32F205RB的USART外接了一顆RS485收發(fā)芯片作為Modbus從站接入現(xiàn)場總線。溫度數(shù)據(jù)映射到保持寄存器40001到40004分別是四個測點的溫度值單位0.01℃有符號整型40005是狀態(tài)字每個bit對應(yīng)一個測點的健康狀態(tài)。請求01 03 00 00 00 08 CRC 響應(yīng)01 03 10 XX XX XX XX ... CRC把浮點溫度換算成0.01℃的整型再上Modbus這是從工控行業(yè)沿用下來的習(xí)慣。很多組態(tài)軟件和觸摸屏的數(shù)值控件都帶小數(shù)點偏移配置好就能直接顯示兩位小數(shù)還完全避開浮點字節(jié)序的破事。遠程上報這邊主控預(yù)留了一路USART接串口透傳模塊通過AT指令建立TCP連接往服務(wù)器丟JSON字符串{dev: 2301, t_local: 32.18, t_pipe: 22.45, t_return: 23.62, t_outdoor: 18.30, ts: 1711000000}JSON雖然冗長但平臺端解析方便調(diào)試排查也直觀。一條完整上報報文不到200字節(jié)對本地服務(wù)器帶寬毫無壓力。主控不需要維護復(fù)雜加密協(xié)議透傳模塊把AT指令封裝好嵌入式側(cè)只需要維護一個“上線-上報-斷線重連”的狀態(tài)機。4. 實測數(shù)據(jù)背后校準(zhǔn)方法、誤差來源和現(xiàn)場調(diào)試記錄4.1 冰水混合物和恒溫槽的現(xiàn)場校準(zhǔn)PJ85718DM這類數(shù)字傳感器出廠前做過校準(zhǔn)但現(xiàn)場安裝后還是有必要做一次整體驗證因為安裝方式對讀數(shù)的影響有時比芯片本身的誤差還大。我們的做法是兩步校準(zhǔn)。第一步用冰水混合物驗證0℃點保溫桶里碎冰加水穩(wěn)定后把傳感器探頭放進去讀數(shù)應(yīng)該在0℃附近。第二步用恒溫槽設(shè)到50℃驗證量程中段。每顆傳感器測出來的偏差記錄到主控的校準(zhǔn)表里程序里以偏移量方式修正。我挑了三顆傳感器的實測記錄傳感器編號冰水混合物讀數(shù)恒溫槽50.0℃讀數(shù)偏差1號0.06℃50.12℃0.06~0.12℃2號-0.11℃49.88℃-0.11~-0.12℃3號0.02℃50.25℃0.02~0.25℃這個結(jié)果說明芯片本身的重復(fù)性和一致性都還行。真正的偏差大頭往往不在芯片而在于探頭的安裝位置和傳熱路徑這在后面的誤差分析里展開。4.2 誤差來源拆解自熱、安裝位置、傳輸延遲數(shù)字溫度傳感器有一個容易被忽略的誤差源——自熱。傳感器工作時本身會有電流流過芯片內(nèi)部會因此升溫。在氣流靜止的封閉探針里自熱效應(yīng)會讓讀數(shù)憑空高零點幾攝氏度。解決辦法是降低采樣頻率或者盡量采用前面說的廣播轉(zhuǎn)換模式讓傳感器大部分時間處于休眠狀態(tài)只有轉(zhuǎn)換瞬間才通電工作。安裝位置造成的誤差比自熱大得多。空調(diào)箱的送風(fēng)管道里如果探頭緊貼管壁測到的很可能是金屬管壁的溫度而不是空氣溫度。管壁受外部環(huán)境溫度影響夏天曬熱的管道外壁會讓管內(nèi)探頭讀數(shù)偏高。現(xiàn)場處理方法是把探頭盡量伸到管道中心外部做保溫探頭周圍留出空氣流通空間。傳輸延遲是另一種誤差。溫度轉(zhuǎn)換需要時間數(shù)據(jù)從現(xiàn)場傳感器傳到主控、再傳到服務(wù)器都有延遲尤其當(dāng)采樣周期拉長時控制回路看到的溫度永遠是“過去的溫度”。PID參數(shù)整定時要把這個延遲算進去否則比例增益稍微放大就容易震蕩。4.3 長距離傳輸實測不同線長下的穩(wěn)定性數(shù)據(jù)為了給后續(xù)項目留經(jīng)驗我們在現(xiàn)場專門做了一組長距離測試分別用10米、30米、60米和100米線纜測總線穩(wěn)定性。測試方法是連續(xù)讀一顆傳感器200次統(tǒng)計CRC錯誤次數(shù)和讀取失敗次數(shù)。線長上拉電阻CRC錯誤率備注10米4.7kΩ0%很正常30米4.7kΩ1.5%偶發(fā)錯誤30米2.2kΩ0%穩(wěn)定60米2.2kΩ0.5%偶爾出錯60米1kΩ0%穩(wěn)定100米1kΩ2%不建議單總線傳超過100米結(jié)論很清晰單總線在100米以內(nèi)都有工程可用性但上拉電阻必須根據(jù)線長調(diào)整且最好留出CRC容錯邏輯。超過100米與其想辦法增強上拉不如直接在遠端放一個RS485轉(zhuǎn)單總線采集器用Modbus RTU把數(shù)據(jù)傳回來比硬撐單總線穩(wěn)得多。5. 現(xiàn)場踩坑與復(fù)盤四個讓調(diào)試進度倒退一周的細節(jié)5.1 上拉電阻照抄手冊的4.7kΩ遠程測點頻繁讀到85℃調(diào)試第一天遠程管道溫度時不時讀出85℃而且在正常溫度和不正常的85℃之間跳變。當(dāng)時第一反應(yīng)是傳感器壞了換一顆新的還是偶爾跳。后來排查到根因是上拉電阻。手冊里寫4.7kΩ但這條總線上掛了3顆遠程傳感器、線長超過40米總線寄生電容把上升沿拖慢了導(dǎo)致主機在某些位采樣時讀到不確定電平。讀回來的數(shù)據(jù)CRC校驗偶爾能過、偶爾不能過而CRC過的時候也不代表對——因為在某些位翻轉(zhuǎn)恰好撞上了CRC多項式約束就成了一個看起來合法但其實錯誤的值。解決辦法把遠程單獨這條總線的上拉從4.7kΩ換成2.2kΩ再用一個0.1μF電容并在主控側(cè)總線連接處。換完以后跑了一整天誤碼率清零。注意看到85℃這個數(shù)字優(yōu)先檢查通信和供電不要急著懷疑傳感器本體。85℃是很多單總線器件上電復(fù)位時溫度寄存器的默認值數(shù)據(jù)鏈路出問題時常讀到它。5.2 傳感器裝在散熱器旁邊溫度讀數(shù)偏高3℃還堅稱“沒問題”管道測點讀數(shù)一直比空調(diào)箱自帶顯示的溫度高3到4℃因為偏差相對穩(wěn)定一開始我們以為是傳感器精度差異準(zhǔn)備做軟件負偏移。后來拿點溫槍對著探頭安裝位置一打發(fā)現(xiàn)現(xiàn)場溫度確實比管道中心空氣溫度高——因為探頭裝在管道末端靠近電加熱器外殼的位置熱輻射把探頭周圍的空氣加熱了它測得很真實但測的不是我們想要的那個溫度。這個問題暴露了一個很本質(zhì)的道理數(shù)字傳感器的精度再高測量位置的錯誤也無法被校準(zhǔn)彌補。后來重新在管道上開孔把探頭移到氣流中心加了一個固定支架讀數(shù)立刻和空調(diào)箱顯示吻合。傳感器選型、布線做得再好探頭位置錯了整個數(shù)據(jù)鏈路都是白搭。5.3 遠程管道支線過長導(dǎo)致柜內(nèi)本地傳感器也被拖下水第三期工程把管道測點從1個加到4個現(xiàn)場施工圖為了省線纜讓4個探頭沿著管道每隔幾米接進主總線。結(jié)果接上第3個探頭之后柜內(nèi)本地溫度也開始報超時。原因是支線過長形成了“T形反射”。單總線上每個分支都是一段短路線纜分支越長反射越嚴重總線上的信號完整性被徹底破壞。4.7k的上拉電阻提供的驅(qū)動能力有限反射波疊加之后主機側(cè)采到的電平錯亂。處理辦法是重新布線把原來的“每點分叉”改成“總線串接”也就是主總線從主控一路拉到最遠探頭沿途每個探頭用不超過30厘米的短線接到主干線。重新布完以后本地和遠程全部恢復(fù)正常。單總線布線有一條鐵律分支越短越好最好是一根主干線多點接入每個分支不超過30厘米。實在做不到每個節(jié)點在線纜側(cè)加一個小電容也能緩解但治標(biāo)不治本。5.4 更換傳感器備件后忘記更新ROM配置表數(shù)據(jù)一直超時系統(tǒng)運行了半年后有個遠程探頭報CRC錯誤且無法恢復(fù)判定傳感器損壞?，F(xiàn)場換上新探頭離線測試讀數(shù)正常但接回總線后主控依舊一直報超時。排查半天原因是主控里存的是舊傳感器的64位ROM而單總線的匹配ROM命令是按地址點名的。新傳感器的ROM不同主控拿著舊地址去匹配總線上的設(shè)備一個都不應(yīng)答自然永遠超時。后來重新運行了一次總線搜索把新ROM寫進配置表問題立刻解決。這個坑提醒我們?nèi)魏斡脝慰偩€做多點測溫的系統(tǒng)都要在設(shè)備端做“ROM配置表在線更新”功能?，F(xiàn)場換傳感器的概率比想象中高得多每次換完都靠工程師連調(diào)試器改代碼根本不可持續(xù)。最后再分享一個個人習(xí)慣現(xiàn)場采集的溫度數(shù)據(jù)我只信任“連續(xù)三次CRC校驗通過數(shù)值范圍判斷”雙重確認后的結(jié)果寧可丟一次采樣也不把錯誤值寫進歷史曲線。溫度數(shù)據(jù)一旦進入PID控制回路一個偶然的尖峰可能讓電加熱器輸出猛地跳一下影響比丟幀大多了。這組配置在柜內(nèi)報警、管道溫度報警里都跑得很穩(wěn)后續(xù)準(zhǔn)備把這套單總線測溫邏輯移植到用RS485級聯(lián)采集節(jié)點的方案里看看能不能把測點規(guī)模再往上推一推。