На главный блок должна стекаться инфа с нескольких периферийных.
Есть такие варианты:
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 - лучше день потерять, потом за час долететь Просто, надёжно.

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


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

Хе-хе. А как же это согласуется с вашим требованием минимальной задержки передачи любого сообщения?

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

А сколько устройств на линии по максиму? Может и проблемы нет…

Вам надо определять исправность удалённых устройств? При опросе это получается почти даром.

Устройств немного - от 2 до 10 (периферийных). Надо определять наличие их.
Проблемы в смысле "беда", конечно, нет. Есть проблема в смысле "задача", для решения которой надо взвесить все ЗА и ПРОТИВ, а для этого услышать побольше мнений.

тут вот так вот на пальцах можно бесконечно долго рассуждать...

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

а то можт у вас у одного устройства пакет 25кБ, а у другого 10 байт...

Ну, так и сравнивайте, а затем выбирайте. Оба варианта реализуемы. Всё можно посчитать. Но все требования знаете только Вы.

Первый вариант (все - мастера) значительно сложнее программно.
Второй проще.
Если у Вас максимум 10 устройств и время доставки должно быть 50 мс, значит на каждый опрос не более 5 мс. При скорости 19200 можно отправить ответ около 8 байт. Хватит? Сколько надо?
Если надо 1000 байт, то при одновременном возникновении желания поговорить с главным, за 50 мс надо передать 10000 байт. Т.е. скорость должна быть более 0.2 Мбит/с. А с коллизиями и того больше…

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

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

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

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

Назовите мне модель драйвера RS-485, для которого коллизия является нештатной и который от этого крякнется. Я эту фирму буду обходить стороной.

Как правило в даташите пишут нечто подобное (это из ST485): "Current limiting and thermal shutdown for driver overload protection".

так что производители гарантируют.

У Sipex в даташитах специфицирован только ток КЗ по выходу и макс. рассеиваимая мощность корпуса. Про коллизию не нашел ни в одном даташите. Есть защита от КЗ, но это как бы совсем не коллизия.
Обходите.

Согласен, многие гарантируют.
И тем не менее: вы считаете, что доводить систему до срабатывания защиты - это нормально? Или вы считаете, что возможные периодические временные отказы связи из-за thermal shutdown - это штатный режим работы системы?

А не знаете, нет ли микосхемки, совместимой по выводам с МАХ485, только с открытым коллектором?


Из портянки на МАХ485:
"Drivers are short-circuit current limited and are protected against excessive power dissipation by thermal shutdown circuit"
Провел эксперимент: замкнул А и В. Секунд через 7 микросхема (в ДИПе) нагрелась градусов до 45, дальше температура не росла; thermal shutdown не было; ток 100 мА.
Не лучший вариант...

Из той же портянки:
"The receiver input has a fail-safe feature that guarantees a logic-high output if the input is open circuit."
Я правильно понял, имеется в виду, что если линия болтается в воздухе, то "фича гарантирует", что на выходе приемника болтанки не будет? Но тогда непонятно, как фича догадается, что это наводки, а не сигнал?

1. про Sipex: Спасибо за информацию, это для меня новость. Такие микросхемы просто нельзя применять. Так как в случае замыкания линии, что вполне вероятно и периодически случается в полевых условиях, система выйдет из строя.
2. Коллизии и КЗ: Это разные уровни модели Если спуститься на физический уровень, то для RS-485 коллизией является в том числе и КЗ, так как передача одновременно нуля и единицы в линию двумя драйверами приводит к замыканию линии через выходные каскады этих драйверов (источники тока).
3. Насчет периодического термального шутдауна: это последняя штатная ступень защиты, ничего нештатного тут нет. Конечно, желательно если будут предварительные ступени защиты (детектирование коллизий до шутдауна из-за перегрева), но они не необходимы. Совершенно не согласен с тем, что "Производитель не гарантирует, что драйвера выдержат сколь-нибудь долгую эксплуатацию в таком режиме. Хотите иметь неприятности из-за отказов - делайте."
Кстати, до такого перегрева довести драйвера простейшими короткими коллизиями вряд ли получится, тут считать нужно.

2Ruslan1

Т.о. вы считаете, что система может строиться из расчета, что коллизии являются нормальным режимом логики, а драйверы их выдержат?

Как не лучший? просто недогрели его, никакого шутдауна и не произошло. Штатная работа, генератор тока выдает свои 100 мА, нагрев и рассеивание тепла уравновесились при температуре корпуса 45 градусов. Хотите шутдауна- погрейте феном или паяльником.


Не надо ни о чем догадываться. Представьте себе резисторы большого номинала (точнее генераторы маленького тока), которые тянут линию в неактивное состояние. То есть вместо болтанки на входах будет неактивный уровень. Любому сигналу эти резисторы незаметны.



Ага, считаю. Да, выдержат. Но с точки зрения программинга упаси Боже Вас строить системы с коллизиями! Дело это жутко неблагодарное и статистическое. Такое ноу-хау замутите, что потом вернуться и посмотреть страшно будет.
если оно таки надо, нужно сразу CAN какой-нить брать и приоритеты расставлять.

Нда...
Как говорится, мы трудностей не боимся.
Не для того мы их себе создаём!

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

Это стандартный драйвер CAN. Насчёт совместимости по ногам - смотрите сами. Но так-то ничего не мешает использовать его вместо драйверов RS-485. Всё будет работать абсолютно так-же, только терминаторы в этом случае обязательны. Ещё можно приёмником USART слушать линию во время передачи, и если принятое будет отличаться от переданного - коллизия. Собственно всё так же, как при включении драйверов RS-485 по стандарту J1708 - CAN оттуда и произошёл. Кстати, не удивлюсь, если и модбас оттуда - и протокол и времянки то очень похожи. Только модбас не мультимастерный.

А вообще, закладывать модбас в новую разработку, ИМХО это не есть гуд.

чем не угодил модбас?
для простых устройств самое то, любой студент напишет его на любом контроллере.


Терминаторы да, обязательны. Нетерминированый отрезок кабеля в 50м намертво убивал передачу на 19200.

Вот и тянется эта фигня год за годом...
Потом, ради совместимости, приходится такую же фигню делать. Ну никаких преимуществ у модбаса нет, кроме простоты реализации. Да и это преимущество весьма относительно.

Кстати можно специальные микросхемы для J1708 использовать. MAX3444, например. Только дорогие они, но зато защищены всеми возможными способами (автоэлектроника). Они по ногам со стандартным драйвером RS-485 совместимы, только вход DE у них инверсный. Подключил туда провод вместо (можно и параллельно) DI и всё. А переключатель направления передачи в этом случае не нужен.

Дык, тогда о чем "штатном" идет речь? Нет сомнения, что с драверами ничего не случится, если производитель пишет... тут вопрос с точки зрения системы.

Зато внешний резистор 270 кОм (в обратную сторону) превращает неактивный уровень в болтанку, а 220 к дает устойчивый активный уровень - проверено


Абсолютно не пугает с точки зрения программинга, ничего сложного.
Пугает физика: 100мА-ные помехи - не айс