[haker_fox 60]

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

[kt361 0]

Нельзя. Ибо выходит из строя мастер - вся сеть перестает работать. Это недопустимо.

Система может обойтись без какого-то члена, но всегда должна быть работоспособна.

[Edit2007 3]

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

Но CAN в данном варианте выглядит более предпочтительно.

[stells 9]

Нельзя. Ибо выходит из строя мастер - вся сеть перестает работать.

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

[flakman 0]

Позвольте добавить свой вопрос. Задача от части похожа на сабж от kt361, по этому прочитал весь топик и не стал создавать отдельный, да и назывался бы он точно также.

Нужно что-то вроде промежуточного варианта между мульти-мастер протоколом и традиционными. Сразу скажу что уйти от RS485 просто не могу - у меня готовое устройство с тем что есть, выбирать не из чего. Сеть может работать и с одним мастером, но особенность в том, что критично время реакции на запрос, счёт идёт на миллисекунды (сеть будет из устройств считывания RFID, всё сделать нужно за время, приемлемое для подноса человеком карты к считывателю). По этой причине хочется заменить опрос слэйвов на сигнализацию самими слэйвами о необходимости связи с мастером.

 

Есть такая идея. По сравнению с Modbus всё наоборот - мастер не клиент, а сервер. В тишине мастер не опрашивает слэйвов, а ждёт запроса на связь => ;) возникает проблема с коллизиями, которую попытаюсь объяснить как хочу обойти. Слэйвы в спокойном состоянии тоже слушают шину. Что-бы просигналить о необходимости связи, слэйв отсылает пакет определённого формата, включающий его собственный адрес. Мастер, если всё ок, в ответ отсылает пакет на широковещательный адрес, в котором содержится адрес запросившего слэйва. Данный пакет для инициатора связи означает что обмен разрешён, всеми остальными он должен распознаваться как "шина занята" (в пакете не их адрес), и нужно ждать широковещательного пакета означающего освобождение шины. Во избежании глюков можно периодически слать пакет "шина свободна" просто во время тишины. Это поможет и для распознавания вымершего матера. Но механизм поиска нового в моей задаче не стоит. Им в любом случае может быть только софт на ПК с совершенно другой логикой чем у остальных девайсов в сети.

 

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

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

 

На вскидку, в случае отсутствия коллизии, связь будет установлена за один запрос-ответ и самое главное - инициирована слэйвом, опрос не нужен. Правда рассматривал только логическую сторону вопроса. Физическую - кз передатчиков не рассматривал. Разработка внутренняя, не на продажу, и все конкретные девайсы добавляемые в сеть будут заранее известны с возможностью проверки наличия защиты драйверов RS485 на защиту от кз. Наверно это плохой тон конечно.

 

Возможно это велосипед какого-нибудь протокола вообще без фиксированного матера-сервера (прошу ткнуть носом :)), возможно это вообще не будет работать (прошу обсуждения). Изначально рассматривал Modbus, но там как раз традиционный вариант с опросом. Если описанное выше имеет место быть, не знаю - стоит писать с нуля или быстрее будет модифицировать какую-нибудь реализацию Modbus. Это потому-что на самом деле после установки связи, она может происходить точно так-же как в Modbus, что избавляет от написания реализации самого обмена данными.

[_Pasha 0]

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

Сташин Урусов Мологонцева

Это книжка такая по 51-м была в 19затёртом году.2ТС: Гуглим-с.

[=AK= 10]

Нужно что-то вроде промежуточного варианта между мульти-мастер протоколом и традиционными. Сразу скажу что уйти от RS485 просто не могу - у меня готовое устройство с тем что есть, выбирать не из чего. Сеть может работать и с одним мастером, но особенность в том, что критично время реакции на запрос, счёт идёт на миллисекунды

Похоже что мало кто знает, что помимо "традиционных" протоколов "master-slave", в которых есть какой-то мастер, есть протоколы "producer-consumer", в которых мастера нет в принципе.

 

В протоколах "producer-consumer" (к которым, в частности, относится CAN) передачу начинает любой "производитель информации", которому "есть что сказать". А принимает информацию не какое-то одно устройство, а все, кому эта информация нужна. В результате этого информация передается очень быстро даже при малых бодовых скоростях. Суммарный выигрыш по скорости при раздаче информации получается на один-два порядка, хоть людям неискушенным в это трудно поверить.

 

В обычных "master-slave" мастер должен:

- все время опрашивать другие узлы на предмет наличия новой информации

- если у одного из узлов появилось что-то новое, мастер должен прочитать инфу

- после этого мастер должен по очереди разослать инфу тем узлам, которым она нужна

 

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

 

Основной проблемой протоколов "producer-consumer" является обнаружение и "разруливание" столкновений (CSMA/CD). Очень хорошим вариантом является предотвращение столкновений (CSMA/CA), для реализации которой как правило используют передатчики с открытым коллектором или их эквиваленты. CAN использует эквивалент открытого коллектора, гибрид ОК и RS485.

[flakman 0]

Похоже что мало кто знает, что помимо "традиционных" протоколов "master-slave", в которых есть какой-то мастер, есть протоколы "producer-consumer", в которых мастера нет в принципе.

...

Основной проблемой протоколов "producer-consumer" является обнаружение и "разруливание" столкновений (CSMA/CD). Очень хорошим вариантом является предотвращение столкновений (CSMA/CA), для реализации которой как правило используют передатчики с открытым коллектором или их эквиваленты. CAN использует эквивалент открытого коллектора, гибрид ОК и RS485.

 

Спасибо за ответ, сейчас покопаем.

[Smen 1]

Тоже возникла похожая задача.

Сперва хотел реализовать именно "producer-consumer".

В принципе, даже, вроде, придумал как коллизии разруливать.

Однако возникло препятствие в виде компьютера с преобразователем USB-485 на FT232R, который сам не умеет определять занятость линии.

Т.е. это должен делать комп, который не является "реал-тайм".

Короче говоря, аппаратно проверять не получается, и надо всё реализовать на уровне команд протокола.

Кто может что-нибудь подсказать? Или, где в рассуждениях ошибся?

[=AK= 10]

Однако возникло препятствие в виде компьютера с преобразователем USB-485 на FT232R, который сам не умеет определять занятость линии.

 

А что, разве на FT232R свет клином сошелся? Возьмите любой микроконтроллер, у которого есть UART и USB, и сделайте на нем.

[Smen 1]

А что, разве на FT232R свет клином сошелся?

В данном случае, сошёлся, ибо не я его делаю.

 

[Fujitser 0]

Не взлетит. RS-485 не поддерживает режим с возможными коллизиями шины (когда передают несколько устройств одновременно).

 

Используйте CAN.

[ZASADA 0]

+1, переходите на CAN, мы везде где можно от RS-485 избавляемся. С CAN гораздо проще жить.

[Edit2007 3]

В данном случае, сошёлся, ибо не я его делаю.

В таком случае МК с 2-мя UART-ми. Один на FT232R - для "чистых данных", второй в линию - коллизии разруливать.

[dac 0]

имхо Ethernet полностью снимает проблемы коллизий. enc28j60 стоит недорого, есть PIC с набортным PHY. тоже недорого :) это если CAN не устраивает :)))