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

Уважаемые гуру , прошу помощи в проектировании сети CAN устройств на складе. 

Планируется объединить в одну сеть до 1000 устройств на базе STM32+TJI1050 .

Планируется плоский 4х-жильный кабель 0.5мм2 для объединения( 2 питание, 2 интерфейс), без разрыва самого кабеля.

Питание 12V , планируется параллельное включение блоков питания для светодиодных лент, через каждые 20-50 устройств.

Насколько понимаю без древовидной структуры объединения не обойтись.

Расстояние между устройствами 2м , общая длинна линии до 2км.

Буду рад любым рекомендациям и примерами реализаций похожих конструкций.

 

[Vasily_ 59]

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

TJI1050

Нет такого чипа.

 

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

Планируется плоский 4х-жильный кабель 0.5мм2 для объединения( 2 питание, 2 интерфейс)

Не катит. Ибо нужна витая пара.

1000 устройств в кан? Учите для начала мат-часть.

[Eddy_Em 2]

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

Правда, как оно тупить будет... Если планируется canopen вместо нормального CAN'а, лучше и не начинать.

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

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

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

Правда, как оно тупить будет... Если планируется canopen вместо нормального CAN'а, лучше и не начинать.

На устройствах STM32F042F4P6, насколько понимаю в нем "нормальный CAN"

С репетирами линия должна быть последовательной или возможно частично параллельное включение ?

Насколько упадет скорость с ретитерами при обмене всех устройств с одним центральным?

 

 

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

Нет такого чипа.

 

Не катит. Ибо нужна витая пара.

1000 устройств в кан? Учите для начала мат-часть.

tja1050

[_pv 79]

скорость упадёт не из-за репитеров, а из-за общей длины сегмента, чтобы can работал с разруливанием коллизий, надо чтобы от одного устройства до другого (2км) и обратно свет пробежал заметно быстрее одного бита, то есть получится десяток кБит/с.

на 1000 устройств, по байту в секунду каждому :), а с учётом накладных расходов на преамбулы адресацию и контрольные суммы и того меньше.

[x893 60]

А как ввсё хорошо начиналось !

Нет что бы взять 2 км провода, соединить два устройства и убедиться, что работать будет или не будет.

Или на калькуляторе

Питание 50-20 блоков питания для лент * ток потребления одного и всё это по 0.5 мм2 проводу до 2 км.

[Eddy_Em 2]

Ставим по рипитеру через каждые 200 метров — проблем с длиной линии не будет. Но тормозить будет знатно. В принципе, можно сесть, да оценить.

А насчет canopen — это ж протокол более высокого уровня. Славится своим идиотизмом и невменяемостью. Убивает даже короткую линию. Особенно если устройства постоянно что-то в сеть шлют.

Единственный вариант построить работоспособную CAN-шину на 2 километра — сажать туда устройства, которые работают исключительно в полудуплексном режиме. В смысле — пока их не спросят, ничего не отвечают. Если на линии будет условно 10 рипитеров, а каждый будет задерживать сигнал не больше, чем на полторы длины фрейма, то при скорости в 250кбод передача пакета от звена к звену будет длиться до четверти миллисекунды. Пауза будет в районе 0.4мс. Итого - около 650мкс на пакет. Т.е. от начала до конца линии такой пакет будет ползти не меньше 6.5мс. Получаем скорость в районе 150 пакетов в секунду. В принципе — ничего страшного, если не нужно быстро реагировать и часто опрашивать.

А, да. Я про устранение помех и коллизий забыл совершенно. Так что, если будет еще мусор всякий и/или коллизии, то можно смело еще полтора порядка убрать. И получим где-то 50 пакетов в секунду. А может даже и меньше.

Изменено 9 января, 2020 пользователем Eddy_Em

[Baza 31]

не проще будет PoE питание и Ethernet для управления?

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

10 часов назад, Eddy_Em сказал:

Ставим по рипитеру через каждые 200 метров — проблем с длиной линии не будет. Но тормозить будет знатно. В принципе, можно сесть, да оценить.

А насчет canopen — это ж протокол более высокого уровня. Славится своим идиотизмом и невменяемостью. Убивает даже короткую линию. Особенно если устройства постоянно что-то в сеть шлют.

Единственный вариант построить работоспособную CAN-шину на 2 километра — сажать туда устройства, которые работают исключительно в полудуплексном режиме. В смысле — пока их не спросят, ничего не отвечают. Если на линии будет условно 10 рипитеров, а каждый будет задерживать сигнал не больше, чем на полторы длины фрейма, то при скорости в 250кбод передача пакета от звена к звену будет длиться до четверти миллисекунды. Пауза будет в районе 0.4мс. Итого - около 650мкс на пакет. Т.е. от начала до конца линии такой пакет будет ползти не меньше 6.5мс. Получаем скорость в районе 150 пакетов в секунду. В принципе — ничего страшного, если не нужно быстро реагировать и часто опрашивать.

А, да. Я про устранение помех и коллизий забыл совершенно. Так что, если будет еще мусор всякий и/или коллизии, то можно смело еще полтора порядка убрать. И получим где-то 50 пакетов в секунду. А может даже и меньше.

 

Теоретически моя система в полудуплексе какраз и есть. 

В среднем секунду не более 1-2 ответа от всех устройств суммарно , в остальное время ждут свои данные. 

В сеть отправки будут редкие но сразу на 10-50 устройств ("Задачи")

Важно доставлять пакеты 100% и в случае сбоя отправитель должен об этом знать. (отключение питания не в счет). 

Репитеры это пара AMIS-42770 в схеме с развязкой?

Можно как-то мониторить помехи колизии ? есть возможность программно на центральном узле ,  анализировать в какой они части сети?  

 

 

10 часов назад, Eddy_Em сказал:

 В принципе, можно сесть, да оценить.

Вы оказываете услуги в проектирование сетей? Если да прошу написать в личку 

59 минут назад, Baza сказал:

не проще будет PoE питание и Ethernet для управления?

Понадобиться роутер на 1000 портов и 500 000 метров витой пары.

[SSerge 6]

PoE питание и Ethernet на каждый узел сети - это будет слишком дорого.

Более-менее релистичное решение - разбить сеть на сегменты разумной длины, каждый из сегментов подключается через модуль Ethernet-CAN.

[jcxz 243]

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

Теоретически моя система в полудуплексе какраз и есть. 

В среднем секунду не более 1-2 ответа от всех устройств суммарно , в остальное время ждут свои данные. 

В сеть отправки будут редкие но сразу на 10-50 устройств ("Задачи")

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

Что такое "1-2 ответа от всех устройств суммарно"? Сколько это в байтах? 2000 б/сек или 20000 б/сек? Далее прибавляем к этому биты обрамления CAN-кадра. И получится что скорей всего такая система не возможна физически.

Если связь с устройствами - полудуплексная, то зачем вообще CAN? Для полудуплексного обмена достаточно RS-485. И он не имеет ограничений связанных с механизмом определения коллизий как в CAN. RS-485 для вашей задачи будет наверное самым оптимальным решением.

 

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

Понадобиться роутер на 1000 портов и 500 000 метров витой пары.

Не обязательно. Достаточно например в каждом слэйв-девайсе иметь два ethernet-порта. И ретранслировать между ними данные силами самого слэйв-девайса. И провода нужны только между отдельными девайсами, а не 500км.

[AlexandrY 3]

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

Репитеры это пара AMIS-42770 в схеме с развязкой?

У этой микросхемы заявлено - Overvoltage ±45 V
Эт мало для длинных линий CAN в десятки и сотни метров. Либо все должно быть жестко гальвано развязано.
Если гальвано изоляцию ставить жалко, то ставим трансиверы типа  LTC2875 чтобы Overvoltage Range был не меньше  ±60 V

А так делал сети на 50 узлов на дистанции 1 км со скоростью 100 Кбит. Работало как часы. 

Надо делать сегменты по 100 узлов,  и соединять сегменты не через трансиверы, а через CAN мосты на микроконтроллерах.
Тогда можно надеяться на общую скорость в 50 Кбит. 
Тогда узлы еще сносно можно через CAN перепрограммировать и снимать телеметрию. 

PS. Консультациями и заказной разработкой  сейчас не занимаюсь.     
 

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

В 10.01.2020 в 11:41, jcxz сказал:

