adnega 11 1 июля, 2010 Опубликовано 1 июля, 2010 · Жалоба Уж если RS-485, то могу посоветовать две фишечки: 1. Использовать схему приоритетного опроса. Реализуется не сложно,принцип такой: - у каждого узла на шине есть приоритет. - мастер за один цикл опрашивает все узлы с наивысшим приоритетом и одно устройство с приоритетом на единицу ниже (окно). От цикла к циклу в окно последовательно попадают все устройства с приоритетом на единицу ниже и одно на две единицы ниже. Далее рекурсивно. Пример, A, B - наивысшиq приоритет, C, D - чуть ниже, E - низший приоритет. Опрос будет выглядеть так: A B C A B D A B E и т.д. Если какой-то узел не ответил N раз - считаем его потерявшим связь с шиной и устанавливаем низший приоритет. При восстановлении связи с этим узлом - восстанавливаем исходные приоритет. Плюсы: гарантированный период опроса (ограничен сверху), минимизация простоев на шине. Минусы: пока не придумал) 2. После запроса мастера к конкретному слейву, тот отвечает на запрос мастеру и может продолжать занимать шину. Скажем, послать команду другому слейву, а затем освободить шину. Псевдомультимастер ) 3. Недавно всплывала задачка автоматического поиска устройств на шине RS-485 (охранно-пожарная сигнализация с нестабильно конфигурацией - например, поезд с перецепкой вагонов). Готовые контроллеры имеют 24 битный адрес (8 под тип устройства; 16 под идентификатор, прошиваемый на заводе) - тупой перебор займет мнооого времени (скорость 9600, минимальный пакет слейву 7 байт + таймаут неответа), или я не правильно считаю? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
defunct 0 1 июля, 2010 Опубликовано 1 июля, 2010 · Жалоба Уж если RS-485, то могу посоветовать две фишечки: Раз уже пошли советы по теме :) Могу тоже поделиться hint'ом: Если использовать хороший помехоустойчивый протокол и не требовательный к таймаутам между пакетами, например модбас over hdlc. Тогда в одной сети можно размещать устройства с разными скоростями обмена. Устройства с ИК портом на 2400-9600, остальные на 115200, а там где много данных например на 1Mbps. В этом случае у мастера появляется возможность адресовать устройства не только адресным байтом, но и признаком скорости. Например в системе может быть 3 устройства с одинаковым адресом "1", но работающих на разных скоростях. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
aaarrr 64 1 июля, 2010 Опубликовано 1 июля, 2010 · Жалоба Ну а такие же требования как и для автомобиля могут появиться только если "дом" это одно из трех... Вот только не надо переворачивать все с ног на голову: сами же писали, что CAN - это слишком дорого. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ILYAUL 0 1 июля, 2010 Опубликовано 1 июля, 2010 · Жалоба ...не только адресным байтом, но и признаком скорости. Например в системе может быть 3 устройства с одинаковым адресом "1", но работающих на разных скоростях. Может всё таки 2 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
defunct 0 1 июля, 2010 Опубликовано 1 июля, 2010 · Жалоба Вот только не надо переворачивать все с ног на голову: сами же писали, что CAN - это слишком дорого. А где переворот? требования к оборудованию которое будет эксплуатироваться в трейлере, или неотапливаемом сарае, или сырой да еще и движущейся избе как ни удивительно, гораздо более жесткие чем к оборудованию работающему в тепличных условиях теплой квартиры. Может всё таки 2 Сколько скоростей будет обслуживать мастер столько и устройств с одинаковым адресом. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
aaarrr 64 1 июля, 2010 Опубликовано 1 июля, 2010 · Жалоба А где переворот? требования к оборудованию которое будет эксплуатироваться в трейлере, или неотапливаемом сарае, или сырой да еще и движущейся избе как ни удивительно, гораздо более жесткие чем к оборудованию работающему в тепличных условиях теплой квартиры. Напомню, что до сих пор ваш основной аргумент против CAN был - дорогие контроллеры/дорогая автомобильная шина. Я не считаю, что квартиру можно набивать лапшой из проводов и дешевым барахлом, исходя из соображений, что там сухо, тепло и авось-либо пожар не случится (по нашей вине). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
=AK= 10 2 июля, 2010 Опубликовано 2 июля, 2010 · Жалоба Oтчего же, если хорошо позаботиться о мастере - постоить на надежном железе и софте Построить надежное устройство - само по себе задача не тривиальная. А написать для него надежный софт - задача просто сложная, занимает много времени (с доводкой - растягивается нa годы) и получается отнюдь не у всех. Поэтому использование CAN является более чем оправданным. И разбиение задачи на маленькие кусочки - тоже оправданно. Ведь с ростом сложности ненадежность софта увеличивается не линейно, а как-то типа в геометрической прогрессии. Так что много одинаковых не очень сложных узлов CSMA/CA получится надежнее, чем один сложный мастер. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ILYAUL 0 2 июля, 2010 Опубликовано 2 июля, 2010 · Жалоба признаком скорости Что Вы под этим понимаете Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
galjoen 0 2 июля, 2010 Опубликовано 2 июля, 2010 · Жалоба Напомню, что до сих пор ваш основной аргумент против CAN был - дорогие контроллеры/дорогая автомобильная шина. У меня софтовый CAN до 500 килобод живёт на ATmega48 за $1. Для выключателя/лампочки ничего больше и не надо. Неужели $2 ($1 контроллер + $1 драйвер) дорого? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
defunct 0 2 июля, 2010 Опубликовано 2 июля, 2010 · Жалоба Что Вы под этим понимаете Я уже выше все написал.. Врятли смогу что-нибудь добавить, разве только C-шный пример опроса всех блоков: for( speed = LOW_SPEED; speed <= HIGH_SPEED; speed++) { uart_SetBaudRate( speed ); for( addr = 1; addr <= MAX_ADDR; addr++) { query_slave( addr, ....); } } У меня софтовый CAN до 500 килобод живёт на ATmega48 за $1. Для выключателя/лампочки ничего больше и не надо. Неужели $2 ($1 контроллер + $1 драйвер) дорого? Это решение ненадежно, настолько же насколько и недорого. Софтовая реализация довольно сложного интерфейса это не просто потенциальный баг, а мина замедленного действия. Сочетание той же m48 с аппартным UART'ом и rs485 драйвером, будет куда проще и надежней, заметьте - по той же цене. Построить надежное устройство - само по себе задача не тривиальная. А написать для него надежный софт - задача просто сложная, занимает много времени Эта задача все равно много проще multimaster системы. Суммарно если сравнить две системы: - систему 1 мастер + тривиальные слейвы, - систему мультимастер где много устройств средней сложности. Первая будет проще. Я не считаю, что квартиру можно набивать лапшой из проводов и дешевым барахлом, исходя из соображений, что там сухо, тепло и авось-либо пожар не случится (по нашей вине). Набивать лапшой никто и не предлагает, богатство выбора дает уникальную возможность выбрать наиболее подходящий вариант. С моей точки зрения такой вариант - это RS485 + IR непосредственно включенный в сеть 485, что позволит не только избавиться от лапши в некоторых местах, но и от пары Кановских проводов тоже, заодно и от сложности железа и софта слейвов и всей системы. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
galjoen 0 2 июля, 2010 Опубликовано 2 июля, 2010 · Жалоба Это решение ненадежно, настолько же насколько и недорого. Софтовая реализация довольно сложного интерфейса это не просто потенциальный баг, а мина замедленного действия. Чем же это железная реализация надёжнее софтовой? На мой взгляд, как раз наоборот. И периодически вылавливаемые в CAN-овском железе баги это подтверждают. И не известно есть они там или нет. А в софтовой можно все ошибки выгрести - запись логов при работе достаточно сделать. Кстати, для софтового CAN-а можно и ATtiny2313 использовать - ещё дешевле. А для гарантии, при использовании с софтового CAN-а, можно использовать драйвер с ограничением времени доминанты и всё. Поэтому я и написал про его стоимость $1 . Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
syv 0 2 июля, 2010 Опубликовано 2 июля, 2010 · Жалоба То есть дублируем длину для того чтобы в запросе мастера можно было бы сделать ошибку, а слейв мог бы о ней доложить. Гениально. Не хуже, чем любая другая заумность из известных протоколов. По Вашему принудительная адресация поверх CAN в DeviceNet лучше? Мне тоже, но для этого стандарты должны быть современными. В противном случае приходится или уродовать и усложнять интерфейсы нового оборудования, вписывая его в реалии тридцатилетней давности, или "расширять" стандарт, тем самым от него все дальше уклоняясь :( Поймите правильно. Не надо лучше. Надо, чтобы всегда одинаково. Поэтому - никаких "современных" стандартов. И чем их меньше, тем лучше. А свой протокол - даже не смешно. Это будет никому ненужный мартышкин труд. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
aaarrr 64 2 июля, 2010 Опубликовано 2 июля, 2010 · Жалоба Не хуже, чем любая другая заумность из известных протоколов. Если бы заумность, а то ведь глупость откровенная. Поймите правильно. Не надо лучше. Надо, чтобы всегда одинаково. Так оно не получается одинаково, что признают использующие Modbus - свои типы данных, свои команды и т.д. А свой протокол - даже не смешно. Это будет никому ненужный мартышкин труд. Никому не нужный мартышкин труд будет реализовывать Modbus там, где он объективно не нужен. Лучше потратить пару часов на изобретение своего, с учетом своих потребностей, а не брать Modbus и "расширять" его потом. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
defunct 0 2 июля, 2010 Опубликовано 2 июля, 2010 · Жалоба И периодически вылавливаемые в CAN-овском железе баги это подтверждают. И не известно есть они там или нет. А в софтовой можно все ошибки выгрести - запись логов при работе достаточно сделать. Кстати, для софтового CAN-а можно и ATtiny2313 использовать - ещё дешевле. Сравните с: А в 485-м интерфейсе багов нет и логов никаких не надо! И ловить нечего... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
syv 0 2 июля, 2010 Опубликовано 2 июля, 2010 · Жалоба Если бы заумность, а то ведь глупость откровенная. А как Вам "засерание" шины совершенно излишней информацией, якобы увеличивающей целостность данных в том же Ethernet или Profibus? Тоже очевидная глупость... А про старые отработанные годами протоколы я бы осторожнее... Любую несуразность в них надо воспринимать практически, как устав РККА или ПУЭ. Наличие такой "глупости" говорит только о том, что кто-то здесь сломал себе шею... Так оно не получается одинаково, что признают использующие Modbus - свои типы данных, свои команды и т.д. Если сделать все по уставу, как в перечисленных мною девайсах, то все будет работать даже в условиях сильных электромагнитных помех, коими являются частотные преобразователи. И основная "сила" старых протоколов - их отработанность и "проверенность". Никому не нужный мартышкин труд будет реализовывать Modbus там, где он объективно не нужен. Лучше потратить пару часов на изобретение своего, с учетом своих потребностей, а не брать Modbus и "расширять" его потом. Смысла делать свое даже в данном случае не вижу. Лучше сделать то, что потом пригодится. Не нравится Modbus - делайте что-то иное - DeviceNet или CanOpen, к примеру. Потом хоть наработки останутся... А в промавтоматике, где находится основная часть денег, которые можно заработать, свой протокол - признак элементарного дилетантизма. Иными словами. В эту сферу со своими протоколами лучше вообще не соваться... Засмеют. Сравните с: А в 485-м интерфейсе багов нет и логов никаких не надо! И ловить нечего... Не скажите. Знаете, почему уважающие себя люди никогда не будут использовать нашу электронику в ответственных местах? Потому, что в нашем воплощении RS485 логи, таки, нужны и ловить есть чего. Даже простейший Modbus сообразно со стандартом сделать не можем... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться