Phuntik 0 16 октября, 2008 Опубликовано 16 октября, 2008 · Жалоба Здравствуйте. На работе дали задание разработать интерфейс сообщений между устройствами на основе протокола Modbus. Суть такова. Есть некоторое количество измерительных приборов, соединённых по RS-485. Нужно сделать так, чтобы с одного прибора можно было управлять другим - устанавливать режимы, принимать архивы измерений и т.д. За основу предложено взять протокол modbus. Уже месяц сижу и туплю. Вопросы: 1. Можно ли сделать так, чтобы любое устройство могло взять на себя роль главного? 2. Каким образом вообще передавать информацию главному? Через регистры, что ли? 3. С чего вообще начинать? Подскажите, пожалуйста, ткните носом во что-нибудь готовое, описание какое-нибудь. Протокол зачитал, но там, такое ощущение, всё привязано к конкретным контроллерам. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
MrYuran 23 16 октября, 2008 Опубликовано 16 октября, 2008 · Жалоба Правильный протокол - на modbus.org Если нужно менять мастера, то модбас не катит. Скорее ProfiBUS Информацию в модбасе можно передавать через регистры, койлы и файлы. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Phuntik 0 16 октября, 2008 Опубликовано 16 октября, 2008 · Жалоба Если нужно менять мастера, то модбас не катит. Скорее ProfiBUS Т.е. совсем не катит? Нельзя так сделать? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
MrYuran 23 16 октября, 2008 Опубликовано 16 октября, 2008 · Жалоба Т.е. совсем не катит? Нельзя так сделать? Ну, всегда можно что-то сделать. Но это будет ваш собственный велосипед, не имеющий ничего общего с протоколом MODBUS (кроме формата пакетов). Стандартом передача "мастерства" не предусмотрена. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Andy Great 0 17 октября, 2008 Опубликовано 17 октября, 2008 · Жалоба Если нужно менять мастера, то модбас не катит. Скорее ProfiBUS ProfiBUS (ProfiBUS/DP по кр.мере) не мультимастер. ЗЫ: А Модбас это и есть формат пакетов. Можно сделать пакет "передача мастера" плюс, на случай потерь, захват "мАстерства" по таймауту в зависимости от собственного адреса (ИД). В свое время интересовался мультимастерными сетями, некоторые решения были очень простыми. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
MrYuran 23 17 октября, 2008 Опубликовано 17 октября, 2008 · Жалоба ProfiBUS (ProfiBUS/DP по кр.мере) не мультимастер. цитирую педию: PROFIBUS использует обмен данными между ведущим и ведомыми устройствами (протоколы DP и PA) или между несколькими ведущими устройствами (протоколы FDL и FMS). Требования пользователей к получению открытой, независимой от производителя системе связи, базируется на использовании стандартных протоколов PROFIBUS. Можно сделать пакет "передача мастера" плюс, на случай потерь, захват "мАстерства" по таймауту в зависимости от собственного адреса (ИД). Можно, но тогда это будет "стандарты нестандартные, системы бессистемные" Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
bovolk 0 16 ноября, 2008 Опубликовано 16 ноября, 2008 · Жалоба Тоже поставили задачу прикрутить Modbus. В описании протокола сказано, что в начале и конце сообщения должен быть интервал тишины, когда же подчиненный может начинать отвечать? Т.е. Мастер делает паузу 3.5, затем передает пакет и снова делает паузу 3.5. Подчиненному когда начинать делать стартовую паузу, сразу после окончания передачи CRC мастером или после его завершающей паузы 3,5? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ucMike 0 3 декабря, 2008 Опубликовано 3 декабря, 2008 · Жалоба Наверное, главной проблемой станет борьба с коллизиями. В модбасе ведомые устройства молчат, как примерные ученики, пока не спросят. Возможный вариант: гонять метку ведущего. Во всех устройствах выделить пару регистров. Первый - признак, что устройство хочет быть ведомым. Через некоторый интервал ведущий опрашивает все устройства. Если появились желающие, то пишет во второй регистр метку ведущего. Получил ответ - сам стал ведомым и тихо ждет своей очереди. Это уже было в TokenRing Однако, может оказаться два ведущих или никого. Другой вариант. Драйвер RS485 следит за линией и самостоятельно борется с ошибками. А Ethernet, особенно коаксильный вариант. P.S. С PROFIBUS не знаком (не требовалось). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ucMike 0 4 декабря, 2008 Опубликовано 4 декабря, 2008 · Жалоба P.S. С PROFIBUS не знаком (не требовалось). Упс. Profibus как раз. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
defunct 0 1 января, 2009 Опубликовано 1 января, 2009 · Жалоба Подчиненному когда начинать делать стартовую паузу, сразу после окончания передачи CRC мастером или после его завершающей паузы 3,5? По завершающей паузе некоторые слейвы определяют границу пакета. (не все ж считают CRC на лету). Пауза между пакетами должна быть не менее 3.5. По приему CRC слейв может сразу же приступить к формированию ответа, но слать ответ в линию он должен не ранее чем через 3.5 сивольного интервала. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ukpyr 0 1 января, 2009 Опубликовано 1 января, 2009 · Жалоба modbus plus - multimaster : http://prodcs.ru/files/ModPlusDesignManual.pdf можно сделать временнОе мультиплексирование, например мастер делает опрос узлов с периодом 5 сек, слейв может давать запросы между запросами мастера, со смещением 2.5 сек после запроса мастера. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
koyodza 0 17 октября, 2009 Опубликовано 17 октября, 2009 · Жалоба По завершающей паузе некоторые слейвы определяют границу пакета. (не все ж считают CRC на лету). Пауза между пакетами должна быть не менее 3.5. По приему CRC слейв может сразу же приступить к формированию ответа, но слать ответ в линию он должен не ранее чем через 3.5 сивольного интервала. Довольно распространенное заблуждение насчет определения конца пакета путем подсчета CRC. Стандарт однозначно определяет конец пакетов по таймауту (не менее 3,5 байтовых интервалов для скоростей ниже 19200 и 1,75 мсек для скоростей выше 19200). Совсем не обязательно считать CRC на лету. Более того, обычно это даже вредно. Ответ в линию начинается после приема запроса, таймаута (3,5), обработки пакета (подсчета CRC + обработки), и (в случае полудуплексной линии) дополнительного времени на переключение направления, обычно делается порядка нескольких мсек Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Гость @Ark 17 октября, 2009 Опубликовано 17 октября, 2009 · Жалоба Вопросы: 1. Можно ли сделать так, чтобы любое устройство могло взять на себя роль главного? 2. Каким образом вообще передавать информацию главному? Через регистры, что ли? 3. С чего вообще начинать? 3. Начинать нужно с детализации постановки задачи и выстраивания вашей системы на различных уровнях иерархии управления. 2. Начните с физического уровня. Определите, какое максимальное количество устройств может быть на линии. Какие объемы информации нужно передавать и с какой периодичностью. Тогда станет понятна необходимая скорость обмена и возможная частота опроса устройств. 1. Если за основу выбран протокол MODBUS, то я бы не советовал Вам делать систему со многими ведущими. На много проще, когда ведущий один. Желательно, что бы им было устройство с наибольшими собственными ресурсами -персональный компьютер (ПК), например. 0. На каждом уровне иерархии, ведущими могут быть различные устройства системы. Совсем не обязательно, чтобы ведущий был один и тот же на всех уровнях. Такое прямое, "лобовое" решение - не всегда самое лучшее. Например, на протокольном уровне ведущим может быть ПК, а на более высоком уровне - им может быть, к примеру, какой-нибудь выносной пульт управления. Хотя он будет подчиненным устройством с точки зрения MODBUS, но фактическое управление системой будет осуществляться с него. ПК будет периодически читать его по MODBUS, получая, таким способом, указания, что необходимо делать в данный момент. Далее, эти "указания" обрабатываются в ПК и преобразуются в последовательность протокольных команд для других подчиненных устройств... Подобным же образом можно реализовать и передачу функций ведущего устройства (высокоуровневого) другим устройствам или получить систему с многими ведущими. При этом, формально, протокол не будет нарушен, и коллизии между устройствами не будут возникать (по крайней мере на физическом уровне). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
rezident 0 17 октября, 2009 Опубликовано 17 октября, 2009 · Жалоба koyodza, @Ark, зачем нужно старую тему поднимать? Думаете, что топикстартер, создавший ее год назад и тогда же последний раз в ней отметившись, прочитает? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Гость @Ark 17 октября, 2009 Опубликовано 17 октября, 2009 · Жалоба Sorry, не посмотрел на дату. :) Просто тема показалась интересной... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться