Комментарии 23
С появлением CAN XL всё это legacy можно уже начать забывать.
Чем он лучше 10Base-T1 ?
Вообще я нигде не писал, что он "лучше" или "хуже". Ещё не щупал руками, но по описании 10Base-T1S/L я для себя вынес, что это чуть более быстрая свистелка (на ~20%, что само по себе не очень существенно), чем XL. При этом, это "чуть" достигается засчет того, как работает PLCA: необходимость в мастер-ноде, отсутствие приоритизации сообщений, необходимость в присваивании узлам уникальных ID и ведении их списка на мастере, упрощенный механизм отключения от шины сбоящей ноды, ограничение на максимальное количество нод, очень короткая линия для T1S, либо отсутствие шины вовсе (только peer-to-peer) для T1L.
Для кого-то у XL-контроллеров также плюсом будет обратная совместимость со всем вплоть до еще паянного дедушкой в сарае из навесных элементов классического CAN.
Но если у вас есть конкретный опыт, напишите статью, где приведите более подробное сравнение, с удовольствием почитаю.
Так уже сравнили
CAN XL and 10BASE-T1S – Dataline Performance of Two New Actors in the Networking Arena
CAN XL and 10BASE-T1S – Gateway Performance of Two New Actors in the Networking Arena
Однако с CAN XL я чипов не нашёл. А 10Base-T1 уже есть доступные и недорогие.
И поверх 10Base-T1 есть масса решений, включая прямой выход в глобальную сеть с огромным количеством опенсорсных проектов.
Так уже сравнили
В интернете сравнений полно, я и конкретно это читал, но они поверхностные (ту проблематику, которую я обозначил хотя бы в комменте выше, они в явном виде не рассматривают), и вопросики позадавать некому (поэтому на хабре и не любят статьи-переводы, т.к. обычно автор такой публикации ни бе, ни ме по предмету от себя добавить не может).
Однако с CAN XL я чипов не нашёл. А 10Base-T1 уже есть доступные и недорогие.
Он появился лет 5 назад, а XL всего пару лет назад, т.ч. с доступностью последнего у ширнармасс, видимо, придется еще годик подождать.
И поверх 10Base-T1 есть масса решений, включая прямой выход в глобальную сеть с огромным количеством опенсорсных проектов.
Берем самое банальное промышленное применение. Дано: некое производственное помещение длиной в сотню-другую метров, и пара десятков (или сотен) управляемых узлов. Нужен большой (скажем, килобайт) размер пакета, а скорость передачи здесь выведем за скобки, чтобы не усложнять расчеты. 10Base-T1 справится с такими вводными?
Конечно же справится, это ж почти такой же Ethernet, какой применяется в сетях повсеместно.
Судя по спецификации, это вообще ни разу не такой же Ethernet. Почему тогда много где упоминается, что по стандарту S поддерживается длина шины до 25 метров с гарантированным кол-вом узлов равным 8? В CAN нужна длинная шина - уменьшаем скорость. Здесь как будто 10 Мбит - фикс (что косвенно следует из названия), соответственно, и шину длиннее 25м не сделать?
Во, находятся за 60 сек:
А говорите всё смотрели.
Вообще на CAN XL я смотрю как на костыли, нужные где-то там в корпоративном секторе автомобилестроения, по их узкоспециальным интересам.
В Ethernet есть куча способов маршрутизации, проекты открыты. Поэтому ограничения на количество узлов на одной физической подсети мало волнует.
А говорите всё смотрели.
Вообще на CAN XL я смотрю как на костыли, нужные где-то там в корпоративном секторе автомобилестроения, по их узкоспециальным интересам.
В Ethernet есть куча способов маршрутизации, проекты открыты. Поэтому ограничения на количество узлов на одной физической подсети мало волнует.
Это вы плохо смотрели. T1L - это peer-to-peer, а не шина (только 2 устройства).
Если делаете систему с нуля, то не должно быть никакого значения через микросхему проходят сигналы на плате или напрямую от разъёма к разъёму. Поскольку какую-то микросхему все равно ставить придётся.
Вы просто представьте что вы предлагаете. Вот идут у меня 20 датчиков с интервалом в 50 метров каждый. В случае с CAN мы просто берем 3 бухты витой пары и бросаем, садя устройства прямо на провод. В вашем случае я даже не представляю что вы предлагаете, каждые 50 метров вешать на линию предлагаемое выше устройство-переходник? А какой протокол будет на шине? Обычный 10Base-T работать не будет (слишком длинная шина), 10Base-T1 - тоже (не умеет в multidrop). Коммутаторы ставить каждые 100 метров? Тогда зачем нам вообще тут T1L, это обычный Ethernet выйдет)
И что значит "делаете систему с нуля"? Промышленная автоматизация чуть менее, чем полностью, состоит из готовых модулей управления, датчиков, сенсоров, которые из коробки можно садить прямо на шину, в этом и суть стандартов.
Я понимаю ваши переживания, но вы чуток передёргиваете
Вот схема из даташита:
А ещё есть топология типа Ring
Чем это физически отличается от CAN?
CAN тоже имеет разъёмы, тоже соединяется по цепочке. Прям на провод соплями ничего не вешают. Там также адреса надо выставлять.
У вас там датчики не свои? Ну так сделайте свои. У вас же серьёзная задача.
Вы ж тут готовы год ждать до появления чипов с CAN XL. А так уже есть решение производительней чем будущий CAN XL.
Я вам скажу что с CAN-ом огребал такие сказочные проблемы, особенно по соседству с частотными преобразователями, что больше никаких иллюзий по поводу его помехоустойчивости не питаю. Всё решают программные стеки.
CAN тоже имеет разъёмы, тоже соединяется по цепочке. Прям на провод соплями ничего не вешают.
Stub'ы в CAN от провода отводят, daisy chain не нужен. В противном случае все устройства должны были бы иметь 2 порта (условные "вход" и "выход"). Также выход из строя или просто демонтаж любого из устройств не приводит к разрыву линии.
Там также адреса надо выставлять.
Не надо, у узла может быть как много идентификаторов, так и ни одного, одинаковые "идентификаторы" у разных устройств - также не редкость.
Я понимаю ваши переживания, но вы чуток передёргиваете
Вот схема из даташита: А ещё есть топология типа Ring
Вот интересно, если на шине цепочкой висит сотня таких девайсов, и все они работают по сути как повторители (сигнал ходит не напрямую от края до края шины), то при скорости среды в 10 Мбит/с, какова будет реальная скорость обмена между первым и последним узлом. А если они все еще и будут активно общаться, да пакетами размером в килобайт, будет ли вообще это работать, или всё потонет в синхронизациях и коллизиях. Честно - я не знаю, было бы интересно узнать.
У вас там датчики не свои? Ну так сделайте свои. У вас же серьёзная задача.
Мы же тут не про какую-то конкретную задачу говорим, а про "в принципе", про перспективы новых протоколов в промышленной автоматизации, нет? Вот есть (или скоро появятся, если говорить о сабже) станки c интерфейсом на стандартных протоколах, есть инженерное оборудование (вентиляция, электрораспределительное оборудование), есть телеметрические датчики. И протокол либо будет позволять работать с ними "из коробки", либо нет, и потребуются какие-то переходные платы и подобн (либо эти переходные платы придется добавлять в качестве довеска в каждое устройство). Пока что, то, что я вижу в T1 - оно либо более сложно и дорого, чем CAN, либо дает меньшую гибкость или лимитировано по функционалу. Возможно, найдутся применения, где это оправдано, но с точки зрения универсальности пока это решение вопросов вызывает больше, чем есть ответов.
Вот интересно, если на шине цепочкой висит сотня таких девайсов, и все они работают по сути как повторители (сигнал ходит не напрямую от края до края шины), то при скорости среды в 10 Мбит/с, какова будет реальная скорость обмена между первым и последним узлом.
Ну тут уж сами считайте.
А я бы так оценил. Сигнал проходит за 5 мкс по витой паре 1 км . Ещё 6.4 мкс добавляет каждый узел из-за латентности.
Итого на 100 узлов и 100 км получаем 1.2 миллисекунды задержки. Не так уж и плохо. Делаем такт системы в 10 мс и нормально так разруливаем в реальном времени 100 килобайт данных за такт. Т.е. аккурат по килобайту с устройства за 10 мс. А это оцифровка 100 Кгц 8-битного сигнала с каждого сенсора. Очень мощно получается.
Тут надо помнить, что в системах с жёстким риалтаймом применяют time-triggered протоколы. Т.е. никаких коллизий быть не может. Тот же TT CAN или EtherCAT.
Про сложность T1 не знаю что вы имеете в виду. Ну да там есть диагностика повреждений с вычислением дистанции до повреждения. Но я за такую сложность обеими руками бы голосовал. Сложность - это когда проприетарный протокол и без исходников.
Да, и адресация нужна всегда. Если вам кажется что её нет, значит её кто сделал вместо вас.
Вот интересно, если на шине цепочкой висит сотня таких девайсов, и все они работают по сути как повторители (сигнал ходит не напрямую от края до края шины), то при скорости среды в 10 Мбит/с, какова будет реальная скорость обмена между первым и последним узлом.
Сильно зависит от протокола. Напрямую. количество узлов в цепочке влияет только на RTT, но не на пропускную способность.
Так по первой ссылке-то переходник с T на T1L. Ставите два таких на длинную линию, и вот у вас связь на полтора километра с разъёмами типа T с обоих сторон.
Так по первой ссылке-то переходник с T на T1L. Ставите два таких на длинную линию, и вот у вас связь на полтора километра с разъёмами типа T с обоих сторон.
Если бы у нас была задача передать данные точка-точка на километр, можно было бы просто кинуть оптику. Здесь же идет речь о совсем другой задаче, когда у нас длинная линия и множество узлов, рассредоточенных по этой линии. Ваш переходник эту задачу не решает.
Да, один единственный провод длиннее 25 метров не вытянуть. Это нормально для Ethernet, в том же классическом 100BASE-TX тоже есть ограничение на длину провода - 100 метров (и всего два узла, вот же сволочи!).
Но это не означает, что больше устройств подключить невозможно. Надо просто отказаться от идеи-фикс садить абсолютно все устройства на один провод, и поставить нужное количество коммутаторов. Точно также как это делается в нормальных сетях. И вовсе необязательно чтобы у этого коммутатора все порты были 10Base-T1, думаю если поискать то найдутся мосты и в обычную сеть (собственно, ради них же протокол и делался). А значит - вы вообще не ограничены в технологиях, можете хоть оптику на километры кидать, хоть радиомосты строить, хоть через VPN облачную АСУ подключать (если хочется приключений с нестабильной связью, му-ха-ха).
Но это не означает, что больше устройств подключить невозможно. Надо просто отказаться от идеи-фикс садить абсолютно все устройства на один провод, и поставить нужное количество коммутаторов. Точно также как это делается в нормальных сетях.
Пфф... В нормальных промышленных сетях шины могут идти на километры. С вашим подходом вы как затраты на СКС увеличиваете минимум на порядок, так еще и абсолютно лишние коммутаторы нужно ставить.
Коммутаторы не лишние, а необходимые. Если у вас 10Base-T1 более чем на 7 устройств - у вас будут коммутаторы, это данность. И их наличие - не обязательно плохо,
Затраты - да, затраты надо считать.
Коммутаторам еще и питание нужно, и подводить его в разных местах вдоль шины - тот еще геморрой. Обычно потребителям на шине достаточно трёх незадействованных пар кабеля, чтобы подать питание по ним, соответственно, нужны низковольтовые (12-36В) коммутаторы, которые умеют питаться от той же шины и одновременно потреблять достаточно мало, чтобы на длинной высокоомной шине не просаживать напряжение ниже уровней, которые могут вытянуть импульсники (сомневаюсь, что это вообще возможно).
Но не тому, кто с автопромом работает, там еще долго оно будет жить :)
Обзор Протокола ISO-TP [ISO 15765-2]