Алексей Васильевич 0 9 января, 2020 Опубликовано 9 января, 2020 · Жалоба Уважаемые гуру , прошу помощи в проектировании сети CAN устройств на складе. Планируется объединить в одну сеть до 1000 устройств на базе STM32+TJI1050 . Планируется плоский 4х-жильный кабель 0.5мм2 для объединения( 2 питание, 2 интерфейс), без разрыва самого кабеля. Питание 12V , планируется параллельное включение блоков питания для светодиодных лент, через каждые 20-50 устройств. Насколько понимаю без древовидной структуры объединения не обойтись. Расстояние между устройствами 2м , общая длинна линии до 2км. Буду рад любым рекомендациям и примерами реализаций похожих конструкций. Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Vasily_ 54 9 января, 2020 Опубликовано 9 января, 2020 · Жалоба 24 минуты назад, Алексей Васильевич сказал: TJI1050 Нет такого чипа. 25 минут назад, Алексей Васильевич сказал: Планируется плоский 4х-жильный кабель 0.5мм2 для объединения( 2 питание, 2 интерфейс) Не катит. Ибо нужна витая пара. 1000 устройств в кан? Учите для начала мат-часть. Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Eddy_Em 1 9 января, 2020 Опубликовано 9 января, 2020 · Жалоба Единственная преграда здесь - нагрузка на линию и ее длина. Поэтому если подробить на кусочки поменьше, поставив между ними рипитеры, то хоть сто тысяч устройств на одну шину. Правда, как оно тупить будет... Если планируется canopen вместо нормального CAN'а, лучше и не начинать. Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Алексей Васильевич 0 9 января, 2020 Опубликовано 9 января, 2020 · Жалоба 1 час назад, Eddy_Em сказал: Единственная преграда здесь - нагрузка на линию и ее длина. Поэтому если подробить на кусочки поменьше, поставив между ними рипитеры, то хоть сто тысяч устройств на одну шину. Правда, как оно тупить будет... Если планируется canopen вместо нормального CAN'а, лучше и не начинать. На устройствах STM32F042F4P6, насколько понимаю в нем "нормальный CAN" С репетирами линия должна быть последовательной или возможно частично параллельное включение ? Насколько упадет скорость с ретитерами при обмене всех устройств с одним центральным? 1 час назад, Vasily_ сказал: Нет такого чипа. Не катит. Ибо нужна витая пара. 1000 устройств в кан? Учите для начала мат-часть. tja1050 Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
_pv 71 9 января, 2020 Опубликовано 9 января, 2020 · Жалоба скорость упадёт не из-за репитеров, а из-за общей длины сегмента, чтобы can работал с разруливанием коллизий, надо чтобы от одного устройства до другого (2км) и обратно свет пробежал заметно быстрее одного бита, то есть получится десяток кБит/с. на 1000 устройств, по байту в секунду каждому :), а с учётом накладных расходов на преамбулы адресацию и контрольные суммы и того меньше. Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
x893 51 9 января, 2020 Опубликовано 9 января, 2020 · Жалоба А как ввсё хорошо начиналось ! Нет что бы взять 2 км провода, соединить два устройства и убедиться, что работать будет или не будет. Или на калькуляторе Питание 50-20 блоков питания для лент * ток потребления одного и всё это по 0.5 мм2 проводу до 2 км. Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Eddy_Em 1 9 января, 2020 Опубликовано 9 января, 2020 (изменено) · Жалоба Ставим по рипитеру через каждые 200 метров — проблем с длиной линии не будет. Но тормозить будет знатно. В принципе, можно сесть, да оценить. А насчет canopen — это ж протокол более высокого уровня. Славится своим идиотизмом и невменяемостью. Убивает даже короткую линию. Особенно если устройства постоянно что-то в сеть шлют. Единственный вариант построить работоспособную CAN-шину на 2 километра — сажать туда устройства, которые работают исключительно в полудуплексном режиме. В смысле — пока их не спросят, ничего не отвечают. Если на линии будет условно 10 рипитеров, а каждый будет задерживать сигнал не больше, чем на полторы длины фрейма, то при скорости в 250кбод передача пакета от звена к звену будет длиться до четверти миллисекунды. Пауза будет в районе 0.4мс. Итого - около 650мкс на пакет. Т.е. от начала до конца линии такой пакет будет ползти не меньше 6.5мс. Получаем скорость в районе 150 пакетов в секунду. В принципе — ничего страшного, если не нужно быстро реагировать и часто опрашивать. А, да. Я про устранение помех и коллизий забыл совершенно. Так что, если будет еще мусор всякий и/или коллизии, то можно смело еще полтора порядка убрать. И получим где-то 50 пакетов в секунду. А может даже и меньше. Изменено 9 января, 2020 пользователем Eddy_Em Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Baza 30 10 января, 2020 Опубликовано 10 января, 2020 · Жалоба не проще будет PoE питание и Ethernet для управления? Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Алексей Васильевич 0 10 января, 2020 Опубликовано 10 января, 2020 · Жалоба 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 4 10 января, 2020 Опубликовано 10 января, 2020 · Жалоба PoE питание и Ethernet на каждый узел сети - это будет слишком дорого. Более-менее релистичное решение - разбить сеть на сегменты разумной длины, каждый из сегментов подключается через модуль Ethernet-CAN. Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 235 10 января, 2020 Опубликовано 10 января, 2020 · Жалоба 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 10 января, 2020 Опубликовано 10 января, 2020 · Жалоба 58 minutes ago, Алексей Васильевич said: Репитеры это пара AMIS-42770 в схеме с развязкой? У этой микросхемы заявлено - Overvoltage ±45 V Эт мало для длинных линий CAN в десятки и сотни метров. Либо все должно быть жестко гальвано развязано. Если гальвано изоляцию ставить жалко, то ставим трансиверы типа LTC2875 чтобы Overvoltage Range был не меньше ±60 V А так делал сети на 50 узлов на дистанции 1 км со скоростью 100 Кбит. Работало как часы. Надо делать сегменты по 100 узлов, и соединять сегменты не через трансиверы, а через CAN мосты на микроконтроллерах. Тогда можно надеяться на общую скорость в 50 Кбит. Тогда узлы еще сносно можно через CAN перепрограммировать и снимать телеметрию. PS. Консультациями и заказной разработкой сейчас не занимаюсь. Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Алексей Васильевич 0 13 января, 2020 Опубликовано 13 января, 2020 · Жалоба В 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 235 13 января, 2020 Опубликовано 13 января, 2020 · Жалоба 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 13 января, 2020 Опубликовано 13 января, 2020 · Жалоба 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 уровне, а не на уровне физики. Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться