Здравствуйте.
На работе дали задание разработать интерфейс сообщений между устройствами на основе протокола Modbus.
Суть такова. Есть некоторое количество измерительных приборов, соединённых по RS-485. Нужно сделать так, чтобы с одного прибора можно было управлять другим - устанавливать режимы, принимать архивы измерений и т.д. За основу предложено взять протокол modbus.
Уже месяц сижу и туплю.
Вопросы:
1. Можно ли сделать так, чтобы любое устройство могло взять на себя роль главного?
2. Каким образом вообще передавать информацию главному? Через регистры, что ли?
3. С чего вообще начинать?
Подскажите, пожалуйста, ткните носом во что-нибудь готовое, описание какое-нибудь.
Протокол зачитал, но там, такое ощущение, всё привязано к конкретным контроллерам.

Правильный протокол - на modbus.org
Если нужно менять мастера, то модбас не катит. Скорее ProfiBUS
Информацию в модбасе можно передавать через регистры, койлы и файлы.

Т.е. совсем не катит? Нельзя так сделать?

Ну, всегда можно что-то сделать. Но это будет ваш собственный велосипед, не имеющий ничего общего с протоколом MODBUS (кроме формата пакетов). Стандартом передача "мастерства" не предусмотрена.

ProfiBUS (ProfiBUS/DP по кр.мере) не мультимастер.
ЗЫ: А Модбас это и есть формат пакетов. Можно сделать пакет "передача мастера" плюс, на случай потерь, захват "мАстерства" по таймауту в зависимости от собственного адреса (ИД). В свое время интересовался мультимастерными сетями, некоторые решения были очень простыми.

цитирую педию:


Можно, но тогда это будет "стандарты нестандартные, системы бессистемные"

Тоже поставили задачу прикрутить Modbus.
В описании протокола сказано, что в начале и конце сообщения должен быть интервал тишины, когда же подчиненный может начинать отвечать? Т.е. Мастер делает паузу 3.5, затем передает пакет и снова делает паузу 3.5. Подчиненному когда начинать делать стартовую паузу, сразу после окончания передачи CRC мастером или после его завершающей паузы 3,5?

Наверное, главной проблемой станет борьба с коллизиями. В модбасе ведомые устройства молчат, как примерные ученики, пока не спросят.
Возможный вариант: гонять метку ведущего. Во всех устройствах выделить пару регистров. Первый - признак, что устройство хочет быть ведомым. Через некоторый интервал ведущий опрашивает все устройства. Если появились желающие, то пишет во второй регистр метку ведущего. Получил ответ - сам стал ведомым и тихо ждет своей очереди. Это уже было в TokenRing
Однако, может оказаться два ведущих или никого.

Другой вариант. Драйвер RS485 следит за линией и самостоятельно борется с ошибками. А Ethernet, особенно коаксильный вариант.

P.S. С PROFIBUS не знаком (не требовалось).

Упс. Profibus как раз.

По завершающей паузе некоторые слейвы определяют границу пакета. (не все ж считают CRC на лету). Пауза между пакетами должна быть не менее 3.5. По приему CRC слейв может сразу же приступить к формированию ответа, но слать ответ в линию он должен не ранее чем через 3.5 сивольного интервала.

modbus plus - multimaster :
http://prodcs.ru/files/ModPlusDesignManual.pdf

можно сделать временнОе мультиплексирование, например мастер делает опрос узлов с периодом 5 сек, слейв может давать запросы между запросами мастера, со смещением 2.5 сек после запроса мастера.

Довольно распространенное заблуждение насчет определения конца пакета путем подсчета CRC.
Стандарт однозначно определяет конец пакетов по таймауту (не менее 3,5 байтовых интервалов для скоростей ниже 19200 и 1,75 мсек для скоростей выше 19200).
Совсем не обязательно считать CRC на лету. Более того, обычно это даже вредно.
Ответ в линию начинается после приема запроса, таймаута (3,5), обработки пакета (подсчета CRC + обработки), и (в случае полудуплексной линии) дополнительного времени на переключение направления, обычно делается порядка нескольких мсек

3. Начинать нужно с детализации постановки задачи и выстраивания вашей системы на различных уровнях иерархии управления.
2. Начните с физического уровня. Определите, какое максимальное количество устройств может быть на линии. Какие объемы информации нужно передавать и с какой периодичностью. Тогда станет понятна необходимая скорость обмена и возможная частота опроса устройств.
1. Если за основу выбран протокол MODBUS, то я бы не советовал Вам делать систему со многими ведущими. На много проще, когда ведущий один. Желательно, что бы им было устройство с наибольшими собственными ресурсами -персональный компьютер (ПК), например.
0. На каждом уровне иерархии, ведущими могут быть различные устройства системы. Совсем не обязательно, чтобы ведущий был один и тот же на всех уровнях. Такое прямое, "лобовое" решение - не всегда самое лучшее. Например, на протокольном уровне ведущим может быть ПК, а на более высоком уровне - им может быть, к примеру, какой-нибудь выносной пульт управления. Хотя он будет подчиненным устройством с точки зрения MODBUS, но фактическое управление системой будет осуществляться с него. ПК будет периодически читать его по MODBUS, получая, таким способом, указания, что необходимо делать в данный момент. Далее, эти "указания" обрабатываются в ПК и преобразуются в последовательность протокольных команд для других подчиненных устройств... Подобным же образом можно реализовать и передачу функций ведущего устройства (высокоуровневого) другим устройствам или получить систему с многими ведущими. При этом, формально, протокол не будет нарушен, и коллизии между устройствами не будут возникать (по крайней мере на физическом уровне).

koyodza, @Ark, зачем нужно старую тему поднимать? Думаете, что топикстартер, создавший ее год назад и тогда же последний раз в ней отметившись, прочитает?

Sorry, не посмотрел на дату. Просто тема показалась интересной...