Как лучше организовать протокол (логический) для 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