Comments 32
За лицензию платить не надо, т.к. за нее уже заплатил производитель чипа.
Если бы подобная технология хорошо работала в ответственных приложениях, то она там повсеместно применялась, но такого нет.
Хотелось бы понять почему Token Ring не «выстрелил» и что предпринято в Ethercat, что бы не повторить его судьбу?
Я искал решение для систем связи где в описании требований применяются слова «троирование» и многие другие непотребства.
Если есть желание почитайте результат размышлений: habr.com/ru/post/512652.
Ethercat проще, с Ethernetом совместим лучше и не пытается с ним конкурировать — это не одноранговая сеть, а сеть с одним мастером. Соответственно мастеру не надо ждать токена и как-то вклиниваться, он просто отправляет ethernet\udp пакет в котором предусмотрено место для всех ожидаемых ответов.
С теоретической стороны конечно можно спорить что эффективнее, мы и сами до знакомства с Ethercat обсуждали идею сделать «кольцо» на базе двухпортовых ethernet-свитчей, но с чисто практической стороны Ethercat удобнее т.к. уже работает. Хотя и вендорлок.
Еще вопрос: EtherCat можно использовать в критически важных узлах самолета, ракетной техники и тд?
Если нет то планируется ли их получить и есть ли перспективы получения таких разрешений (соответствует ли требованиям).
В нашей области в обозримом будущем грядет требование сертификации по SIL3 (1 отказ на 10млн. часов т.к. отказ связан с риском для жизни людей). Но с этой стороны проблем вроде нет (исключительно мое мнение т.к. мы пока сертификацией не занимались) — свитчи Beckhoff на SIL3 сертифицированы, а скорость обмена достаточна чтобы в случае отказа аварийно отрубить питание.
Думал я об апгрейде самодельного ЧПУ-станка с использованием EtherCAT. Со слейвами все очень красиво: есть доступные драйверы как шаговых, так и серво-двигателей, есть даже двигатели со встроенным энкодером и драйвером. А вот с управляющим устройством начинается веселье. Решение, для которого доступна хоть какая-то документация — LinuxCNC, но его сборка та еще история (например, тема на форуме LinuxCNC про EtherCAT HAL driver — 95 страниц обсуждения). Можно попытаться воспользоваться Mach4+Kingstar, но документация без покупки всего этого не очень доступна. В общем, технологически, это чудесный интерфейс, если у вас есть деньги на промышленные решения и задача написать все самому (всяких SDK как раз достаточно).
бекофовские модули для этого лучше подходят, в них крепежные отверстия есть, а вот это у автора только на столе побаловаца.
А дальше мы берем используемый в них чип (XMC4800) и разводим свою плату.
а со стороны ПК есть какие-нибудь альтернативы twinCATу?
Можно и ручками, но ведь twinCAT это не только ethercat master, но ещё и какой-никакой реалтайм, без него смысл ethercatа как-то теряется.
Тем более что, я так понимаю, ручками тяжело будет какой-нибудь готовый беховский же модуль, например, сервопривода запустить, описания низкоуровневых внутренностей поди нету?
Из готового модуля можно по CoE прочитать какие у него есть регистры (точнее то что твинкат назвает мейлбоксами). Достаточно ли этой информации будет для того чтобы запустить модуль не знаю, я и в TwinCAT то дальше списка мейлбоксов не ушел.
реальное оборудование само подхватываеца, добавляете цнц таск с простейшей задачкой и гоняеете пакеты.
насчёт альтернативы это не про сложность, а про проприетарщину.
есть ли что-нибудь вроде rtx64, может rt-xen (он там живой вообще?) которым можно (без особых плясок с бубном) на х86 полностью откусить несколько процессорных ядер и отдать их целиком какому-нибудь примитивному freedos :), freertos или embox для реалтайма, но и при этом иметь на оставшихся ядрах процессора рядом и нереалтаймовый "условный виндоус" для гуя и/или сети с вебмордой наружу.
Ну сетевые карты из определённого списка не самая большая проблема, тем более что и с какими попало картами работать тоже как-то должно с немного большим джиттером, если время цикла какие-то милисекунды, то лишние десятки мкс тупости в сетевой карте не особо испортят "реалтайм".
с МК не всё так просто, если там ещё с другой, пользовательской, стороны всякого говна навешано: tango/tine, ads беховский и вообще твинкатовский гуй которым через remote desktop иногда для всяких сервисных вещей пользуются, всё в МК тащить (пилить аналоги) устанешь.
Можно конечно разделить и оставить нереалтаймовую "hmi" часть в ПК, а реалтаймовую вынести в МК, и как-то склеить, но на фоне этих "велосипедов" даже twincat под виндовсом выглядит уже не так страшно.
Да вроде даже ниже, то есть винда свалившаяся в синий экран, по утверждениям, не означает смерть твинката, ну в каких-то разумных пределах пожалуй.
Про какие попало карты есть только предположение, что они пакеты не отдают пока целиком не примут, соответственно отсюда и небольшие дополнительные задержки.
А вы в своем проекте использовали CoE, и возможно, другие высокоуровневые протоколы или вы собственные протоколы прямо поверх EtherCAT делали?
EtherCAT предполагает последовательное соединение слейвов (если у слева два порта — вход и выход), но если нарушить связь между первым и вторым слейвом, то отвалятся все последующие 10050 слейвов — это нормально для АСУТП?
CASE 1 и CASE 3 будут работать, в CASE 2 будет многократное отражение пакетов (пакет с мастера ушел на первый и второй девайс, вернувшиеся от них ответы ушли на мастер и соответственно на второй и первый девайс, ответы на ответы еще раз ушли на мастер и на другой девайс) и работать не будет.
Насчет второго вопроса - в каких-то случаях это допустимо, там где это недопустимо EtherCAT предлагает концепцию redundancy. Для этого мастер должен иметь два PHY - тогда выход последнего слейва заводим на мастер и в случае обрыва он будет опрашивать сеть с двух сторон - "с начала" и "с конца".
есть разница — hub/switch/router?
Ethercat для начинающих