syoma

Это не вопрос и не проблема, а чисто поговорить. У нас сейчас пошел жесткий оптический Ethernet для реалтаймового Process Bus в системе управления. PRP, IEC61850, PTP для синхронизации. EtherCAT уже не так прет. Сегодняшние 20х 1G каналов наш Virtex-7 переваривает очень легко. Так как в сети оборудование почти все свое, хотим перейти на 10G. Ultrascale под рукой есть. Тот же Samtec предлагает вкусные Firefly в индустриальном диапазоне температур и даже нашли уже тех, кто готов на них FMC+ модули с 24х 10G дуплексными каналами сделать. Но оказалось, что есть нюанс: индустриальных 10G Ethernet свичей нету. Парочка есть, но там только четыре 10G порта. А нам надо бы как минимум 12. Вот и пришла идея взять ПЛИСину, прикрутить к ней оптическую FMC+ c 24-мя каналами Firefly, да забебехать простенький 10G Ethernet switch. Все это можно будет легко засунуть в индустриальщину, если взять подходящую плату. А если постараться, то даже cut-through можно замутить, вместо обычных store-and-forward - еще и задержки уменьшатся. Как вам такая идея? Смотрю по статьям - народ все больше и больше понимает, что ПЛИС в этом деле стают очень интересной и полезной штукой.

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

Для этого вам достаточно просто знать, что такие задачи есть и решаются на CAN. Например есть применения CANopen с 1000 узлами и это описано в стандартах - следовательно - реализоуемо. Также CAN-репитеры и Капплеры - это уже давно разработанные продукты, сделанные как раз для таких применений, как у вас - следовательно аналогичные проблемы были и у других. Поэтому вам надо просто сесть и сделать. И не слушать пессимистов.

Тема постоянно скатывается в оффтоп. Да и переместить ее в CAN Интерфейсы не мешало бы.

Вы имели ввиду репитеры/каплеры? Так как трансиверов вам надо будет столько же, сколько у вас и узлов. По одному на каждый. И на стоимость это будет влиять. сильно. В принципе, как вы уже сказали, в качестве репитеров/каплеров по крайней мере для первых проектов, надо взять готовые. Например https://www.ixxat.com/products/products-industrial. За одно узнаете как они работают. А потом уже будете сами смотреть, придумывать свои или нет. По кабелю может стоит поискать такой же, но с витой парой хотя бы. Его разделывать тоже не так сложно. По итогам ваших требований, пока я не вижу проблем с использованием CAN, даже на весьма низких скоростях.

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

Я человека тоже понимаю. Но понимает ли он, что это выдвинет более серьезные требования по выбору CAN-трансиверов и их EMC - защите?

Вопросы: Это серьезное требование? Т.е. на складе нет всяких электропогрузчиков, кранов, токо-коммутационных устройств, моторов, частотников, электролюминисцентных ламп, которые могут запороть этот вид кабеля на корню? Общая длина кабеля до 2км? Приемником может быть любое устройство из 1000-и или только в пределах одного сегмента? Ошибка или недоставка данных? Насколько критично время отклика?

И напишу. Я и не предлагал отказаться от репитеров, или тех же каплеров, как их называют. Да, сеть надо делить на сегменты по 50-60 узлов. Между сегментами ставятся репитеры, задачей которых будет принимать сообщения с одной сети, буферизировать и слать в другой. Почему вы вдруг решили, что для ТС-а эта ситуация должна быть обычной? Менеджмент должен быть, но случаться она должна отнюдь не каждую секунду, иначе не только с CANом а вообще с любым интерфейсом будут проблемы. А по менеджменту - надо отваливание узлов решать, да и все. Механизм очень простой, я уже описал в прошлом сообщении. Автору - Алексей Васильевич, вы можете написать, что требуется от сети, а не то, что вы сейчас делаете на RS485? Т.е. отделить требования от реализации? Я на 99% уверен, что с CANом ваш уже реализованный вариант мастер-слейв вообще не нужен(и вы можете выбросить этот код вообще), но по-моему некоторые тут это не совсем понимают. Т.е. вопросы: - Вы просто периодически шлете 7-8 байтовые команды от одних узлов другим? Как часто это должно происходить (а не сделано у вас в коде)? Асинхронно - по событию, или периодически? - Или у вас один узел должен собирать информацию со всех остальных 999 узлов? Опять же это требуется(а не реализовано у вас в коде) периодически или лучше как только, так и сразу? - Есть ли у вас моменты, когда один узел должен послать одну и ту же команду нескольким или многим узлам одновременно? (точнее требуется ли это в вашем применении) - Или у вас есть большие блоки данных для обмена? - Или все вышесказанное или часть вместе? - Вопрос по теме jcxz - узлы могут включаться и выключаться из сети неожиданно в любые моменту(например их кто-то вручную переставляет)? Или это нештатная ситуация для вашего применения? Короче требования к сетевому обмену надо.

