[Diusha 0]

На главный блок должна стекаться инфа с нескольких периферийных.

Есть такие варианты:

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

2) Главный постоянно периферийным шлет запросы. Если у периферийного данные готовы, то он посылает.

 

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

[ASN 0]

Diusha

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

[Сергей Борщ 143]

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

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

[rezident 0]

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

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

[Diusha 0]

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

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

Если случайно 2 периферийных пошлют одновременно, то контрольная сумма не совпадет -> не будет подтверждения -> повтор.

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

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

 

Если вам нужен именно первый вариант, то переходите на CAN.

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

 

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

[ASN 0]

Diusha

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

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

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

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

[Andron_ 0]

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

[Сергей Борщ 143]

Дело в том, что передачи относительно редки => вероятность коллизии невысока. Коллизии разрулятся с помощью контрольной суммы.

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

[rezident 0]

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

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

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

"Быстро" это не технический термин. Укажите скорость обмена, количество передаваемой информации, количество узлов и максимально допустимое время отклика.

[SSerge 6]

Не мучайтесь, сделайте Модбас.

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

[Don2 0]

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

 

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

[stells 12]

можете применить общий запрос от ведущего в ответ на который ведомые выдают ответ с разносом во времени

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

[Diusha 0]

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

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

 

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

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

 

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

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

Честно говоря, не знаю даже, это плохо или нейтрально

 

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

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

 

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

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

 

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

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

 

Не мучайтесь, сделайте Модбас.

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

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

[ASN 0]

Diusha

Держать желательно, чтобы не линия "болтала".

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

При скорости 19200 время передачи одного байта около 0,5 мс.

Даже если сообщение состоит из 10 байт + время на включение/выключение опрос одного устройства займёт не более 5 мс.

Сколько у Вас устройств? Для 10, IMHO, времени достаточно.

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

Если надо опрашивать много устройств, IMHO, лучше сделать концентраторы, которые собирают информацию с удалённых объектов и отсылают её в host.

На подобие дерева.

P.S. Я бы рекомендовал Modbus - лучше день потерять, потом за час долететь :) Просто, надёжно.

[Diusha 0]

Держать желательно, чтобы не линия "болтала".

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

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

Или я что-то не понимаю?

 

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

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

Изменено 23 февраля, 2010 пользователем Diusha