Как лучше организовать протокол (логический) для RS-485 Опции

[Diusha]

На главный блок должна стекаться инфа с нескольких периферийных.
Есть такие варианты:
1) Каждый периферийный посылает данные (по мере их готовности) и в теч. нек. времени ждет подтверждение от главного. Если подтверждения нет, посылает еще раз. Если случайно 2 периферийных пошлют одновременно, то контрольная сумма не совпадет -> не будет подтверждения -> повтор.
2) Главный постоянно периферийным шлет запросы. Если у периферийного данные готовы, то он посылает.

Вроде оба варианта имеют право на существование, но чего-то не нравятся. Может предложите получше варианты или есть решения, проверенные временем?

[SSerge]

Не мучайтесь, сделайте Модбас.
Заодно получите возможность подключать вместе с Вашими ещё кучу других устройств и опрашивать их не только своей программой, но и многими другими системами сбора данных.

[Diusha]

Линию в любом случае кто-то должен держать.

Зачем ее обязательно кому-то держать? (я не спорю, а просто спрашиваю )

Большая частота - это какая величина?

Пока только расплывчато… Чтобы на глаз задержка не была заметна. Думаю, миллисек 50 от готовности данных до их получения на центральном.

Чем не устраивает такой протокол?

Да вроде только тем, что линия будет трещать без умолку, тогда как могла бы быть занята только на время передачи нескольких байт раз в неск. секунд.
Честно говоря, не знаю даже, это плохо или нейтрально

а гарантированная доставка пакета от периферийного устройства необходима?

Да. Думаю это организовать с помощью добавления в пакет его номера. Интересно было бы посмотреть примеры, как делают умные люди.

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

Разруливается весьма легко: У каждого устройства свой период повторной передачи в случае неполучения подтверждения.

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

Логично! Не подумал об этом. Чего-то не нашел в ДШ на МАХ485 про допустимую нагрузку.

Не мучайтесь, сделайте Модбас.
Заодно получите возможность подключать вместе с Вашими ещё кучу других устройств и опрашивать их не только своей программой, но и многими другими системами сбора данных.

«Куча» не понадобится и опрос другими системами тоже. Так что подгонгять под определенный готовый стандарт и проверять, действительно ли оно соответствует, – как раз лишнее мучение. Но общие принципы модбаса стоит взять на вооружение.

[ASN]

Diusha
Держать желательно, чтобы не линия "болтала".
Были в практике неприятные истории, когда устройства постоянно "дёргались" обрабатывать запросы по UART, потому что линией никто не управлял и она "ловила" шумы.
При скорости 19200 время передачи одного байта около 0,5 мс.
Даже если сообщение состоит из 10 байт + время на включение/выключение опрос одного устройства займёт не более 5 мс.
Сколько у Вас устройств? Для 10, IMHO, времени достаточно.
Плюс к тому, чтобы на глаз задержка не была заметна для нескольких байт ограничение будет выступать, IMHO, не задержки передачи, а задержки отрисовки в ПЭВМ.
Если надо опрашивать много устройств, IMHO, лучше сделать концентраторы, которые собирают информацию с удалённых объектов и отсылают её в host.
На подобие дерева.
P.S. Я бы рекомендовал Modbus - лучше день потерять, потом за час долететь Просто, надёжно.

[Diusha]

Держать желательно, чтобы не линия "болтала".
Были в практике неприятные истории, когда устройства постоянно "дёргались" обрабатывать запросы по UART, потому что линией никто не управлял и она "ловила" шумы.

В любом случае если не повесить подтяжки, линия болтать будет: мастер послал запрос и переключился на прием. Пока слейв не ответил, все устройства слушают болтавню.
Или я что-то не понимаю?

чтобы на глаз задержка не была заметна для нескольких байт ограничение будет выступать, IMHO, не задержки передачи, а задержки отрисовки в ПЭВМ.

Ну я имел в виду задержку не передачи, а периода посылки запросов мастером, если период будет велик

Сообщение отредактировал Diusha - Feb 23 2010, 13:30

[ASN]

Diusha
А если длина линии (в смысле ёмкость) большая? Её "пробить" надо. Простыми резисторами в этом случае не обойдёшься.
Алгоритм работы простой:
- опрос состояний всех устройств (их два - длинный адрес при инициализации и короткий в рабочем цикле);
- ответ каждого устройства словосостоянием (4 байт обычно достаточно) (после получения запроса все slave отключают приём на фиксированное время - один выходил на передачу);
- при необходимости запрос дополнительных данных от выбранного устройства.
Про "отрисовку".
Кто является мастером? ПЭВМ? Работает под Win? Время реакции Win (со слов системного программиста) около 50 мс + всякие графические примочки.
На круг обычно выходит около 1 секунды. За это время можно переслать уйму данных.
Узким местом, как правило, оказывается "человеческий фактор" - оператор просто не успевает обрабатывать такой поток информации.
IMHO, Вам предоставили достаточно информации, чтобы принять правильное решение

[Diusha]

IMHO, Вам предоставили достаточно информации, чтобы принять правильное решение

Да! Информации достаточно. Склонился в сторону 2-го варианта, на самом деле уже давно, специально не говорил
Самый веский аргумент, ИМХО:

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

Всем большое спасибо!

[galjoen]

Если так боитесь коллизий и скорость передачи у вас небольшая - включите драйвера RS-485 так, чтобы они только 0 передавали, а 1 за счёт резисторных растяжек формировалась.
По крайней мере гляньте на автомобильный стандарт J1708. Там драйвера RS-485 именно так включены. К плюсам такого решения ещё и возможность мультимастерности и соединения сети звездой. А расплата за это всего одна - скорость 9600. Но работает, в непростых автомобильных условиях, очень стабильно. Если скорость устроит, то ИМХО для вас это лучший вариант.