發現的問題
在軟體初始化過程中卡死在instrument booting(儀器初始化)過程,經排查發現設定液面感應電容只回覆了bb和cc而未回覆33或55.導致上位機卡死.經確認液面感應板與驅動板線路虛焊導致通訊失敗.
有關故障識別的問題
通訊過程直接下發下位機時序屬於定製功能,下位機並不受上位機軟體管理,因此除了固定的位元組陣列外其他資訊一無所知,每個指令的執行超時時間並不知道.因此在現有模式下讓上位機識別下位機超時並不合理.
此外,由於現有的中位機和驅動板是按照配置模式設計,不具備通訊檢查的功能.因此讓板卡定製程式也不科學(畢竟不知道到底有沒有液面感應版,需要配置).
另外,有人提出了心跳包的方案對硬體及底層軟體的改動也比較大.並不划算的方案.
提出硬體自檢的方案
常規的儀器裝置自身的一些常規錯誤應當自己檢查,比如通訊,供電等.作為基礎檢查是必不可少的.因此應當系統開始時進行自檢檢查更加合理.結合時序配置方案,可以將板卡的自檢作為下位機時序,通過命令呼叫執行,單次檢查避免了心跳包的改動,出現錯誤可以按照原有協議向上位機返回錯誤**.
需要改動的內容
由於現有方案是由上位機軟體主導初始化,因此需要增加指令使上位機呼叫啟動自檢.
中位機和驅動板需要增加新的功能以執行自檢命令(通訊測試),及錯誤**反饋.
在錯誤**的配置檔案中增加錯誤**.供上位機關聯識別報警.
linu系統初始化配置
1 關閉防火牆 檢視狀態 firewall cmd state 停止防火牆 systemctl stop firewalld.service 設定禁止開機啟動防火牆 systemctl disable firewalld.service 2 設定網路 選擇橋接模式 vi etc sysconfig ...
SparkContext的初始化機制
1.createtaskscheduler 建立sparkscheduler，sparkdeployschedulerbackend 它在底層負責接收taskschedulerimpl的控制，實際上負責與master的註冊，executor的反註冊，task傳送到executor等操作 呼叫task...
Spring 配置及物件初始化（1）
一，配置檔案進行spring初始化 1，配置檔案編寫 1.0 encoding utf 8 這裡會報異常 spring.context.support.contextregistry 的型別初始值設定項引發異常。把配置注釋掉就行了 v4.0 sku netframework,version v4.0...