將從設(shè)備的地址設(shè)置好還有問題？它自己會改變？

如果設(shè)置好的話是沒有問題的，但是如果施工或維護(hù)人員操作失誤，不小心設(shè)置了兩個相同的地址的話，整個系統(tǒng)有短路燒毀的危險，實在是不能不慎重啊！

從機(jī)設(shè)備采用硬件唯一ID。主機(jī)定期輪詢所有設(shè)備列表，發(fā)現(xiàn)有重復(fù)的地址則告警。

問題時如何發(fā)現(xiàn)重復(fù)地址。當(dāng)?shù)刂分貜?fù)時，有可能響應(yīng)的數(shù)據(jù)是一樣的，或者同時搶占總線，造成數(shù)據(jù)錯亂。

485這一點是比較討厭的，在發(fā)送的時候無法知道總線的真實狀況。

樓主不妨換個思路，從源頭上掐死邏輯地址重復(fù)的可能性。主機(jī)處必定是有從機(jī)地址列表的。在從機(jī)上設(shè)置地址時，在當(dāng)次令牌周期內(nèi)獲得令牌后，將舊地址、新地址以及從機(jī)的唯一標(biāo)識發(fā)送給主機(jī)，建表歸檔。如果地址無重復(fù)，主機(jī)確認(rèn)，從機(jī)交還令牌；有重復(fù)，主機(jī)拒絕，從機(jī)交還令牌并顯示設(shè)置錯誤。

LZ，只要解決一個關(guān)鍵，你的問題就很好解決了：
應(yīng)該設(shè)計硬件地址（唯一ID號）和軟件地址，程序上既能按硬件地址通訊也能按軟件地址通訊即可。
按硬件地址通訊可以限定成只有個別命令可以，這樣可靠性更高。

應(yīng)答方應(yīng)作隨機(jī)延時和多次應(yīng)答、超時機(jī)制，避免沖突時丟失應(yīng)答的可能

謝謝樓上兩位。
To ejack:
你的意思是從機(jī)加入系統(tǒng)時，要跟主機(jī)有交互。這個可能不好實現(xiàn)，因為我的從機(jī)設(shè)備很小，維護(hù)人員可能在別處設(shè)好地址，直接加入系統(tǒng)，就可以正常運行。

To xwj：
設(shè)計硬件地址是可以的，可以在生產(chǎn)時寫入，但是上位機(jī)如何知道從機(jī)的硬件地址呢？

我認(rèn)為完美的方案是這樣的：
從機(jī)接收到總線命令后，能夠跟總線上的其他相同地址的從機(jī)產(chǎn)生交互，從而知道總線上有地址重復(fù)，從而拒絕執(zhí)行命令，并且上報地址重復(fù)信息。

但是如何交互是一個麻煩。
基本方案如下：
假定總線上有兩個相同地址的從機(jī)A和B
當(dāng)主機(jī)下發(fā)命令時，A，B都收到了命令，然后定時隨機(jī)時間發(fā)送隨機(jī)數(shù)據(jù)（比如每隔1-20ms隨機(jī)發(fā)送00-FF），在不發(fā)送時偵測總線，多次偵測后，當(dāng)一次或一次以上偵測到總線上有數(shù)據(jù)時，認(rèn)為有重復(fù)地址。當(dāng)然，主機(jī)在這段時間要裝聾作啞了。

這個方案還是有發(fā)現(xiàn)不了的可能性，只是把可能性降低了很多，還是不完美。

485這一點是比較討厭的，在發(fā)送的時候無法知道總線的真實狀況。

這句不理解。完全可以發(fā)送的同時偵測總線啊，只不過要加另外一顆485芯片，或者使用一顆雙向芯片。

1.向一個新設(shè)備的地址讀取序列號和校驗字.如果有沖突,必然線與.得到結(jié)果錯誤.如果沒有錯誤則認(rèn)為地址不沖突.
2.發(fā)數(shù)據(jù)是進(jìn)行狀態(tài)檢查.發(fā)送1,線狀態(tài)必須為1.如果為0,則認(rèn)為有多從機(jī).

想起了有次參加研討會聽到有個人從“os任務(wù)死看門狗還跑”擔(dān)憂到“x=y+z運算到最后突然由于干擾導(dǎo)致累加器發(fā)生了1bit變化如何是好”:lol

技術(shù)只是一個工具，它不是萬能的。我覺得，只能建立一套管理體系，從根本上杜絕相同ID的從機(jī)掛在一個總線上。

主站應(yīng)該維護(hù)一張數(shù)據(jù)庫表格，列出所有當(dāng)前掛接的從機(jī)，在每次安裝或者維護(hù)之后，運行一個“一致性檢驗”程序，遍歷所有從機(jī)ID，并與數(shù)據(jù)庫匹配，匹配成功則開始工作，通訊出錯或者數(shù)量不一致，則不予投產(chǎn)，總不能不問死活就亂發(fā)命令。

這些功能，屬于系統(tǒng)維護(hù)的部分，操作權(quán)限高于普通用戶。每次工作之后要建立紙質(zhì)檔案，有授權(quán)有簽字。并且建立系統(tǒng)日志，可以追溯問題根源。日志加密，只能查看不能修改。

將此寫入操作規(guī)程，作為用戶的企業(yè)標(biāo)準(zhǔn)執(zhí)行。安全遠(yuǎn)遠(yuǎn)比技術(shù)重要，不能怕麻煩。

上述實現(xiàn)是有前提的：維護(hù)系統(tǒng)時要停產(chǎn)。xwj說的讓新加入的從機(jī)自動去主站注冊，這在不能停產(chǎn)的系統(tǒng)里有意義。問題是，這個過程怎么實現(xiàn)？

正常情況下，比如MODBUS，通訊申請都是主站發(fā)起的，而不是相反。要想實現(xiàn)從機(jī)發(fā)送，從機(jī)必須知道總線空閑，這對一個成型的系統(tǒng)很困難?，F(xiàn)有系統(tǒng)未見得支持空閑識別，主站和從機(jī)都變成了雙向通訊，硬件和軟件的改動會非常大。

呵呵，好幾天沒有上來了。
不管態(tài)度如何，歡迎大家的關(guān)注和批評指正。

to xwj：
??不管我的構(gòu)思是不是真的是“狗屎”和“垃圾”，但我是抱著一種技術(shù)探討的態(tài)度來說明這個問題的，同時也是拋磚引玉的

意思。如果您能夠用不垃圾的技術(shù)方法來解決該問題，我被罵一句也不要緊??！
謝謝您的參與和關(guān)注。

正如15樓所說，我的系統(tǒng)是MODBUS，系統(tǒng)通信只能是由主機(jī)發(fā)起，從機(jī)響應(yīng)。系統(tǒng)正常運行時，不允許從機(jī)主動隨機(jī)向總

線發(fā)送數(shù)據(jù)，否則數(shù)據(jù)沖突的可能性很大。
而實際的應(yīng)用場景是這樣的：
系統(tǒng)正常運行時，某個從機(jī)模塊故障，比如001號。此時要求系統(tǒng)不能停產(chǎn)，維護(hù)人員用新的從機(jī)模塊寫入地址001，然后更換

模塊。實在不能指望這幫維護(hù)人員的技術(shù)素質(zhì)，搞錯地址不是一次兩次了。
所以我希望先從技術(shù)手段上考慮解決這個問題的可能性，不行的話再用管理手段解決。

另外還想探討一下之前我的想法，虛心請教各位：
xwj先生說了四個缺點：
1.從機(jī)要相互交互
??這個確實增加了從機(jī)的設(shè)計難度，但是只是在接收到命令之后的一個判斷程序，并沒有硬件的改動；
2.主機(jī)裝聾作啞
??主機(jī)在發(fā)出命令后本身是有等待延時的，不符合協(xié)議的數(shù)據(jù)不會接收；
3.總線上還大量大垃圾數(shù)據(jù)
??在總線上是主機(jī)巡檢機(jī)制，本身數(shù)據(jù)量不大，沒有通信效率的壓力；
4.一個命令還要和可能有可能沒的其他從機(jī)交互后才能執(zhí)行
??這個交互可能只需要數(shù)十ms,對于執(zhí)行時間（10S左右），可以忽略不計。

xwj先生的問題可能也是因為我沒有詳細(xì)的說明實際應(yīng)用場景。上述問題確實存在，但我覺得可以忍受。

另外，也有優(yōu)點：
1.無須主機(jī)參與，修改只涉及從機(jī)的命令接收部分程序，工作量不大；
2.比起管理手段，綜合成本要低。

虛心請教各位，請大家多批評指正。

大家在實際應(yīng)用中是如何處理此類問題的呢？

每個設(shè)備設(shè)ID，采用注冊方式和主機(jī)連上，主機(jī)分配一個總線地址給設(shè)備；同時需要對所發(fā)消息的校驗，防止誤碼。