Но в автомобилях именно так и работает и никто не жаловался. Один узел просто сообщает обороты двигателя, а другие их используют. Переключатель света просто выставляет на шину сообщение "Включить габариты" и остальные узлы молча выполняют эту команду без подтверждения. CANopen тоже так работает с механизмом PDO. А если узел вдруг начал перезагружаться, то его задача при перезагрузке - это сообщить всем "Привет! Я здесь!" и спросить Remote Frame "А не скинет ли мне кто-нибудь последнее состояние вот этих и этих данных?" У другие узлы с удовольствием ему помогут получить самые новые данные. Это очень легко реализуемая фича. Режим "Запрос/ответ" все-таки надо забыть. Софт, как и концепцию обмена, при переходе с RS485 на CAN стоит перелопатить, иначе будут те же грабли и преимуществ от новой шины вы просто не получите. По ситуации с репитерами абсолютно не вижу проблем, но напишу позже. Сейчас нет времени.

Ну запишите 0.01с. Хватит? Это верно. Но для дальнейших действий может лучше почитаем CAN спецификацию? Я тоже неправильно сказал - это не часть механизма ACK, а на один бит после него. И чтобы потом не говорили, что после ACK сообщение считается принятым. Нет не считается: А ACTIVE ERROR FLAG после ACK этот END OF FRAME еффективно уничтожает.

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

Интересная задумка, жалко только, что, наверное, сложная. Например в моем авто некоторые измерения можно посмотреть только на родном сканере, который стоит за 2 тыщи баксов. А обычный OBD сканер показывает только ошибки, да и все. Также есть такие умные машины, где после замены фильтров или каких-нибудь датчиков надо производить т.н. "адаптацию". Немцы особенно любят эти адаптации по любому поводу. Это тоже можно сделать только с помощью родного сканера, который подключается через тот же OBD разьем. ИМХО если иметь тот сканер и хорошо его проснифить, можно было бы, наверное, сделать удаленную диагностику. Мне в этом случае видится проблема в дистрибуции этих самых "OBD адаптеров" - стоить они будут не так, чтобы дешево, и плюс к этому надо иметь какую-то возможность управлять этим сканером удаленно, а иначе должен подключаться специалист.

В CAN основная концепция как раз в том, что модель "опрос-ответ" меняется на "издатель-подписчик". Т.е смысл в том, что устройства (это уже не слейвы) сами публикуют сообщения на шину(обычно по изменению или/и периодически), не ожидая, что кто-то их об этом попросит . А тот, кому эта информация нужна, просто слушает шину, ожидая нужное сообщения, фильтруя ненужные по идентификатору (в этом смысл аппаратных фильтров на приеме). В этом и есть смысл мультимастерности и неразрушающего приоритетного арбитража в CAN. Тогда задержка будет в идеале 0.0с и зависеть только от загрузки сети. Механизм Ack в CAN гарантирует, что конкретное сообщение либо будет принято всеми активными узлами в сети, либо не будет принято ни одним из них. Поэтому дополнительный контроль получения, как правило, не требуется. Может быть только ситуация, что конкретный узел полностью отваливается от сети, но это можно легко контролировать т.н. Heartbeat сообщениями - т.е. каждый узел периодически шлет свое сообщение, даже если инфа не изменилась, а те узлы, что на эти сообщения подписаны, контролируют, что сообщения от этого узла не пропадают.

А чем определялся именно выбор CAN для этой сети, вместо другого интерфейса? Чисто физически 1000 CAN трансиверов на одну сеть не повесить, поэтому нужны репитеры, которые бы разделяли сети на сегменты. Тогда можно и скорость повысить и это как-то скомпенсирует задержку на репитерах. Не забудьте про гальваническую развязку драйверов. На таких расстояниях поможет.