Алексей Васильевич 0 13 января, 2020 Опубликовано 13 января, 2020 · Жалоба 22 минуты назад, jcxz сказал: RS-485 был и нормально работает. В моем случае он не может гарантировать доставку информации на сотни устройств через DMA, потеря любой одной доставки критично для бизнеса. Так как один пропавший байт ломает всю систему и приходится программно анализировать что именно пропало, заново отправлять пакеты. 99,9% это пустой опрос устройств на наличие ответа , и соответственно 99,9% помех в случае CAN не будет. 48 минут назад, jcxz сказал: В CAN нет подтверждения доставки, есть подтверждение, что кадр был увиден хотя бы одним узлом Был уверен что CAN гарантированно доставляет. Как правильно организовать доставку в САN? В любом случае у меня получается "мультимастер" и нет необходимости в опросе устройств. Вторая проблема низкая скорость ответа при 57600 на 100 устройств - это более 1 сек. поэтому создать с одним мастером сеть на 100+ устройств не получится, приходится делать "узлы" по 60 устройств с отдельными мастерами. Третья проблема, писал о ней выше - это падение питания , если повесить 60 устройств 0.5мм2 кабель 50м на 20м будет прирост минуса +0.5v на 60м +1.5v, в зависимости от условий гарантировано работает только 20-30 устройств. Если расположить 2 блока питания на 20 и 40 ячейке все работает. С CAN насколько понимаю такие отклонения не опасны и линия может быть длиннее. 47 минут назад, AlexandrY сказал: но на нем реализован урезанный MODBUS, а если CAN В моем понимании обмен должен быть прост и реализован на аппаратном уровне , программа должна быть простой и понятной , а не тысячи строк кода которые мониторят насколько RS485 хорошо себя чувствует ( а в моем случае приходится вести лог на spiflash и потом анализировать "что это было") и все это для отправки десятки байт в секунду. Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 235 13 января, 2020 Опубликовано 13 января, 2020 · Жалоба 1 час назад, AlexandrY сказал: Морально устарел - означает что производители ( кроме вас конечно) предпочитают не использовать данную технологию. Ну с вами то уже давно всё ясно. Всё что не использует "облачные технологии" и прочие новомодные фишки - всё устарело. А медь в проводах - не устарела морально? А то может пора на что-то боле инновационное менять? Цитата Помехоустойчивость CAN-у дает аппаратная реализация ретрансмитов и арбитраж в контроллере CAN, т.е. на MAC уровне, а не на уровне физики. Расскажите нам как будут работать ретрансмиты CAN-а "на уровне физики", при том что сама линия будет разбита на множество физически отдельных сегментов. А также - как будет работать арбитраж CAN в пределах одного бита. При тех условиях. А мы посмеёмся Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
yes 7 13 января, 2020 Опубликовано 13 января, 2020 · Жалоба 47 minutes ago, Алексей Васильевич said: Был уверен что CAN гарантированно доставляет. Как правильно организовать доставку в САN? гарантировано за счет повторов на МАС уровне, который сделан в аппаратной части контроллера и не требует программного кода. то есть если все работает - то программа на одном конце положила сообщение в мэйлбокс, а на другом достала. но если с шиной что-то не так - то на ней будут непрерывные попытки передать, блокирующие остальные устройства (там есть достаточно хитрая самодиагностика, тоже сделанная внутри железа, которая отключает узел при достаточно большом количестве неудачных попыток) -------------- вроде как разумно делить на сегменты с некими бриджами (то есть устройствами с двумя CAN портами "нисходящим" и "восходящим" или как это правильно назвать?) - как я понял логически структура такая, что есть некий мастер, который управляет всей шиной и самопроизвольно передачи от "слэйвов" нету - тогда логика работы этих "бриджей" вообще прозрачная Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
_pv 71 13 января, 2020 Опубликовано 13 января, 2020 · Жалоба 34 minutes ago, Алексей Васильевич said: В моем случае он не может гарантировать доставку информации на сотни устройств через DMA. а каким образом это гарантирует CAN? 36 minutes ago, Алексей Васильевич said: В любом случае у меня получается "мультимастер" и нет необходимости в опросе устройств. RS485 запрещает "мультимастер"? Единственное отличие CAN это детектирование коллизий и контроль доступа к среде на физическом уровне, за что придётся заплатить скоростью в такой большой сети. В отличии от 485, где есть возможность "синхронизацию" и контроль доступа к среде вынести на уровни выше и скорость тем самым не ограничивать. То есть CAN с длиной сегмента 2км изначально ограничен скоростью до десятка кБит сразу на физическом уровне, а вот RS458 можно запустить на те же 2км на 1мбит с правильными драйверами и линией. Там единственное ограничение (впрочем как и для CAN) будет на ~200 устройств на линии между репитерами так как они собой просто линию нагрузят больше чем передатчик выдать может. 45 minutes ago, Алексей Васильевич said: Вторая проблема низкая скорость ответа при 57600 на 100 устройств - это более 1 сек. поэтому создать с одним мастером сеть на 100+ устройств не получится, приходится делать "узлы" по 60 устройств с отдельными мастерами. каждое устройство отвечает более чем 57 байтами? Доставка питания вообще отдельный вопрос и к физическому уровню отношения не имеет. С такой длиной сети устройства всё равно должны быть развязаны. и сколько там упадёт по дороге - преобразователю питания в конечных устройствах должно быть без разницы. Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 235 13 января, 2020 Опубликовано 13 января, 2020 · Жалоба 1 час назад, Алексей Васильевич сказал: В моем случае он не может гарантировать доставку информации на сотни устройств через DMA, потеря любой одной доставки критично для бизнеса. Так как один пропавший байт ломает всю систему и приходится программно анализировать что именно пропало, заново отправлять пакеты. 99,9% это пустой опрос устройств на наличие ответа , и соответственно 99,9% помех в случае CAN не будет. Как я уже сказал выше: Это говорит только о плохой организации кода на уровне драйвера. Особенно если "пропадают байты". Протокол должен быть кадр-ориентированным и байты тут не при чём. Весь кадр должен проверяться на корректность. Если байты пропадают из кадра - тут однозначно только одно: надо корректировать код драйвера. DMA вообще непонятно с какого боку тут приплетён. Много лет разрабатывал устройства со связью через RS-485. Десятки (а может уже сотни) тысяч их сейчас работают у заказчиков. Ничего не пропадает. Цитата Был уверен что CAN гарантированно доставляет. Как правильно организовать доставку в САN? Если нужно подтверждение доставки - только делать отдельное программное подтверждение. CAN генерит автоповтор по неполучению ACK. ACK на длинной линии может дать любой CAN-узел, не обязательно тот, куда кадр адресован. Так что ACK этот в вашем случае - мёртвому припарка. А так как всё равно нужно программное подтверждение доставки, то тогда нет никакого плюса от встроенного механизма CAN. И тот оверхед по размеру передачи, который из-за этого возникает - только минус. Цитата Вторая проблема низкая скорость ответа при 57600 на 100 устройств - это более 1 сек. поэтому создать с одним мастером сеть на 100+ устройств не получится, приходится делать "узлы" по 60 устройств с отдельными мастерами. Если у Вас на RS-485 не работало выше 57600, почему думаете, что будет работать на CAN? Он же не телепортировать сигналы будет, а через те же самые провода и передавать. Если думаете, что физический уровень у CAN лучше для вашего случая, так просто поставьте на UART драйвер физики CAN и получите ту же среду передачи с емкостями и токами, как и у CAN. В одном нашем текущем проекте так и сделано. Скорость = мегабод, хотя дальности конечно не такие как у Вас. Цитата С CAN насколько понимаю такие отклонения не опасны и линия может быть длиннее. Опять - же: UART с CAN-физикой и фреймингом как у RS-485 - будет работать точно так же. 2 минуты назад, _pv сказал: Единственное отличие CAN это детектирование коллизий и контроль доступа к среде на физическом уровне, за что придётся заплатить скоростью в такой большой сети. В отличии от 485, где есть возможность "синхронизацию" и контроль доступа к среде вынести на уровни выше и скорость тем самым не ограничивать. То есть CAN с длиной сегмента 2км изначально ограничен скоростью до десятка кБит сразу на физическом уровне, а вот RS458 можно запустить на те же 2км на 1мбит с правильными драйверами и линией. Там единственное ограничение (впрочем как и для CAN) будет на ~200 устройств на линии между репитерами так как они собой просто линию нагрузят больше чем передатчик выдать может. +++ Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
adnega 11 13 января, 2020 Опубликовано 13 января, 2020 · Жалоба "Крылья, ноги... главное хвост". Проблемы длинных линий обычно связаны с необходимостью согласования такой линии. Если теряются байты, то это не только из-за кривого драйвера, но и из-за отсутствия согласования линии. CAN в этом плане менее терпим ;) Это довольно неплохая конструкция: мастер на 60 слейвов, затем мастера в своей шине с одним супер-мастером. Мастера делают всю грязную работу по опросу узлов. Отвалившиеся узлы должны опрашиваться реже. Например, после каждого 10 опроса мы опрашиваем один раз один из "отвалившихся" узлов. Супер-мастер выдает высокоуровневые задания мастерам и получает от них высокоуровневые ответы подчиненных узлов. Уровни тут условные, главное различие - в адресации узлов на разных уровнях. В "приготовлении" RS485 есть много тонкостей, если их знать и учитывать, то никаких проблем, кроме скорости опроса не будет. Например, очень вредит неопределенное состояние линии, когда не работает ни один передатчик - решается либо растяжкой линии, либо задержкой передачи после активации передатчика, либо вставкой спецсимволов в начало кадра. CAN хорош, но у него все сложнее - точку сэмплирования бита не так выставил и через опторазвязку может на больших скоростях и/или растояниях не заработать. В AVR, например, положение точки семплирования не так гибко задается как в STM32. Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
_pv 71 13 января, 2020 Опубликовано 13 января, 2020 · Жалоба 10 minutes ago, adnega said: Если теряются байты, то это не только из-за кривого драйвера, но и из-за отсутствия согласования линии. CAN в этом плане менее терпим ;) в чём заключается "нетерпимость" CANa к несогласованной шине? тут скорее наоборот, из-за требования к битовой скорости, которая должна быть достаточно низкой чтобы сигнал туда/сюда по всей шине успел распространиться за время меньше 1 бита, и если скорость нарастания фронтов у драйвера выставить соответствующую скорости чтобы линия перестала быть "длинной", то отсутсвие согласования на концах не особо жизнь испортит. но тоже самое и с rs485 можно сделать. а разделение сегментов не тупыми хабами/репитерами, а более "интеллектуальными" мостами сделает адресацию этих 1000 устройств на шине гораздо "веселее". Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AlexRayne 7 13 января, 2020 Опубликовано 13 января, 2020 · Жалоба Поправьте меня, может я ошибаюсь? Но вроде КАН предоставляем максимум 8байт данных в пакете? Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Алексей Васильевич 0 13 января, 2020 Опубликовано 13 января, 2020 · Жалоба 4 часа назад, adnega сказал: то довольно неплохая конструкция: мастер на 60 слейвов В моем случае это LAN через общий свич с индивидуальными айпишиками, это дополнительная витая пара. 7x60 + 1x120 Сейчас стоит задача сделать 1000 без LAN , второй кабель тянуть не логично, рассчитываю обойтись одной/двумя линиями , в мастере у меня 2 CAN. 4 часа назад, adnega сказал: CAN хорош, но у него все сложнее Конкретно от CAN мне нужен прежде всего редкий НО БЫСТРЫЙ отклик от устройств, в сами устройства информация заливается заранее. Также есть перспектива ускорить работу за счет БЫСТРОЙ отправки от устройства к устройству и "фоновой" отправки мастеру. Сейчас задачи на устройства загружаются из мастера заранее и эта предопределенная цепочка и событие одного устройства теоретически можно отправлять в обход мастера, активировать второе устройство о котором заранее сообщено первому и так до конца цепочки. В это время с низким приоритетом загружаться новые цепочки. C RS485 приоритеты сложно расставить, потому что идет постоянный пустой опрос устройств для приемлемого отклика. 6 часов назад, jcxz сказал: DMA вообще непонятно с какого боку тут приплетён. Без DMA и приоритета на поток опроса, сам опрос устройств происходит очень мелено. С приоритетом на поток опроса, виснут остальные потоки из-за бесконечного цикла самого опроса. Единственный способ добиться отностительно быстрого отклика слейва не тормозя основную систему (на одночиповом решении) это передать обмен DMA , собственно для чего он и создан. Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Сергей Борщ 134 13 января, 2020 Опубликовано 13 января, 2020 · Жалоба 9 часов назад, AlexandrY сказал: Абсолютно инженерный термин в отличии от "а у меня нормально работает" 9 часов назад, AlexandrY сказал: Вреднее совета трудно придумать. Пожалуй, это тот редкий случай, когда я послностью согласен с AlexandrY Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
adnega 11 13 января, 2020 Опубликовано 13 января, 2020 · Жалоба 4 часа назад, _pv сказал: в чём заключается "нетерпимость" CANa к несогласованной шине? Без терминаторов переход линии из доминантного состояния в рецессивное будет по экспоненте. В RS485-физике переходы 0<->1 всегда выполняются активным способом, т.е. быстрее. 3 часа назад, AlexRayne сказал: Поправьте меня, может я ошибаюсь? Но вроде КАН предоставляем максимум 8байт данных в пакете? 8 байт в поле данных максимум. Можно чуть чуть информации передать в поле идентификатора. Есть FD-версия CAN (где до 64 байт); не использовал, т.к. редко где он есть. 43 минуты назад, Алексей Васильевич сказал: Также есть перспектива ускорить работу за счет БЫСТРОЙ отправки от устройства к устройству и "фоновой" отправки мастеру. Сейчас задачи на устройства загружаются из мастера заранее и эта предопределенная цепочка и событие одного устройства теоретически можно отправлять в обход мастера, активировать второе устройство о котором заранее сообщено первому и так до конца цепочки. В это время с низким приоритетом загружаться новые цепочки. C RS485 приоритеты сложно расставить, потому что идет постоянный пустой опрос устройств для приемлемого отклика. Мультимастер и система приоритетов - это в некоторых случаях спасение. Например, у меня шина умного дома вся на CAN. Мастеров нет, все живет само, друг с другом общается, спокойно можно гонять низкоприоритетный трафик (например, интерком), не мешая никому важному. Обидно, когда люди используют CAN в режиме полудуплекса по старой привычке (RS485-стайл). Я же отношусь к обмену по CAN как "поставил задачу" - "получил результат", где между ними могут быть поставлены другие задачи и получены другие результаты, и ПО должно быть к этому готово, а не ждать результата в течение некоторого таймаута. Если вы настаиваете на CAN, то советую вам продумать адресацию узлов и приоритеты сообщений. Они же у вас короткие будут (до 8 байт включительно)? Насчет дробления, я бы рекомендовал разбить на такие группы, чтобы они питались от одного БП. Напряжение узлов лучше поднять по максимуму, чтобы снизить потребляемый ток, и т.о. снизить негативное влияние тонких проводов. Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 235 13 января, 2020 Опубликовано 13 января, 2020 · Жалоба 20 минут назад, adnega сказал: Например, у меня шина умного дома вся на CAN. Мастеров нет, все живет само, друг с другом общается, спокойно можно гонять низкоприоритетный трафик (например, интерком), не мешая никому важному. Обидно, когда люди используют CAN в режиме полудуплекса по старой привычке (RS485-стайл). У вас дом наверное не 2 км в поперечнике? Да и устройств я думаю на порядки меньше чем нужно ТС? Тогда ваш случай не имеет никакого отношения к случаю ТС. Те проблемы, которые у него могут возникнуть, у Вас не должны проявляться в принципе. Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AlexandrY 3 13 января, 2020 Опубликовано 13 января, 2020 · Жалоба 26 minutes ago, adnega said: Мастеров нет, все живет само, друг с другом общается, спокойно можно гонять низкоприоритетный трафик (например, интерком), не мешая никому важному. Обидно, когда люди используют CAN в режиме полудуплекса по старой привычке (RS485-стайл). Я же отношусь к обмену по CAN как "поставил задачу" - "получил результат", где между ними могут быть поставлены другие задачи и получены другие результаты, и ПО должно быть к этому готово, а не ждать результата в течение некоторого таймаута. "Алексей Васильевич" же сказал - у него DMA! Хотя интересно зачем DMА использовать для CAN где есть всего два майлбокса. На приеме все равно надо софтово демультиплексировать логические каналы передачи, т.е. по любому прерывания. А так пакеты CAN отражают на память и прикладной уровень в принципе может не знать о существовании CAN или другого полевого интерфейса. Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
_pv 71 13 января, 2020 Опубликовано 13 января, 2020 · Жалоба 36 minutes ago, adnega said: Без терминаторов переход линии из доминантного состояния в рецессивное будет по экспоненте. сотня устройств на шине нагрузку сравнимую с терминатором сделает. Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AlexandrY 3 13 января, 2020 Опубликовано 13 января, 2020 · Жалоба 49 minutes ago, adnega said: Без терминаторов переход линии из доминантного состояния в рецессивное будет по экспоненте. В RS485-физике переходы 0<->1 всегда выполняются активным способом, т.е. быстрее. Еслиб это было так, то CAN не работал бы на 1 Mbit. На самом деле все выглядит так- Голубой и синий - линии CAN. Красный - напряжение между линиями CAN-а. Как видно разностное напряжение не имеет никакой экспоненты. Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться