到目前為止,從原型到生產這系列專欄文章中,我們已經針對對於利用Arduino硬體的工業物聯網(IIoT)控制器,甚至開發人員如何使用Python等議題進行一些基本要求的研究。現在,讓我們來探討一些與工業感測器介面接口相關,需要謹記在心的技巧。

技巧1—留意介面變壓

從某供應商到另一位供應商,電壓數值都不同,但微控制器(MCU)硬體通常希望看到輸入訊號電壓正確地在3.0~3.3伏特(V)範圍內。微控制器針對連接到消費性電子感測器,一般不會有很多的硬體介面接口需求,尤其當這些感測器被設計成直接與微控制器連接時。但工業感測器可以是完全不同的故事。

一個工業感測器可能是直接連接到典型的微控制器,但奇怪的是,工業感測器介面將根據系統和感測器的狀況,電壓可從5伏特到高達48伏特。連接這些在高壓工作的感測器,無疑會影響微控制器本身效能,以及讓一個開發者無時不刻被打擾。總是至少需要幾分鐘的時間來審查微控制器和感測器這兩個介面接口的需求,如果需要,可以使用一個電晶體(transistor)加上一個簡單的電平移位(level shifter)電路,或者使用一個現成的緩衝電路。

技巧2—以標準介面選擇感測器

在過去的15年,我接觸過一些特殊且酷的感測器,但無論感測器如何實用與多麼先進,若是其未內建標準介面,則需要特別小心!客製化的感測器介面將非常難以與之連接,一個很好的例子是其代碼(code)通常不可用,用來除錯(debugging)的介面現成工具是不存在的。當然,開發者可以幸運地從感測器製造商得到一些支援,但在這種情況下,它的進展會比較緩慢,因為銷售團隊位於美國,清楚感測器如何運作的工程師都在地球的另一邊。維持感測器的已知和標準介面,諸如類比(Analog)、控制器區域網路(CAN)、Modbus、串列(Serial),和其他微控制器很容易理解的介面。

技巧3—開發時使用通訊協議分析儀(protocol analyzer)

儘管勤奮、有紀律和具天才般的頭腦,工程師做出來的表,在第一次嘗試的工作中,很少使用代碼或硬體。工程師們已經變得非常善於最大限度地減少會遭遇到的問題,但事實是,我們仍需要衛系統除錯,示波器(oscilloscope)針對觀察原始硬體介面可起很大的作用,但一台通訊協議分析儀可以解碼數據並傳送,可幫助開發人員很快發現問題。通訊協議分析儀可以是獨立的工具。如匯流排監視器(bus monitor),或者它們可以是一台內建複雜示波器的分析儀。

我不會主張走出門並購買工具,僅是在陳述一個明顯的事實是,若你擁有合適的工具,你的工作會進行得更快速、只需少量的努力,並為其他人(公司、工程師和終端客戶)製作出更好的產品。通訊協議分析儀可作為工程師的眼和耳,使其更易於去看到感測器介面真正發生了什麼,而不需要猜測。

技巧4—當心Vin陷阱

在先前的文章,我們研究了Arduino硬體,和許多屏蔽(shield)與開發工具包(development kit), 它可以出現該施加電壓到Vin,這將導致3伏特和5伏特電壓在匯流排接腳(pin)。有時候這會是真的,且一個5伏特感測器介面將如同預期的運作;但有時,也讓我們只想說,當除錯一段時間後,工程師會發現感測器並未通電。當連接工業感測器到一塊Arduino電路板,它總是個好方式以探測周圍主機板的電壓,並確保關於主機板如何運作的所有有關的假設實際上都正確。一個簡單的電壓檢查可能只是保住你一或兩根白髮。

技巧5—使用嘗試/除外/最後(try/except/finally)

當開發韌體(firmware)與感測器進行溝通時,別以一種天真、樂觀的態度認為一切工作正按計畫進行;相反地,應採取完全相反的做法,並認為事情會出錯。使用try/except/finally Python架構以捕捉並處理感測器的通訊問題,try關鍵字可以用於嘗試與感測器通訊,如採樣到感測器;若是一切順利,樣品會被檢索且except的情況將永遠不會被執行。然而,如果確實存在錯誤,except情況可以用來擷取到底是什麼地方出了錯,並允許開發人員更了解手頭上要解決的問題。

結論

介接工業感測器可能會對開發商造成一些問題。第一道門檻是簡單的確保感測器和微控制器的硬體介面是相容的;一旦此門檻無法跨越,感測器通訊協議會成為一個潛在的絆腳石。選擇使用一個共同通訊協議的感測器可以解決介面問題,並幫助開發人員可更快與他們的感測器「通話」。