Доброго времени суток, хотелось бы узнать от людей, которые пользовались интерфейсом EtherCAT и могут помочь студенту в решении некоторых вопросов, т.к. в рунете информации как таковой я не нашел:
1) Чем вообще примечателен данный интерфейс, какие у него есть конкуренты, плюсы и минусы их?
2) Как он реализуется? хотелось бы услышать о его реальной производительности, а не о том, что написано в по большей части рекламных брошюрах от производителя.
3) за счет чего он принципиально лучше CAN-шины?

Микроконтроллеры с EtherCAT имеют всегда два интерфейса Ethernet и аппаратный мост между ними.
Пакет пришедший в один интерфейс Ethernet сразу же без задержки передается во второй.
Если микроконтроллер имеет что передать в этом пакете на лету подставляется нужный фрагмент данных в нужное место.
Т.е. при любой нагрузке время реакции гарантировано.

В CAN-е же плотный поток приоритетных пакетов может наглухо забить канал. А равных приоритетов в CAN-е не бывает.
Поэтому CAN не подходит для систем с жестким реальным временем.

спасибо. А существуют ли какие-нибудь конкурентоспособные аналоги EtherCAT'у? И какие недостатки существуют у езерката?

Нужно городитиь что-то на ПЛИС или использовать контроллеры тип AM335x с PRU.
И именно поэтому он не так сильно распространён. ИМХО.
А так каждый вендор чего-то своё старается пропихнуть. Посмотрите что сейчас продвигает Сименс, Роквел...

Т.е. это реалтайм езернет?
Ведь в обычном езернете время реакции не может быть меньше нескольких миллисекунд ( а порой десятков миллисекунд), а в etherCat время реацкии может быть 1 микросекунда.
Кроме того, там вроде нет арбитража шины методом слуяайного доступа. Поэтому время доставки пакета там гарантировано маленькое.
Бекшофф в основном занимается и продвигает этот протокол, в основном используемый для построения сверхбыстродействующих систем управления
Никто не юсает что ли EtherCAT в своих проектах?

нешовсем так.
бецкофф продает готовые чипы.


я даже отладошную плату пыталсо юзать


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

ща глянул, они уже предлагают ип-ядра для фпга https://www.beckhoff.com/english/ethercat/e...m?id=3557177466

те кто юзают, берут целиком всю эту беховщину с их же промышленными компами на виндовсе и twinCATом.

ну а вообще такой token-ring, реалтаймовый, когда пакет тупо насквозь проталквается с дописыванием данных от кого надо, разве нельзя реализовать без спец чипов на любом процессоре? интерфейс-то физически один обычный езернет, тупо пришедшие данные перекладывай из rx в tx, дописав своё, если надо.

вот вроде обычные intelовские сетевые карточки бехофом как etherCAT compatible объявлены.
http://infosys.beckhoff.com/english.php?co...kcontroller.htm

Тоже об этом подумал.
Почему никто кроме Bekshow не догадался сделать реал-тайм езернет и уменьшить latency time с миллисекунд до микросекунд?

Ведь он в АСУТП очень востребован

Не так, чтоб никто
https://en.wikipedia.org/wiki/PROFINET