Что такое "1-2 ответа от всех устройств суммарно"?

ответ один байт.

В 10.01.2020 в 11:41, jcxz сказал:

Для полудуплексного обмена достаточно RS-485

Более 5ти лет на RS-485 и работает, все что можно выжато , он морально устарел и сложно строить большие сети.  RS485 программно обрабатывать сложно из-за проблем в самом интерфейсе. Режим последовательного опроса имеет медленный отклик в целом и нестабильный из-за помех , доставку нужно проверять опросом, при посадке питания на 0.5 система доставляет проблемы. Насколько понимаю в CAN все эти проблемы устранены , а главное с ним можно строить сети и получать быстрый отклик от устройств.

В 10.01.2020 в 12:00, AlexandrY сказал:

Эт мало для длинных линий CAN в десятки и сотни метров. Либо все должно быть жестко гальвано развязано.

Буду развязывать, на 50 устройств планирую блок питание с развязкой CAN как отдельный модуль

[jcxz 243]

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

Более 5ти лет на RS-485 и работает, все что можно выжато , он морально устарел и сложно строить большие сети.

Что такое "морально устарел"? Это фраза из лексикона какого-то маркетолога, а не инженера.

RS-485 был и нормально работает. И применяется повсеместно. Там где он подходит.

 

Цитата

RS485 программно обрабатывать сложно из-за проблем в самом интерфейсе.

Что за проблемы?? Странно - сколько с ним работал - проблем не замечал.

 

Цитата

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

Насколько понимаю в CAN все эти проблемы устранены , а главное с ним можно строить сети и получать быстрый отклик от устройств.

Это проблемы реализации конкретно вашей системы, а не RS-485 как интерфейса. И не разобравшись и не устранив эти проблемы в RS-485, просто заменив интерфейс на CAN, вы получите аналогичные проблемы на CAN.

RS-485 более гибок по сравнению с CAN, так как более прост. Если есть помехи на RS-485, почему думаете, что на CAN они пропадут?

В CAN нет подтверждения доставки, есть подтверждение, что кадр был увиден хотя бы одним узлом (ACK). Не важно - принят этот кадр потом или нет; и тому ли узлу он вообще был предназначен. Если кадр вы посылали узлу N (который далеко), но есть узел M (который близко) и узел M его увидел, этот M и даст ACK. А узел N этот кадр может не принять, так как к тому времени, после всех репитеров, на более дальнем участке трассы на него наложилась помеха.

Так что в CAN вам так же придётся делать подтверждения отдельным ответным кадром.

И самый большой плюс CAN по сравнению с RS-485: Аппаратное разрешение коллизий. Но в Вашем случае (длинная линия с множеством устройств) это скорее даже будет минусом, чем плюсом. Так как ограничит скорость передачи. Тем более если с репитерами.

Если думаете, что физический уровень протокола CAN более помехоустойчив, то никто не мешает использовать UART с физикой от CAN (подключение UART к линии через драйвер линии CAN).

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

Буду развязывать, на 50 устройств планирую блок питание с развязкой CAN как отдельный модуль

И как собираетесь передавать подтверждения приёма через этот "отдельный модуль" из одного сегмента линии в другой?  Опять программно и опять получить "медленный отклик"?  

[AlexandrY 3]

6 minutes ago, jcxz said:

Что такое "морально устарел"? Это фраза из лексикона какого-то маркетолога, а не инженера.

RS-485 был и нормально работает. И применяется повсеместно. Там где он подходит.

Ну прицепились вообще без повода. 
Морально устарел - означает что производители ( кроме вас конечно) предпочитают не использовать данную технологию.
Абсолютно инженерный термин в отличии от "а у меня  нормально работает" 
Уже сколько раз сталкивались, в линейках какой-либо продукции  CAN есть, а RS485 нет.  Или RS485 есть, но на нем реализован урезанный MODBUS, а если CAN, то там полный CANopen с кучей недоступной по RS485 функциональности. 
Так что знайте на будущее что такое "морально устарел" 

12 minutes ago, jcxz said:

Если думаете, что физический уровень протокола CAN более помехоустойчив, то никто не мешает использовать UART с физикой от CAN (подключение UART к линии через драйвер линии CAN).

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