Идентификация устройств в сети RS-485

[kj]

Всем привет. Подскажите как организовать сеть RS-485. Один мастер и много ведомых. У каждого будет зашит свой номер. По этому номеру при инициализации будет присваиваться адрес. Но как считать этот номер. Ведь при выдачи запроса, например, GET_ID все начнут его выдавать будет конфликт. Наверняка существуют какие-то решения

[tych]

Случайные числа помогут.

[Aheir]

Максимальное число устройств в сети известно?
Можно заранее прошить в ведомых некие порядковые номера от 1 до максимума и запрограммировать их так, чтобы они отвечали только после n-го запроса GET-ID, где n - порядковый номер устройства.
Т.е. выдаете в сеть столько запросов GET-ID, сколько м.б. устройств в Вашей сети, после каждого запроса от соотв. устройства приходит (или не приходит ответ...
Пойдет такой вариант?

[kj]

Максимальное число устройств 6. Данный вариант не подходит потому что устройства будут разные. Т.е. нельзя заранее сказать с какими ID в сети будут устройства. Может все таки пойти на конфликт шины и сделать так как это реализовано в MicroLan. Каким образом я могу применить метод случайных чисел? Предполагается 32битный ID. Должен же быть какой то способ получения номера без конфликта на шине

[kj]

Как в МикроЛан не получится там открытый сток. Мда

[tych]

устройства будут разные.

Должен же быть какой то способ получения номера без конфликта на шине

Случайные числа, случайные паузы.

[kj]

То есть предлагается каждому номеру сопоставить выдержку через которую он будет отвечать? Если максимальное число 4 млрд то какая это будет выдержка

[tych]

То есть предлагается каждому номеру сопоставить выдержку через которую он будет отвечать?

Вы слово СЛУЧАЙНОЕ понимаете ?

Если сопоставить заранее - это будет случайное ?

[kj]

Хорошо допустим. Скорость при инициализации 9600. Посылка 8-ми байтовая. Для получения номера -- 2 посылки. Все это займет примерно 15 мс. Максимальное время инициализации 5с. Делим 5 на 15мс. Получаем 333. А если устройств будет произведено тысячи, десятки тысяч. Согласитесь довольно высока вероятность что в одной сети совпадут устройства с одинаковой выдержкой, что недопустимо

[Aheir]

А решение обязательно д.б. чисто программное?
Обычно в таких ситуациях просто ставится несколько джамперов или дип-переключатель, на которых на этапе монтажа сети выставляются уникальные номера устройств в данной конкретной сети. При этом внутренний ID уникален для каждого устройства. А вот его в этом случае можно получать по описанной выше схеме.

Однако здесь возможен косяк при неодновременном включении устройств.

Вообще, в broadcast сетях (а речь, похоже, именно о такой) используется random acсess time, т.е. после подачи команды устройство отсылает свой ID через случайное время, лежащее в некотором диапазоне. В этой ситуации коллизии возможны, но вероятность их невелика, при возникновении коллизии надо просто повторить опрос.

Можно скрестить эти варианты: после команды устройство возвращает айдишник по прошествии времени, заданного джампером на устройстве.

Вообще, некоторые нюансы все же будут зависить от очередности подачи питания на устройства.

[kj]

К сожалению оно должно быть программное. Самый оптимальный вариант на корпусе нанести серийный номер и при конфигурации вписать мастеру все серийники. Но к сожалению данный способ не подходит по целому ряду причин. DIP ы тоже не подходят. К сожалению. Вот поэтому и парюсь. Должен же быть какойто способ. Ведь в промышленности RS 485 рулит. Тот же ProfiBus, ModBus. Может кто знает?

[Aheir]

Тогда пробуйте по принципу broadcast'a, только все же обработчик коллизий надо продумать будет.

[kj]

Ну конечно сначала broadcast запрос -- получаю все номера, адресую. А потом чтоб скорость была максимальная никаких коллизий возникать не должно. Обратился по адресу -- получил ответ. Все остальные молчат

[tych]

Должен же быть какойто способ.

Уж несколько раз его вам сказал.

[kj]

Необходимо ПОЛНОСТЬЮ исключить вероятность ошибки при конфигурирровании. Каково это будет если в 1000 случаях кофигурация будет нормальная. а в 1001 случае попадутся 2 устройства с совпадающей выдержкой. Согласитесь диапазон случайных чисел от 0 до 333 не такой уж большой

[ARV]

я думаю, придется обязательно слушать линию во время передачи. если ведомый начинает передавать ответ на широковещательный запрос, и при этом обнаруживает, что принимает он не то, что передает - он замолкает на некий псевдослучайный интервал времени, например, просто пропорциональный его физическому адресу, и лишь после того начинает вторую попытку передать. причем любая попытка начать передачу всегда начинается с прослушивания линии в течение того же псевдослучайного интервала времени - только если линия свободна это время - тогда начинается передача. вкратце я изложил принцип стандарта CSMA/CD - ethernet-сети примерно по этому принципу работают. елси в сети нет устройств с одинаковыми физическими адресами - рано или поздно все смогут передать свою информацию.

возможно, tych и имел ввиду примерно это, но прямо не сказал по свойственной ему привычке отвечать либо ссылкой на свой сайт (очевидно, скоро появится сайт rs485network123.nаrоd.ru ) либо загадочной фразой...

[tych]

Дак уж разъясняли что полностью исключить колизеум нельзя. А он максималист похоже.

[Aheir]

Ну конечно сначала broadcast запрос -- получаю все номера, адресую. А потом чтоб скорость была максимальная никаких коллизий возникать не должно. Обратился по адресу -- получил ответ. Все остальные молчат

Ну дык блин, само собой, что после процедуры инициализации и считывания всех айди коллизий не будет. Речь идет о возможных конфликтах на этапе инициализации, если делать ее на тайм-шифте, вот об их "разруливании" и придется позаботиться особо. Потом - проьлем не будет.
Чем такой подход не устраивает?

[kj]

Вот насчет того что ведомый (который в данный момент передает) может слушать линию я не подумал. Очень хорошая идея. Насчет выдержек и всего остального это уже дело техники. Всем спасибо

[WildCat]

А объясните мне пожалуйста, как происходит инициализация кучи термометров на шине 1-wire?