haker_fox 61 3 декабря, 2012 Опубликовано 3 декабря, 2012 · Жалоба А нельзя протокол переделать так, чтобы в сети был один мастер, без запроса которого ни одно устройство бы не отправляло данных?) Тогда все по умолчанию только слушают, а когда всем одновреммено пришел некий пакет, то только то устройство, чей адрес был в заголовке пакета, начинает передаать данные в ответ? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
kt361 0 4 декабря, 2012 Опубликовано 4 декабря, 2012 · Жалоба Нельзя. Ибо выходит из строя мастер - вся сеть перестает работать. Это недопустимо. Система может обойтись без какого-то члена, но всегда должна быть работоспособна. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Edit2007 3 4 декабря, 2012 Опубликовано 4 декабря, 2012 · Жалоба Если зациклициваться на RS, то можно передавать управление между контроллерами по кругу, а при потере активности на шине установить фиксированное, но разное для всех блоков, время захвата шины, или фиксированное время от последней передачи. Но CAN в данном варианте выглядит более предпочтительно. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
stells 12 4 декабря, 2012 Опубликовано 4 декабря, 2012 · Жалоба Нельзя. Ибо выходит из строя мастер - вся сеть перестает работать. Вы почитайте литературу, есть варианты передачи (перехвата) управления... например мастер постоянно кидает в сеть некоторый кадр, подтверждающий его работоспособность, если этого кадра нет в определенное время, то слейвы отсчитывают еще некоторый интервал (у каждого свой) и захватывают управление... таким образом мастером в сети становится тот, у которого этот интервал меньше Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
flakman 0 21 декабря, 2012 Опубликовано 21 декабря, 2012 · Жалоба Позвольте добавить свой вопрос. Задача от части похожа на сабж от kt361, по этому прочитал весь топик и не стал создавать отдельный, да и назывался бы он точно также. Нужно что-то вроде промежуточного варианта между мульти-мастер протоколом и традиционными. Сразу скажу что уйти от RS485 просто не могу - у меня готовое устройство с тем что есть, выбирать не из чего. Сеть может работать и с одним мастером, но особенность в том, что критично время реакции на запрос, счёт идёт на миллисекунды (сеть будет из устройств считывания RFID, всё сделать нужно за время, приемлемое для подноса человеком карты к считывателю). По этой причине хочется заменить опрос слэйвов на сигнализацию самими слэйвами о необходимости связи с мастером. Есть такая идея. По сравнению с Modbus всё наоборот - мастер не клиент, а сервер. В тишине мастер не опрашивает слэйвов, а ждёт запроса на связь => ;) возникает проблема с коллизиями, которую попытаюсь объяснить как хочу обойти. Слэйвы в спокойном состоянии тоже слушают шину. Что-бы просигналить о необходимости связи, слэйв отсылает пакет определённого формата, включающий его собственный адрес. Мастер, если всё ок, в ответ отсылает пакет на широковещательный адрес, в котором содержится адрес запросившего слэйва. Данный пакет для инициатора связи означает что обмен разрешён, всеми остальными он должен распознаваться как "шина занята" (в пакете не их адрес), и нужно ждать широковещательного пакета означающего освобождение шины. Во избежании глюков можно периодически слать пакет "шина свободна" просто во время тишины. Это поможет и для распознавания вымершего матера. Но механизм поиска нового в моей задаче не стоит. Им в любом случае может быть только софт на ПК с совершенно другой логикой чем у остальных девайсов в сети. Теперь если всё не ок. Если несколько слэйвов начинают передачу, то получившийся пакет мастер просто отбрасывает как не корректный пакет запроса на связь, в тишине он ждёт только его. Если при коллизии например модифицировался адрес запрашивающего, а формат пакета остался корректным, и мастер отправил широковещательный ответ, то обладатель этого случайного адреса просто не ответит, передача навернётся по таймауту, а мастер снова объявит о свободности шины. Настоящие же запросившие связь в случае не получения положительного ответа ждут объявления свободности шины, рандомят себе задержку и пробуют снова. Пакеты запросов связи могут слушать и все слэйвы, что-бы затыкаться сразу же, пока не получат подтверждения свободности шины. Это избавит от влезания "желающих" во время уже начавшейся попытки установить связь, и сильно снизит вероятность коллизий. На вскидку, в случае отсутствия коллизии, связь будет установлена за один запрос-ответ и самое главное - инициирована слэйвом, опрос не нужен. Правда рассматривал только логическую сторону вопроса. Физическую - кз передатчиков не рассматривал. Разработка внутренняя, не на продажу, и все конкретные девайсы добавляемые в сеть будут заранее известны с возможностью проверки наличия защиты драйверов RS485 на защиту от кз. Наверно это плохой тон конечно. Возможно это велосипед какого-нибудь протокола вообще без фиксированного матера-сервера (прошу ткнуть носом :)), возможно это вообще не будет работать (прошу обсуждения). Изначально рассматривал Modbus, но там как раз традиционный вариант с опросом. Если описанное выше имеет место быть, не знаю - стоит писать с нуля или быстрее будет модифицировать какую-нибудь реализацию Modbus. Это потому-что на самом деле после установки связи, она может происходить точно так-же как в Modbus, что избавляет от написания реализации самого обмена данными. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
_Pasha 0 21 декабря, 2012 Опубликовано 21 декабря, 2012 · Жалоба Вы почитайте литературу, есть варианты передачи (перехвата) управления... например мастер постоянно кидает в сеть некоторый кадр, подтверждающий его работоспособность, если этого кадра нет в определенное время, то слейвы отсчитывают еще некоторый интервал (у каждого свой) и захватывают управление... таким образом мастером в сети становится тот, у которого этот интервал меньше Сташин Урусов Мологонцева Это книжка такая по 51-м была в 19затёртом году.2ТС: Гуглим-с. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
=AK= 18 23 декабря, 2012 Опубликовано 23 декабря, 2012 · Жалоба Нужно что-то вроде промежуточного варианта между мульти-мастер протоколом и традиционными. Сразу скажу что уйти от RS485 просто не могу - у меня готовое устройство с тем что есть, выбирать не из чего. Сеть может работать и с одним мастером, но особенность в том, что критично время реакции на запрос, счёт идёт на миллисекунды Похоже что мало кто знает, что помимо "традиционных" протоколов "master-slave", в которых есть какой-то мастер, есть протоколы "producer-consumer", в которых мастера нет в принципе. В протоколах "producer-consumer" (к которым, в частности, относится CAN) передачу начинает любой "производитель информации", которому "есть что сказать". А принимает информацию не какое-то одно устройство, а все, кому эта информация нужна. В результате этого информация передается очень быстро даже при малых бодовых скоростях. Суммарный выигрыш по скорости при раздаче информации получается на один-два порядка, хоть людям неискушенным в это трудно поверить. В обычных "master-slave" мастер должен: - все время опрашивать другие узлы на предмет наличия новой информации - если у одного из узлов появилось что-то новое, мастер должен прочитать инфу - после этого мастер должен по очереди разослать инфу тем узлам, которым она нужна В "улучшенных" конфигурациях вместо одного мастера есть координатор, который опрашивает те узлы, которые способны быть мастером - не желают ли они "немножко порулить" интерфейсом? Если желают, то координатор на некоторое время дает им сеть во владение, а уж они сами "выковыривают" инфу из периферийных устройств. Понятно, что никаких преимуществ по времени по сравнению с предыдущим вариантом это не дает. Основной проблемой протоколов "producer-consumer" является обнаружение и "разруливание" столкновений (CSMA/CD). Очень хорошим вариантом является предотвращение столкновений (CSMA/CA), для реализации которой как правило используют передатчики с открытым коллектором или их эквиваленты. CAN использует эквивалент открытого коллектора, гибрид ОК и RS485. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
flakman 0 24 декабря, 2012 Опубликовано 24 декабря, 2012 · Жалоба Похоже что мало кто знает, что помимо "традиционных" протоколов "master-slave", в которых есть какой-то мастер, есть протоколы "producer-consumer", в которых мастера нет в принципе. ... Основной проблемой протоколов "producer-consumer" является обнаружение и "разруливание" столкновений (CSMA/CD). Очень хорошим вариантом является предотвращение столкновений (CSMA/CA), для реализации которой как правило используют передатчики с открытым коллектором или их эквиваленты. CAN использует эквивалент открытого коллектора, гибрид ОК и RS485. Спасибо за ответ, сейчас покопаем. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Smen 3 16 июля, 2013 Опубликовано 16 июля, 2013 · Жалоба Тоже возникла похожая задача. Сперва хотел реализовать именно "producer-consumer". В принципе, даже, вроде, придумал как коллизии разруливать. Однако возникло препятствие в виде компьютера с преобразователем USB-485 на FT232R, который сам не умеет определять занятость линии. Т.е. это должен делать комп, который не является "реал-тайм". Короче говоря, аппаратно проверять не получается, и надо всё реализовать на уровне команд протокола. Кто может что-нибудь подсказать? Или, где в рассуждениях ошибся? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
=AK= 18 16 июля, 2013 Опубликовано 16 июля, 2013 · Жалоба Однако возникло препятствие в виде компьютера с преобразователем USB-485 на FT232R, который сам не умеет определять занятость линии. А что, разве на FT232R свет клином сошелся? Возьмите любой микроконтроллер, у которого есть UART и USB, и сделайте на нем. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Smen 3 16 июля, 2013 Опубликовано 16 июля, 2013 · Жалоба А что, разве на FT232R свет клином сошелся?В данном случае, сошёлся, ибо не я его делаю. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Fujitser 0 16 июля, 2013 Опубликовано 16 июля, 2013 · Жалоба Не взлетит. RS-485 не поддерживает режим с возможными коллизиями шины (когда передают несколько устройств одновременно). Используйте CAN. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ZASADA 0 16 июля, 2013 Опубликовано 16 июля, 2013 · Жалоба +1, переходите на CAN, мы везде где можно от RS-485 избавляемся. С CAN гораздо проще жить. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Edit2007 3 17 июля, 2013 Опубликовано 17 июля, 2013 · Жалоба В данном случае, сошёлся, ибо не я его делаю. В таком случае МК с 2-мя UART-ми. Один на FT232R - для "чистых данных", второй в линию - коллизии разруливать. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
dac 0 17 июля, 2013 Опубликовано 17 июля, 2013 · Жалоба имхо Ethernet полностью снимает проблемы коллизий. enc28j60 стоит недорого, есть PIC с набортным PHY. тоже недорого :) это если CAN не устраивает :))) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться