[Алексей Васильевич 0]

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 184]

1 час назад, AlexandrY сказал:

Морально устарел - означает что производители ( кроме вас конечно) предпочитают не использовать данную технологию.

Ну с вами то уже давно всё ясно. Всё что не использует "облачные технологии" и прочие новомодные фишки - всё устарело.

А медь в проводах - не устарела морально? А то может пора на что-то боле инновационное менять?  

Цитата

Помехоустойчивость CAN-у дает аппаратная реализация ретрансмитов и арбитраж в контроллере CAN, т.е. на MAC уровне, а не на уровне физики. 

Расскажите нам как будут работать ретрансмиты CAN-а "на уровне физики", при том что сама линия будет разбита на множество физически отдельных сегментов. 

А также - как будет работать арбитраж CAN в пределах одного бита. При тех условиях.

А мы посмеёмся 

[yes 5]

47 minutes ago, Алексей Васильевич said:

Был уверен что CAN гарантированно доставляет. Как правильно организовать доставку в САN?

гарантировано за счет повторов на МАС уровне, который сделан в аппаратной части контроллера и не требует программного кода.

то есть если все работает - то программа на одном конце положила сообщение в мэйлбокс, а на другом достала.

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

--------------

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

[_pv 52]

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 184]

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 10]

"Крылья, ноги... главное хвост". Проблемы длинных линий обычно связаны с необходимостью согласования такой линии.

Если теряются байты, то это не только из-за кривого драйвера, но и из-за отсутствия согласования линии. CAN в этом плане менее терпим ;)

Это довольно неплохая конструкция: мастер на 60 слейвов, затем мастера в своей шине с одним супер-мастером.

Мастера делают всю грязную работу по опросу узлов. Отвалившиеся узлы должны опрашиваться реже.

Например, после каждого 10 опроса мы опрашиваем один раз один из "отвалившихся" узлов.

Супер-мастер выдает высокоуровневые задания мастерам и получает от них высокоуровневые ответы подчиненных узлов.

Уровни тут условные, главное различие - в адресации узлов на разных уровнях.

В "приготовлении" RS485 есть много тонкостей, если их знать и учитывать, то никаких проблем, кроме скорости опроса не будет.

Например, очень вредит неопределенное состояние линии, когда не работает ни один передатчик - решается либо растяжкой линии,

либо задержкой передачи после активации передатчика, либо вставкой спецсимволов в начало кадра.

CAN хорош, но у него все сложнее - точку сэмплирования бита не так выставил и через опторазвязку может на больших скоростях и/или растояниях не заработать.

В AVR, например,  положение точки семплирования не так гибко задается как в STM32.

[_pv 52]

10 minutes ago, adnega said:

Если теряются байты, то это не только из-за кривого драйвера, но и из-за отсутствия согласования линии. CAN в этом плане менее терпим ;)

в чём заключается "нетерпимость" CANa к несогласованной шине?

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

но тоже самое и с rs485 можно сделать.

 

а разделение сегментов не тупыми хабами/репитерами, а более "интеллектуальными" мостами сделает адресацию этих 1000 устройств на шине гораздо "веселее".

[AlexRayne 7]

Поправьте меня, может я ошибаюсь? Но вроде КАН предоставляем максимум 8байт данных в пакете?

[Алексей Васильевич 0]

4 часа назад, adnega сказал:

то довольно неплохая конструкция: мастер на 60 слейвов

В моем случае это LAN через общий свич с индивидуальными айпишиками, это дополнительная витая пара. 7x60 + 1x120

Сейчас стоит задача сделать 1000 без LAN , второй кабель тянуть не логично, рассчитываю обойтись одной/двумя линиями , в мастере у меня 2 CAN.

4 часа назад, adnega сказал:

CAN хорош, но у него все сложнее

Конкретно от CAN мне нужен прежде всего редкий НО БЫСТРЫЙ отклик от устройств, в сами устройства информация заливается заранее.

Также есть перспектива ускорить работу за счет БЫСТРОЙ отправки от устройства к устройству и "фоновой" отправки мастеру. Сейчас задачи на устройства загружаются из мастера заранее и эта предопределенная цепочка и событие одного устройства теоретически можно отправлять в обход мастера, активировать второе устройство о котором заранее сообщено первому и так до конца цепочки. В это время с низким приоритетом загружаться новые цепочки. C RS485 приоритеты сложно расставить, потому что идет постоянный пустой опрос устройств для приемлемого отклика.  

 

 

6 часов назад, jcxz сказал:

DMA вообще непонятно с какого боку тут приплетён.

Без DMA и приоритета на поток опроса, сам опрос устройств происходит очень мелено. С приоритетом на поток опроса, виснут остальные потоки из-за бесконечного цикла самого опроса. Единственный способ добиться отностительно быстрого отклика слейва не тормозя основную систему (на одночиповом решении) это передать обмен DMA , собственно для чего он и создан.  

[Сергей Борщ 119]

9 часов назад, AlexandrY сказал:

Абсолютно инженерный термин в отличии от "а у меня  нормально работает" 

9 часов назад, AlexandrY сказал:

Вреднее совета трудно придумать. 

Пожалуй, это тот редкий случай, когда я послностью согласен с AlexandrY

[adnega 10]

4 часа назад, _pv сказал:

в чём заключается "нетерпимость" CANa к несогласованной шине?

Без терминаторов переход линии из доминантного состояния в рецессивное будет по экспоненте.

В RS485-физике переходы 0<->1 всегда выполняются активным способом, т.е. быстрее.

3 часа назад, AlexRayne сказал:

Поправьте меня, может я ошибаюсь? Но вроде КАН предоставляем максимум 8байт данных в пакете?

8 байт в поле данных максимум. Можно чуть чуть информации передать в поле идентификатора. Есть FD-версия CAN (где до 64 байт); не использовал, т.к. редко где он есть.

43 минуты назад, Алексей Васильевич сказал:

Также есть перспектива ускорить работу за счет БЫСТРОЙ отправки от устройства к устройству и "фоновой" отправки мастеру. Сейчас задачи на устройства загружаются из мастера заранее и эта предопределенная цепочка и событие одного устройства теоретически можно отправлять в обход мастера, активировать второе устройство о котором заранее сообщено первому и так до конца цепочки. В это время с низким приоритетом загружаться новые цепочки. C RS485 приоритеты сложно расставить, потому что идет постоянный пустой опрос устройств для приемлемого отклика.

Мультимастер и система приоритетов - это в некоторых случаях спасение. Например, у меня шина умного дома вся на CAN. Мастеров нет, все живет само, друг с другом общается, спокойно можно гонять низкоприоритетный трафик (например, интерком), не мешая никому важному. Обидно, когда люди используют CAN в режиме полудуплекса по старой привычке (RS485-стайл). Я же отношусь к обмену по CAN как "поставил задачу" - "получил результат", где между ними могут быть поставлены другие задачи и получены другие результаты, и ПО должно быть к этому готово, а не ждать результата в течение некоторого таймаута.

Если вы настаиваете на CAN, то советую вам продумать адресацию узлов и приоритеты сообщений. Они же у вас короткие будут (до 8 байт включительно)?

Насчет дробления, я бы рекомендовал разбить на такие группы, чтобы они питались от одного БП. Напряжение узлов лучше поднять по максимуму, чтобы снизить

потребляемый ток, и т.о. снизить негативное влияние тонких проводов.

[jcxz 184]

20 минут назад, adnega сказал:

Например, у меня шина умного дома вся на CAN. Мастеров нет, все живет само, друг с другом общается, спокойно можно гонять низкоприоритетный трафик (например, интерком), не мешая никому важному. Обидно, когда люди используют CAN в режиме полудуплекса по старой привычке (RS485-стайл).

У вас дом наверное не 2 км в поперечнике? Да и устройств я думаю на порядки меньше чем нужно ТС? Тогда ваш случай не имеет никакого отношения к случаю ТС. Те проблемы, которые у него могут  возникнуть, у Вас не должны проявляться в принципе.

[AlexandrY 3]

26 minutes ago, adnega said:

Мастеров нет, все живет само, друг с другом общается, спокойно можно гонять низкоприоритетный трафик (например, интерком), не мешая никому важному. Обидно, когда люди используют CAN в режиме полудуплекса по старой привычке (RS485-стайл). Я же отношусь к обмену по CAN как "поставил задачу" - "получил результат", где между ними могут быть поставлены другие задачи и получены другие результаты, и ПО должно быть к этому готово, а не ждать результата в течение некоторого таймаута.

"Алексей Васильевич" же сказал - у него DMA!
Хотя интересно зачем DMА использовать для CAN где есть всего два майлбокса. 
На приеме все равно надо софтово демультиплексировать логические каналы передачи, т.е. по любому прерывания.
А так пакеты CAN отражают на память и прикладной уровень в принципе может не знать о существовании CAN или другого полевого интерфейса.    

 
 

[_pv 52]

36 minutes ago, adnega said:

Без терминаторов переход линии из доминантного состояния в рецессивное будет по экспоненте.

сотня устройств на шине нагрузку сравнимую с терминатором сделает.

[AlexandrY 3]

49 minutes ago, adnega said:

Без терминаторов переход линии из доминантного состояния в рецессивное будет по экспоненте.

В RS485-физике переходы 0<->1 всегда выполняются активным способом, т.е. быстрее.

Еслиб это было так, то CAN не работал бы на 1 Mbit.

На самом деле все выглядит так-

Голубой и синий - линии CAN. Красный - напряжение между линиями CAN-а.
Как видно разностное напряжение не имеет никакой экспоненты.