关于总线冲突的问题

将从设备的地址设置好还有问题？它自己会改变？

如果设置好的话是没有问题的，但是如果施工或维护人员操作失误，不小心设置了两个相同的地址的话，整个系统有短路烧毁的危险，实在是不能不慎重啊！

从机设备采用硬件唯一ID。主机定期轮询所有设备列表，发现有重复的地址则告警。

问题时如何发现重复地址。当地址重复时，有可能响应的数据是一样的，或者同时抢占总线，造成数据错乱。

485这一点是比较讨厌的，在发送的时候无法知道总线的真实状况。

楼主不妨换个思路，从源头上掐死逻辑地址重复的可能性。主机处必定是有从机地址列表的。在从机上设置地址时，在当次令牌周期内获得令牌后，将旧地址、新地址以及从机的唯一标识发送给主机，建表归档。如果地址无重复，主机确认，从机交还令牌；有重复，主机拒绝，从机交还令牌并显示设置错误。

LZ，只要解决一个关键，你的问题就很好解决了：
应该设计硬件地址（唯一ID号）和软件地址，程序上既能按硬件地址通讯也能按软件地址通讯即可。
按硬件地址通讯可以限定成只有个别命令可以，这样可靠性更高。

应答方应作随机延时和多次应答、超时机制，避免冲突时丢失应答的可能

谢谢楼上两位。
To ejack:
你的意思是从机加入系统时，要跟主机有交互。这个可能不好实现，因为我的从机设备很小，维护人员可能在别处设好地址，直接加入系统，就可以正常运行。

To xwj：
设计硬件地址是可以的，可以在生产时写入，但是上位机如何知道从机的硬件地址呢？

我认为完美的方案是这样的：
从机接收到总线命令后，能够跟总线上的其他相同地址的从机产生交互，从而知道总线上有地址重复，从而拒绝执行命令，并且上报地址重复信息。

但是如何交互是一个麻烦。
基本方案如下：
假定总线上有两个相同地址的从机A和B
当主机下发命令时，A，B都收到了命令，然后定时随机时间发送随机数据（比如每隔1-20ms随机发送00-FF），在不发送时侦测总线，多次侦测后，当一次或一次以上侦测到总线上有数据时，认为有重复地址。当然，主机在这段时间要装聋作哑了。

这个方案还是有发现不了的可能性，只是把可能性降低了很多，还是不完美。

485这一点是比较讨厌的，在发送的时候无法知道总线的真实状况。

这句不理解。完全可以发送的同时侦测总线啊，只不过要加另外一颗485芯片，或者使用一颗双向芯片。

1.向一个新设备的地址读取序列号和校验字.如果有冲突,必然线与.得到结果错误.如果没有错误则认为地址不冲突.
2.发数据是进行状态检查.发送1,线状态必须为1.如果为0,则认为有多从机.

想起了有次参加研讨会听到有个人从“os任务死看门狗还跑”担忧到“x=y+z运算到最后突然由于干扰导致累加器发生了1bit变化如何是好”:lol

技术只是一个工具，它不是万能的。我觉得，只能建立一套管理体系，从根本上杜绝相同ID的从机挂在一个总线上。

主站应该维护一张数据库表格，列出所有当前挂接的从机，在每次安装或者维护之后，运行一个“一致性检验”程序，遍历所有从机ID，并与数据库匹配，匹配成功则开始工作，通讯出错或者数量不一致，则不予投产，总不能不问死活就乱发命令。

这些功能，属于系统维护的部分，操作权限高于普通用户。每次工作之后要建立纸质档案，有授权有签字。并且建立系统日志，可以追溯问题根源。日志加密，只能查看不能修改。

将此写入操作规程，作为用户的企业标准执行。安全远远比技术重要，不能怕麻烦。

上述实现是有前提的：维护系统时要停产。xwj说的让新加入的从机自动去主站注册，这在不能停产的系统里有意义。问题是，这个过程怎么实现？

正常情况下，比如MODBUS，通讯申请都是主站发起的，而不是相反。要想实现从机发送，从机必须知道总线空闲，这对一个成型的系统很困难。现有系统未见得支持空闲识别，主站和从机都变成了双向通讯，硬件和软件的改动会非常大。

呵呵，好几天没有上来了。
不管态度如何，欢迎大家的关注和批评指正。

to xwj：
  不管我的构思是不是真的是“狗屎”和“垃圾”，但我是抱着一种技术探讨的态度来说明这个问题的，同时也是抛砖引玉的

意思。如果您能够用不垃圾的技术方法来解决该问题，我被骂一句也不要紧啊！
谢谢您的参与和关注。

正如15楼所说，我的系统是MODBUS，系统通信只能是由主机发起，从机响应。系统正常运行时，不允许从机主动随机向总

线发送数据，否则数据冲突的可能性很大。
而实际的应用场景是这样的：
系统正常运行时，某个从机模块故障，比如001号。此时要求系统不能停产，维护人员用新的从机模块写入地址001，然后更换

模块。实在不能指望这帮维护人员的技术素质，搞错地址不是一次两次了。
所以我希望先从技术手段上考虑解决这个问题的可能性，不行的话再用管理手段解决。

另外还想探讨一下之前我的想法，虚心请教各位：
xwj先生说了四个缺点：
1.从机要相互交互
  这个确实增加了从机的设计难度，但是只是在接收到命令之后的一个判断程序，并没有硬件的改动；
2.主机装聋作哑
  主机在发出命令后本身是有等待延时的，不符合协议的数据不会接收；
3.总线上还大量大垃圾数据
  在总线上是主机巡检机制，本身数据量不大，没有通信效率的压力；
4.一个命令还要和可能有可能没的其他从机交互后才能执行
  这个交互可能只需要数十ms,对于执行时间（10S左右），可以忽略不计。

xwj先生的问题可能也是因为我没有详细的说明实际应用场景。上述问题确实存在，但我觉得可以忍受。

另外，也有优点：
1.无须主机参与，修改只涉及从机的命令接收部分程序，工作量不大；
2.比起管理手段，综合成本要低。

虚心请教各位，请大家多批评指正。

大家在实际应用中是如何处理此类问题的呢？

每个设备设ID，采用注册方式和主机连上，主机分配一个总线地址给设备；同时需要对所发消息的校验，防止误码。