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

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

Diusha
Второй способ используем достаточно давно. Работает устойчиво.

А как он узнает, что в этот момент канал свободен и он своей передачей никому не помешает?

Второй вариант типовой: мастер, который опрашивает все слейвы по принципу запрос-ответ. Первый весьма замороченный, т.к. требует постоянной прослушки линии всеми устройствами сети и передачи маркеров по которым устройства имеют право занять линию для передачи. Основная сложность в том, что RS485 не имеет штатных аппаратных средств для детектирования и "разруливания" коллизий. Если вам нужен именно первый вариант, то переходите на CAN.

Дело в том, что передачи относительно редки => вероятность коллизии невысока. Коллизии разрулятся с помощью контрольной суммы. Прослушивать ничего не надо.
2-й вариант смущает тем, что линию придется держать занятой на несколько порядков бóльшее время (лишние помехи), т.к. главный должен получить данные быстро => запросы придется слать с большой частотой.


САN - в следующий раз, сейчас железо сделано под 485

Какие будут советы в свете моих уточнений? Может есть еще какой-нибудь 3-й вариант?

Diusha
Линию в любом случае кто-то должен держать.
Большая частота - это какая величина?
Мастер опрашивает состояния устройств достаточно быстро, и если есть данные - осуществляет обмен с устройством.
Чем не устраивает такой протокол?

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

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

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

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

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

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

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


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


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


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


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


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


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

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

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


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

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