делайте на uart`ах



т.е. мы ещё не знаем, что нам придёт, но уже знаем, что должны там заменить ?

RT (real-time) protocol for PROFINET CBA and PROFINET IO applications[2] up to 10 ms cycle times
IRT (Isochronous Real-Time) for PROFINET IO applications in drive systems[2] with cycles times of less than 1 ms

Ни о каких единицах микросекунд "Latency Time" и речи нет.
В лучше случае около миллисекунды. В лучшем.
А там в среднем 10 мс.
А это уже ни в какие ворота не лезет.
Такие тормоза

50 килопакетов где-то получается, а это 20us
теоретически ещё больше
так что не меняйте ничего в пакетах, просто прокидывайте их со входа на выход физикой и всё у вас будет хорошо

20 мкс - много. Хотелось бы времени реакции микросекунды и доли микросекунд.
Наверное для этого нужен 10 Гбит езернет?

не знаю, но если исходить из гигабитного, то нельзя - будет только медленнее, чем сотка

у езернета, с синхронизацией, адресами, црц, и 12 байтами паузы минимальная длина пакета 84 байта, 0.67мкс на гигабите. и 0.067 на 10.
только вот зачем для этого именно езернет?
для 100МБитного etherCATа хоть какая-то совместимость с человеческим езернетом еще имеет смысл, а вот на 10Г, да с суб мкс временами, уже как-то не очень.

неправда, первый короткий пакет на гигабите будет дополнен нулями до продолжительности стомегабитного - никакого выигрыша

А если использовать тольку "физику" 10-гигабитного езернета а протокол самому написать?
Как бекшофф сделал.

Просто, к примеру нужно опросить сотню территориально разнесенных датчиков за 100 мкс.
Обычный езернет это вроде не повзоляет сделать. Готь 1Г хоть 10Г. Так?
Может использовать беспроводной езернет?

при full duplex зачем что-то дополнять?


если там пару байт с датчика, то это всего 2мбита, token-ring можно и из rs422 устроить.
или даже из полудуплексного rs485 (что для сильно разнесённых датчиков на 2мбитах уже не очень), когда каждый датчик с адресом N начинает говорить сразу как увидел что N-1 всё что хотел сказать - сказал.

на сколько разнесённых ?



чтобы обеспечить прежний размер сети

точка-точка, из двух устройств?

есть стандарт, ничего, что его пытаются соблюдать ?

Стандарт не обеспечивает возможность опросить 100 удаленных узлов за 100 мкС.


Во-первых 2 байта в микросекунду - это 20...50 Мега бит в секунду, а не 2. В зависимости от способа кодирования, числа и длительности СТАРТ/СТОП-ных битов и т.п.
А во вторых, для систем управления важен не Baudrate (я же не видео хочу гонять по сети), а Latency Time


Т.е. в системах управления быстропротекающими процессами терабайты гонять по сети не нужно.
Там самое важное быстрый отклик. Т.е. чтобы уже через микросекунды после сбоя или аварии в распределенной системе эта инфа уже обрабатывалась в главном вычислителе и принялись меры по их устранению


От 5 до 100 метров
P.S. Я в курсе что сигнал не может распространяться быстрей скорости света и поэтому невозможно узнать через 1 мкс об аварии, произошедшей на расстоянии 1 км

да, с мбитами промазал.

ну тогда действительно брать физческий уровень от езернета, и делать из него либо token ring, либо одну шину half duplex и свой "CSMA", с синхронизацией, когда получив пакет от мастера все начинают отвечать строго по очереди без пауз не машая друг другу.

И я также в курсе, что не смотря на то, что находясь на 300 метров от центрального процессора, невозможно ему сообщить об аварии быстрей чем за 1 мкс, но при этом можно ему передать время обнаружении аварии с точностью до наносекунд

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

Выбор не нужен. Ибо одно от другого не зависит

точное время можно получить штатными средствами, а с откликом едва ли в 10 мкс уложитесь, т.е. потребуются иные

А может сделать как в КАНе?
Когда датчик сам может без запроса начать "отвечать" если у него есть важная инфа?


Я к тому, что точное (до наносекунд) время и время реакции никак не связаны


Свет проходит 100 метров за 0,3 мкс

когда захочет, если линия свободна


не связаны, пока вы их физикой не свяжете


а пакет за сколько ?

Я в смысле изменить дисциплину доступа к шине. Сделать её как в CAN



Не понял


Зависит от длины пакеты.
Если в пакете 100 бит то при скорости 10 Гигабит - (10 нс + 0,3 мкс) = 310 нс

тогда возьмите какую-нибудь фпга и напишите свой протокол на базе гигабита

Я просто FPGA давно не занимался. Лет 15. Они ужн могут работать на Гигагерцах?

А "нюхачи"(пассивные снифферы) и "анализаторы протокола" существуют доставабельные в природе? А то как тестить и отлаживать EtherCat сетку ума не приложу

И как "приёмо-сдаточные" устраивать?

Мне EtherCAT очень нравится - мы его используем уже года три. Используется как расширяемые I/O для нашего контроллера в шкафах. Перелезли на него с Profibus, Profinet и своего зоопарка протоколов. Позволило нам поднять скорость опроса с 1мс до 100мкс и сравнять ее со скоростью нашего процесса, выполняющегося в реальном времени каждые 100мкс - т.е теперь управляющий процесс получает новые данные и отправляет контрольные команды каждый цикл. Все это также стало возможно за счет того, что EtherCAT мастер оказался настолько простой, что мы смогли его в сунуть в сам процесс и он выполняется тем же планировщиком, что и программа. Стеки для других протоколов типа Profinet, гораздо сложнее и требуют прерываний или отдельного процесса, а это уже проблемы с синхронизацией.
Между шкафами - пластиковая фибра - дешевая и легко обжимается на места. Для нашего контроллера мы по спецификации и на базе какого-то opensource написали EtherCAT мастер с очень примитивным набором команд. А в качестве I/O используем Beckhof, Wago или Phoenix.
Мы также в одном из наших контроллеров реализовали Slave - он был на ПЛИС и мы просто взяли IP Core для Xilinx и всунули его. На МК, я так понимаю не стоит пробовать, так как весь смысл, что в Slave обработка фреймов должна быть "на-лету". Он должен вставлять свою инфу прямо в фрейм.

Для меня критические преимущества:
- Стандартный EtherNET порт на мастере. Никаких адаптеров, изоляторов и прочей фигни.
- Скорость и реалтайм - мы работаем на цикле 100мкс, количество сигналов доходит до 1000, аналоговых и цифровых. Скорости достаточно, чтобы мерить переменное напряжение в сети и получать 200 отсчетов за период - достаточно, чтобы определить RMS или дисбаланс фаз. Для аналоговых каналов используем distributed clock, чтобы синхронизировать захват между разными модулями - легко реализовалось и работает.
- Встроенная изоляция Ethernet порта - т.е. никаких проблем с гальванической связью. Как говорил, между шкафами используем пластиковую фибру.
- Реализация мастера очень простая для программиста и контроллера.


По поводу отладки. На мастере просто запускаете Wireshark и смотрите пакеты на нужном порту. Он EtherCAT распознает из коробки.

Также мне понравился т.н. EtherCAT Simulator - в Twincat можно промоделировать слейвы для мастера и даже их логику. Оно правда на 100мкс не работает - не хватает скорости компа, а только на 1мс, но бесплатно и довольно эффективно позволяет отлаживать проги в мастере, без подключения к реальной шине и реальных слейвов. А за счет PLC логики можно даже моделировать внешние сигналы, которые в реальном проекте через EtherCAT приходят и уходят.

Еще я заметил, что готовые EtherCAT slave I/O дешевле аналогичных для Profinet или Modbus TCP.


Ethercat на 100мбит это сделает спокойно. Только latency будет 100-300мкс, в зависимости от настройки.


Ну и прикол EtherCAT в конце концов в том, что он сразу одним махом решил многие проблемы расширения I/O в распределенных системах, включая софт, скорость, латентность, выбор топологии, гальваническую развязку, дешевизну портов и кабелей, надежность. Поэтому буржуи его сейчас вовсю используют, а Beckhoff купается в деньгах.

Блок PRU-ICSS в некоторых Ситарах знает про EtherCAT. Вроде в последних вариантах скорость до гигабита.

однако код слейва лицензируемый

(маленькое уточнение: PRU-ICSS - обычная машина, ничего она ни про кого не знает. Однако у неё есть доступ к периферии, достаточный для фёрмварьной реализации много чего,
в т.ч. EtherCat, Profinet, 3+Mbit UART, IPMB-0 .., даже слабый видепоток некоторые грабят)

Для понимания своего вопрос. Почему не рассматривается применение IEEE1588?

EtherCATу необходима физика с поддержкой IEEE1588.

Мой вопрос был о возможности использовании IEEE1588 вместо EtherCAT для решения поставленной ТС задачи, а не вместе.

Т.е. Вам управлять огромным кол-вом исполнительных механизмов с маленькой латентностью, обеспечиваемой EtherCAT, не надо?
Вам нужно чисто обеспечить единое время во всех узлах системы?

Да. Желательно до 0.1мс. Меньше - лучше. И каналов Ethernet у меня в цепочке до 4-5-ти.

Ну тогда EtherCAT остается без вариантов.
И для синхронизации использовать упрощенную версию протокола IEEE1588.

Вот это и непонятно. Где бы почитать (на любом языке)?

Наша сфера - контроллер, а не I/O к нему. Поэтому при выборе интерфейса была задача использовать покупные индустриальные модули для различных сигналов -24/48/220В реле, термопары, 4-20мА и прочие стандартные сигналы.. И как оказалось, выбор I/O для EtherCAT сейчас достаточно широк - Beckhof, Wago, Phoenix - выбирай по вкусу и цене. И по цене они тоже сейчас оказываются дешевле аналогичных ProfiNetовских или Modbus TCP.

Цитата

© Гуголь

И все-таки кто кручи?
EtherCAT, SERCOS III или POWERLINK?

И тишина.
Почему-то на этом форуме про EtherCAT только одна тема. Эта. И то в ней никто не пишет.
Это очень странно учитывая что это самый тренд сейчас и что в мире происходит сейчас ТОТАЛЬНЫЙ перевод всего и вся на эту технологию.

Не нашел в форуме больше тем про реал-тайм Ethernet поэтому решил задать вопрос в этой.
Дело в том, что я колеблюсь в выборе протокола реал-тайм езернета для проектируемой АСУТП.
Проектируем быстродействующую АСУТП и стоим перед выбором: "какой же протокол реал-тайм езернета лучше использовать?"
Перелопатил весь инет, но все равно не могу однозначно выбрать. Есть сомнения и колебания.

Выбор свелся к 5-ти технологиям:
1) EtherCAT
2) SERCOS III
3) Ethernet powerlink
4) EtherNet/IP
5) PROFINET IO
Из своего опыта что посоветуете?
Или наоборот НЕ советуете использовать?

Что нужно получить.

За один цикл работы ПЛК должен по одному кабелю произвести:
1) Опрос около 270 аналоговых датчиков, состояние которых характеризуется 2-х байтовым числом типа INTEGER + около 400 дискретных датчиков (концевые датчики положения), состояние которых описывается одним битом ("замкнуто/разомкнуто", "ВКЛ/ВЫКЛ"). Ну, точнее не датчиков, а удаленных УСО, подключенных через Etyernet к ПЛК.
2) Выдать код ЦАП на около 30 аналоговых выходов (модуль аналогового вывода)
3) Послать команды типа "включить/выключить" на около 500 дискретных выходов (токи до 5 Ампер) с Latency Time не более 0.2 мс (модули дискретного вывода)

При этом очень желательно:

4) Чтобы протокол "долго жил" (поддерживался ещё лет 10 как минимум производителями железа и разработчиками софта)
5) Чтобы можно было потом "бесшовно" переходить со 100Мбит-ной сетки, на 1Гбит и далее на 10Гбит не меняя идеологию систему и не переделывая радикально софт АСУТП
6) Чтобы относительно легко было делать резервированные конфигурации (дублирование, троирование)

P.S. Эту статью читал естественно.
Как и множество других. Информации много. Но все равно не могу остановится на чем-то одном.
Помогите определиться с выбором. Кто реально работал с протоколами RT Ethernet.
Расскажите о своем опыте использования протоколов RT езернета на практике

Молодцы.
Это вы сделали в чем я сейчас "плаваю" и "тону"...
Можно в сырцы взглянуть? Что использовали за основу мастера и что почистили?
Интересен так же Slave и его реализация в FPGA - можно то же взглянуть?

Еще вопросы в догонку:
1) Мастер в Twincat EtherCAT Simulator использует стандартный порт Ethernet на PC? Есть к нему какие либо требования?
2) Slave как эмулируется на PC - что для этого надо (физика)?
3) Что за IP Core для Slave можно его где-то найти (понимаю, что платный ?