Расскажите про EtherCAT Опции

[Jagdhund]

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

[AlexandrY]

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

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

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

[Jagdhund]

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

Сообщение отредактировал Herz - Dec 18 2015, 13:59

Причина редактирования: Избыточное цитирование

[demiurg_spb]

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

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

[Флюктуация вакку...]

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

[Siargy]

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

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


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


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

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

[_pv]

Никто не юсает что ли EtherCAT в своих проектах?

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

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

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

[Флюктуация вакку...]

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

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

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

[Corvus]

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

[Огурцов]

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

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

насквозь проталквается с дописыванием данных

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

[Флюктуация вакку...]

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

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
теоретически ещё больше
так что не меняйте ничего в пакетах, просто прокидывайте их со входа на выход физикой и всё у вас будет хорошо

Сообщение отредактировал Огурцов - Dec 18 2015, 00:17

[Флюктуация вакку...]

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

[Огурцов]

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

[_pv]

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

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

[Огурцов]

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

Сообщение отредактировал Огурцов - Dec 18 2015, 12:43

[Флюктуация вакку...]

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

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

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

[_pv]

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

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

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

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

[Огурцов]

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

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

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

[_pv]

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

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

[Огурцов]

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

[Флюктуация вакку...]

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

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

если там пару байт с датчика, то это всего 2мбита

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


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

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

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

Сообщение отредактировал Флюктуация ваккума - Dec 18 2015, 17:30

[_pv]

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

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

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

[Флюктуация вакку...]

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

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

Сообщение отредактировал Флюктуация ваккума - Dec 18 2015, 17:35

[Огурцов]

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

[Флюктуация вакку...]

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

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

[Огурцов]

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

[Флюктуация вакку...]

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

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

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

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

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

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

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

[Огурцов]

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

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

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

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

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

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

Сообщение отредактировал Огурцов - Dec 18 2015, 18:35

[Флюктуация вакку...]

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

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

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

Не понял

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

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

Сообщение отредактировал Флюктуация ваккума - Dec 18 2015, 18:52

[Огурцов]

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

[Флюктуация вакку...]

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

[Флюктуация вакку...]

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

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

[syoma]

Мне 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 порта - т.е. никаких проблем с гальванической связью. Как говорил, между шкафами используем пластиковую фибру.
- Реализация мастера очень простая для программиста и контроллера.

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

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

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

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

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

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

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


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

[gosha-z]

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

[svss]

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

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

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

[Myron]

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

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

[BloomJack]

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

[Myron]

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

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

[bbb]

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

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

[Myron]

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

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

[bbb]

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

[Myron]

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

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

[syoma]

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

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

[bbb]

Синхронизация процесса EtherCAT
При каждом соединении с ведомым устройством передается тактовая частота реального времени, которая синхронизируется ведущим устройством с помощью методов, подобных описанным в стандарте IEEE 1588. Существуют ведомые устройства как с механизмами реального времени, так и без них, поскольку такие механизмы очень требовательны к оборудованию. Тактовая частота реального времени позволяет с высокой точностью синхронизировать управляющие сигналы. В физическом смысле протокол EtherCAT работает не только поверх Ethernet, но и поверх LVDS (низковольтная дифференциальная передача сигналов). Этот стандарт используется компанией Beckhoff в качестве внутренней шины терминалов. Обычно в роли ведущего устройства EtherCAT используется стандартный ПК с интерфейсом Ethernet. В отличие от других протоколов, таких как POWERLINK или PROFINET, EtherCAT распространяется на уровни с 1 по 3 семиуровневой OSI-модели. Поэтому для достижения функциональности приложений, сравнимой с другими системами, приходится использовать дополнительный уровень протокола (CoE, EoE).

© Гуголь

Сообщение отредактировал bbb - Mar 9 2016, 16:37

[bbb]

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

[bbb]

И тишина.
Почему-то на этом форуме про 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 езернета на практике

Сообщение отредактировал СНБ - May 2 2016, 14:41

[Make_Pic]

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

...
- Реализация мастера очень простая для программиста и контроллера.
...

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

[Make_Pic]

...
- Стандартный EtherNET порт на мастере. Никаких адаптеров, изоляторов и прочей фигни.
...
Также мне понравился т.н. EtherCAT Simulator - в Twincat можно промоделировать слейвы для мастера и даже их логику.
...

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

[gosha-z]

Только что привалило от техасцев.

[СНБ]

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

1) Вроде как да. В рекламных проспектах пишут, что Вам не нужно какое-то особенное железо для реализациии мастера. Что, мол, сгодится, обычный комп со стандартной сетевой карточкой.
2) ?
3) Прошивки для ПЛИСин

Сообщение отредактировал СНБ - May 4 2016, 17:01

[Make_Pic]

1) Вроде как да. В рекламных проспектах пишут, что Вам не нужно какое-то особенное железо для реализациии мастера. Что, мол, сгодится, обычный комп со стандартной сетевой карточкой.
2) ?
3) Прошивки для ПЛИСин

1) только с интеловским ethernet-овским чипом.
2)? - Я так понял используется та же физика - обычный ethernet порт на интоловском чипе.
3) Как-то я в беседе со своим босом - французом, говорю обычно разговорно: "используется фпга..." - он не понимет. Тогда я понял в чем дело и повторяю: "используется эф-пи-джи-эй" А вы говорите прошивки для плисин... - И что плисина? Какой в нее IP Core зашивается и где его можно раздобыть без обмена на 10000000 зеленых президентов (возможно open core использовался)?

[СНБ]

Я вообще думаю все же PowerLink заюсать.
У него открыто все. До последнего бита. Он полностью Open Source. И он полностью софтовый. Т.е. никакого специального hardware не потребуется. И в отличии от EtherCAT совместим и с одним гигабитом и с 10Gigabit
А в EtherCAT ( как я понял после беглого чтения доков и и форумов), самые "вкусные" вещи закрыты и даются только за немаленькую денежку

А вообще сейчас хилшер производит универсальные сетевые платы, в которых ты можешь использовать ЛЮБОЙ реал-тайм езернет протокол. Для этого достаточно просто перепрошить ПЛИСину. Прошивки на диске идут в комплекте вместе с сетевой платой.

Сообщение отредактировал СНБ - May 5 2016, 16:11

[romasv]

самые "вкусные" вещи закрыты и даются только за немаленькую денежку

денежку просят бешеную( в связи с чем у меня вопрос: есть какие-то решения кроме TwinCAT и EC-WIN от аконтиса, позволяющие поднять реалтаймовый эзеркат под виндой?
пытаюсь сейчас на raspberry pi поднять ethercat-master, но как-то оно очень сомнительно, очень мало инфы и опыта. Если кто-то подскажет советом, буду очень благодарен)

[syoma]

пытаюсь сейчас на raspberry pi поднять ethercat-master, но как-то оно очень сомнительно, очень мало инфы и опыта. Если кто-то подскажет советом, буду очень благодарен)

По поднятию EtherCAT. Сейчас делаю маленький ПЛК проектик на RPI 3 + EtherCAT. На Rpi стоит Codesys Runtime. Из EtherCAT стоит EK1100+EL2008,EL1008,EL2602, EL3202. Контроллер измеряет температуру, исполняет PID контроллер, крутит сервоклапанами, опрашивает кнопки, показывает и управляется через встроенный Вебсервер, добавлю еще Modbus TCP slave. Все в цикле 4мс.
Запустилось все очень быстро по туториалам. EtherCAT модули понасобирал на Ebay по 30€.

[_pv]

а свои устройства на LAN9252 тут случайно никто не делал?

[AlexandrY]

По поднятию EtherCAT. Сейчас делаю маленький ПЛК проектик на RPI 3 + EtherCAT. На Rpi стоит Codesys Runtime. Из EtherCAT стоит EK1100+EL2008,EL1008,EL2602, EL3202. Контроллер измеряет температуру, исполняет PID контроллер, крутит сервоклапанами, опрашивает кнопки, показывает и управляется через встроенный Вебсервер, добавлю еще Modbus TCP slave. Все в цикле 4мс.
Запустилось все очень быстро по туториалам. EtherCAT модули понасобирал на Ebay по 30€.

С фотками было бы информативней. Не думаете?

А вот начало моего монстра


Будет 10 EtherCAT каплеров, цикл 1 мс на мастере.
Не менее 60 контроллеров вводы-вывода, из них 20 будут Safety контроллеры.
Интересно есть ли в Codesys Runtime поддержка FailSafe over EtherCAT. А то без этого на серьезные объекты не сунутся.

[syoma]

С фотками было бы информативней. Не думаете?

Могу выложить, когда сделаю.
Только зачем? В сети полно видео, как это выглядит https://www.youtube.com/watch?v=x4ePFqxqTfY
Причем с RPI 3 стало еще проще, так как там для общения со средой уже есть Wi-Fi на борту, а EtherCAT подключается к проводному Ethernet порту.

[AlexandrY]

В сети полно видео, как это выглядит https://www.youtube.com/watch?v=x4ePFqxqTfY

Понятно, RPI 3 в принципе не может поддерживать FailSafe over EtherCAT.

[syoma]

Понятно, RPI 3 в принципе не может поддерживать FailSafe over EtherCAT.

Если бы вы еще обьяснили, почему без FSoE нельзя сделать серьезные проекты, было бы неплохо. С RPi и так понятно, что он в основном годится только под тестовые проекты - там и Рантайм несильно реалтаймовый получается.

[Make_Pic]

Могу выложить, когда сделаю.
Только зачем? В сети полно видео, как это выглядит https://www.youtube.com/watch?v=x4ePFqxqTfY
Причем с RPI 3 стало еще проще, так как там для общения со средой уже есть Wi-Fi на борту, а EtherCAT подключается к проводному Ethernet порту.

Я PC подключил через USB-TPLINK Ethernet переходник/

Если бы вы еще обьяснили, почему без FSoE нельзя сделать серьезные проекты, было бы неплохо. С RPi и так понятно, что он в основном годится только под тестовые проекты - там и Рантайм несильно реалтаймовый получается.

Если конечное устройство поддерживает этот профиль, например частотник, то возможно безопасное выключение или перевод в безопасное состояние. Если TV-ящик смотрите, то наверно видели как в Китае сбесился эскалатор в метро. Это как раз та тема.
Я все это решаю аппаратным WDT для оконечного контроллера -устройства.
P.S. Быстродействия Rpi мне хватает для моих задач.

[syoma]

С фотками было бы информативней. Не думаете?

Вот фотка ящика. RPI в белом корпусе слева.

[AlexandrY]

EtherCAT тут выглядит слегка притянутым за уши.
EtherCAT это все таки дорогая технология.
И юзать её при количестве IO меньше 100 довольно затратно.
Я б в такой ящик поставил бы что нибудь более гибкое и современное типа CAN FD.
А CAN и к топологии сети менее критичен, можно использовать без транспортных протоколов, и дешевле обвязка, и надежность передачи выше.

[syoma]

EtherCAT это все таки дорогая технология.

Гы. Вот тут вы заблуждаетесь, как и многие другие. Посмотрите на стоимость стандартных промышленных I/O модулей для EtherCAT и для других стандартных интерфейсов - Modbus TCP, Profibus, CANopen - от тех же производителей Beckhof, Wago, Phoenix, Weidmuller. EtherCAT просто дешевле! В сочетании с дешевыми и простыми кабелями и отсутствием специальных требований к Мастеру(просто Ethernet Порт) это и делает EtherCAT сейчас мегапопулярным - его есть смысл использовать просто везде в стандартной автоматизации. Ну и быстродействие, как бонус.
Я после данного эксперимента собираюсь во всех своих стендах использовать только EtherCAT.

[AlexandrY]

Я после данного эксперимента собираюсь во всех своих стендах использовать только EtherCAT.

Насчет перекоса цен у брендов согласен. EtherCAT и у OMRON-a дешевле.

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

Во-вторых вот сейчас столкнулся я в своем распределенном проекте, вам нужно специально покупать Ethernet Coupler-ы для своих IO.
А что если на одном их них отключится питание? У вас падает вся сеть!
В CAN-е такого не бывает. CAN будет продолжать работать.
САN можно вставить в микроскопические дивайсы, он не требует трансформатора и монструозного ненадежного разъема, гальваноизоляторы для CAN более электрически прочные.
CAN можно ответвить по любой лапше.

Нет, для проектов уровня вашего ящика CAN лучший выбор.

[syoma]

А что если на одном их них отключится питание? У вас падает вся сеть!

В EtherCAT есть Cable Redundancy. Второй Ethernet порт на Мастере и Ethernet пакеты начинают двигаться в обоих направлениях и снимается проблема не только питания Ethernet Couplerа а и обрыва кабеля.

В CAN-е такого не бывает. CAN будет продолжать работать.
САN можно вставить в микроскопические дивайсы, он не требует трансформатора и монструозного ненадежного разъема, гальваноизоляторы для CAN более электрически прочные.
CAN можно ответвить по любой лапше.

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

[AlexandrY]

это единственный экземпляр, заточенный под конкретный проект, а не серийный продукт.

Странная заточенность с применением IO модулей без родных ПЛК.

[syoma]

Странная заточенность с применением IO модулей без родных ПЛК.

На то он и стандартный протокол, чтоб работал с любыми ПЛК, а не только Beckhoff. Ethercat сейчас поддерживается почти всеми ПЛК

[gte]

На то он и стандартный протокол, чтоб работал с любыми ПЛК, а не только Beckhoff. Ethercat сейчас поддерживается почти всеми ПЛК

Siemens, Rockwell, Mitsubishi, ABB, Bosch-REXROTH?

Цитата с форума АСУТП:

PROFIBUS International (PI) Organization - стандарт PROFInet - около 1200
членов.
ODVA - стандарт EtherNet/IP - 264 члена, из них пятая часть и в PI.
MODBUS.ORG - стандарт MODBUS TCP - 19 членов.
EPSG - стандарт ETHERNET POWERLINK - 27 членов.
EtherCAT Technology Group - стандарт EtherCAT - 53 члена.

[syoma]

Gte Вы на дату цитаты смотрели?
Ethercat technology group сегодня

The worlds largest Industrial Ethernet organization with 4200 member companies.

В то время как в Profinet как было 1200 членов, так и сейчас

PI has about 1400 members worldwide.

[gte]

Gte Вы на дату цитаты смотрели?
Ethercat technology group сегодня
В то время как в Profinet как было 1200 членов, так и сейчас

Да, действительно оплошал со ссылкой.
И тем не менее вопрос остался.
Сейчас ПЛК таких фирм как Siemens, Rockwell, Mitsubishi, ABB, Bosch-REXROTH легко работают с периферией Ethercat?
Я только Сименс периодически использую.

[AlexandrY]

На то он и стандартный протокол, чтоб работал с любыми ПЛК, а не только Beckhoff. Ethercat сейчас поддерживается почти всеми ПЛК

Да протокол тут последнее что интересует.
Интероперабельность - вот вопрос.
Откуда берете ESI файлы, откуда знаете что они исчерпывающие, откуда знаете что характеристики быстродействия модулей соответствуют вашему мастеру и т.д.

[syoma]

Сейчас ПЛК таких фирм как Siemens, Rockwell, Mitsubishi, ABB, Bosch-REXROTH легко работают с периферией Ethercat?
Я только Сименс периодически использую.

Точно не знаю. В директории членов ETG они присутствуют, кроме Rockwell. Я работаю с Codesys - там EtherCAT поддерживается. Т.е. все ПЛК на этой системе должны с EtherCAT тоже работать.

Интероперабельность - вот вопрос.
Откуда берете ESI файлы, откуда знаете что они исчерпывающие, откуда знаете что характеристики быстродействия модулей соответствуют вашему мастеру и т.д.

ETG дает четкие ответы на эти и другие вопросы https://www.ethercat.org/en/faq.html#778
За интероперабельностью четко следится. Доступ ко всем спецификациям, исходным кодам мастера открыт любому члену группы. Членство бесплатное.

В моем случае я просто скачал нужный архив с https://www.beckhoff.com/english.asp?download/elconfg.htm и импортировал в Codesys нужные мне описания EK и EL модулей, после чего они распознались в среде.

[gte]

Точно не знаю. В директории членов ETG они присутствуют, кроме Rockwell. Я работаю с Codesys - там EtherCAT поддерживается. Т.е. все ПЛК на этой системе должны с EtherCAT тоже работать.

Вот это уже ближе к истине - те, что используют Codesys. У крупных игроков все больше свои системы.

Когда делали первую систему на Симатик с нуля, без опыта работы с Сименс (S7-300, 100+входов/выходов, ET, графическая панель), без реального железа полгода (параллельно с другой работой) ушло на освоение, написание и отладку. Вся система отлажена в симуляторе вместе с панелью, отлажена реакция программы на сигналы входов/выходов и в результате все запустилось на объекте без дополнительной отладки на реальном железе.

[AlexandrY]

ETG дает четкие ответы на эти и другие вопросы https://www.ethercat.org/en/faq.html#778
За интероперабельностью четко следится. Доступ ко всем спецификациям, исходным кодам мастера открыт любому члену группы. Членство бесплатное.

Ага, как они с бесплатным членством-то будут четко следить?
Позасовывают все кому не лень свою проприетарщину.
Не вижу никаких мотивов тому же Сименсу давать своим контроллерами полнофункционально работать в среде Beckhoff.

[syoma]

Не вижу никаких мотивов тому же Сименсу давать своим контроллерами полнофункционально работать в среде Beckhoff.

Причем здесь среда Beckhoff к Ethercat и Сименсу?

[AlexandrY]

Причем здесь среда Beckhoff к Ethercat и Сименсу?

Потому что без среды программирования нам от этого EtherCAT никакой пользы.
Вы например его использует только потому что имеете CodeSys
А не имей вы его, то отказались бы от EtherCAT еще на этапе знакомства с конфигурационными XML файлами.
Поскольку там черт ногу сломит, один парсинг займет неадекватные ресурсы. После чего еще остается риск нарваться на проприетарные данные.

Я использую EtherCAT только потому что заказчик потребовал цепь безопасности по SIL3, а объект в длину несколько сот метров.
Кстати посмотрим как EtherCAT потянет.

А так ассортимент модулей EtherCAT IO у производителей очень беден, цены на них вздуты, да еще и купить их так просто нельзя, месяц доставка.

[syoma]

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

Как я уже писал в одном из контроллеров нами за основу был взят демо код от ETG и был сделан мастер, которому ни среда программирования, ни XML файлы не нужны.

А так ассортимент модулей EtherCAT IO у производителей очень беден, цены на них вздуты, да еще и купить их так просто нельзя, месяц доставка.

Смотря где. У нас тут они даже на ebay продаются. Есть Beckhof, есть Phoenix, есть Weidmuller, есть Wago. По ценам я уже писал - прежде чем писать про вздутие, посмотрите на цены аналогичных модулей для Profinet или Canopen.

[AlexandrY]

Смотря где. У нас тут они даже на ebay продаются. Есть Beckhof, есть Phoenix, есть Weidmuller, есть Wago. По ценам я уже писал - прежде чем писать про вздутие, посмотрите на цены аналогичных модулей для Profinet или Canopen.

Я бы сравнивал с ардуино, а не с Profinet или Canopen.

[syoma]

Я бы сравнивал с ардуино

Ну покажите мне индустриальный IO модуль Ардуино. Посмеемся вместе.

[syoma]

Наткнулся на неплохую презентацию по EtherCAT, правда от 2012 года.
https://indico.cern.ch/event/201794/attachm...CERN_120920.pdf

[Студент заборстр...]

Возникли следующие вопросы.
1) Так он реально открытый и бесплатный? Или тебе только айсики могут продать в которых УЖЕ ВСТРОЕН код слейва, а сам код для плисины тебе не дадут бесплатно?
2) если каждый слейв вставляет свои данные в пакет "на лету", то получается, что CRC пакета, который получит мастер (после прохождения пакета через все слейвы) будет не верным? Но тогда такой пакет стандартный TCP|IP должен же отклонить? Тогда зачем мастеру в исходном пакете считать CRC зря теряя на это драгоценные такты?

3) А есть у нас в России люди, которые написали "с нуля" код етеркат слейфа для ПЛИСине?
4) Как слейф определяет в какое место "телеграммы" ему вставлять (доставать) данные? Тупо подсчетом числа тактов? А если у меня данные 1500 байт - это же гигантское число тактов будет?
5) Исходя из 4) полчучается, что достаточно испортить 1 бит (в цеху помехи дай божЕ)и вся телеграмма "псам под хвост" и 10000 тысяч устройств не получат команды в данном цикле? Или (что хуже) получат неверные команды? к примеру, вместо "включить клапан" слейв получит команду "выключить клапан" и произойдет катастрофа

Сообщение отредактировал Студент заборстроительного - Dec 30 2017, 09:59

[Студент заборстр...]

Никто не в теме что ли?

[gosha-z]

Возникли следующие вопросы.
1) Так он реально открытый и бесплатный? Или тебе только айсики могут продать в которых УЖЕ ВСТРОЕН код слейва, а сам код для плисины тебе не дадут бесплатно?

Доступность спецификации не означает бесплатность реализации.

2) если каждый слейв вставляет свои данные в пакет "на лету", то получается, что CRC пакета, который получит мастер (после прохождения пакета через все слейвы) будет не верным? Но тогда такой пакет стандартный TCP|IP должен же отклонить? Тогда зачем мастеру в исходном пакете считать CRC зря теряя на это драгоценные такты?

А причем тут tcp/ip? Правильно написанный tcp/ip stack этих фреймов не увидит вообще.

[syoma]

Я бы в первую очередь почитал спецификации EtherCAT. Там должны быть даны ответы по реализации. По поводу открытости и бесплатности - присоединюсь к предыдущему комментатору. Вы можете получить спецификации бесплатно - они открыты. Но тогда вам придется реализовать весь слейв самому. А вот бесплатных слейвов для ПЛИС я не встречал, хотя платные пробовал.

[Студент заборстр...]

Т.е. полностью открытых прошивок для ПЛИС в общем доступе нету?

А причем тут tcp/ip? Правильно написанный tcp/ip stack этих фреймов не увидит вообще.

Т.е. то что мастер примет пакет с покоцанной CRC16 - это ничего?

[Студент заборстр...]

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

А это возможно?
А то в инете разная инфа бродит.
Что якобы все равно пока фирме Bechhoff не отстегнёшь "мопед не поедет", так как есть некторые нюансы, которые не изложены в открытой спецификации.

Почему я и вопрос задал: есть ли тут те, кто сам, "с нуля" написал прошивку для ПЛИС на языке VHDL (или Verilog), реализующую EtherCAT-слейв, который успешно "внедрился как родной" в сеть из покупных EtherCAT устройств, изготовленных фирмой Bechhoff?

Сообщение отредактировал Студент заборстроительного - Jan 2 2018, 11:11

[Impartial]

4) Как слейф определяет в какое место "телеграммы" ему вставлять (доставать) данные? Тупо подсчетом числа тактов? А если у меня данные 1500 байт - это же гигантское число тактов будет?

ЕtherСАТ применяется в промышленных системах управления. Там максимальная длина пакета около 100 байт. И счет идет, действительно, побитно вернее по два, четыре или восемь бит в зависимости от протокола чипа физического уровня. Реализовать слейв можно только аппаратно. А вот мастером может быть любой компьютер. Мастер выбрасывает пакет и задержка его прихода в приемник составляет длину в битах интерфейса чипа физического уровня.

[Студент заборстр...]

Impartial
Скажите, а реализовать слейв с нуля самому реально? Ну, в смысле, имеющейся в открытом доступе инфы достаточно для этого?

ЕtherСАТ применяется в промышленных системах управления. Там максимальная длина пакета около 100 байт.

Не факт.
Сам же Bechkoff пишет об охвате 10000 устройств одной телеграммой. Т.е. пакеты там явно длинней 1000 байт.

И счет идет, действительно, побитно вернее по два, четыре или восемь бит в зависимости от протокола чипа физического уровня.

А если в цепочке 4 слейва и более?
А телеграмма должна пройти СКВОЗЬ них, то в принципе любой из них может "ЗАПОРОТЬ"телеграмму, "сбившись со счета" из-за помех и сбоев тактового генератора.
А если их 4 и более в цепочке, то вероятность этого вырастает многократно.

В связи с этим вопрос: какая практическая надежность EtherCAT в случае 4-х слейвов в цепочке и длине пакета 1500 байт?

Кто-нибудь проводил такие исследования?
Есть инфа по этому вопросу?

Т.е. какой процент битовых ошибок?

И по CRC16 не ясно.
Ведь когда слейвы вставляют свои данные в телеграмму они же CRC пакета не меняют.
Получается, что мастер получает пакет с испорченной CRC?

[SSerge]

Скажите, а реализовать слейв с нуля самому реально? Ну, в смысле, имеющейся в открытом доступе инфы достаточно для этого?

так уже:
http://www.microchip.com/DevelopmentTools/...B-LAN9252-DIGIO
16 цифровых входов/выходов как с куста, на одной микросхеме без контроллеров и программирования.
Для этого случая, полагаю, надёжность будет наивысшая из доступных, поскольку т.н. программисты не могут залезть туда своими немытыми лапками и всё испортить.

И по CRC16 не ясно.
Ведь когда слейвы вставляют свои данные в телеграмму они же CRC пакета не меняют.
Получается, что мастер получает пакет с испорченной CRC?

Если слэйв может вставлять свои данные на лету, кто мешает так же на лету и подсчитывать CRC передаваемого пакета?
Кстати, в обычном Ethernet контрольную сумму пакета тоже в процессе передачи (как правило) считают.

[Студент заборстр...]

Если слэйв может вставлять свои данные на лету, кто мешает так же на лету и подсчитывать CRC передаваемого пакета?

Так слейвов много. И каждый что-то вставляет в пакет в свой место.
И потом. Вставить "на лету" 1 байт в 1500 байтовый пакет это реально
А вот посчитать "на лету" (за доли наносекунды) CRC16 1500байтного пакета не реально
Поэтому, я думаю, что слейвы в EtherCAT CRC16 не пересчитывают когда вставляют в него свои данные.
Т.е. получается, что целостность данных НИКАК не контролируется.
Поэтому единственным способом контроля целостности полученных, как мне видится, в EtherCAT может быт только повторные передачи одного и того же пакета.
К примеру.
Если слейв - это устройство, включающее некоторый исполнительный механизм, то для надёжности нужно будет 3 раза передавать слейву пакет, чтобы слейв убедился, что реально нужно включать устройство.
Но тогда весь цимус етерката (маленький цикл обмена) пропадает из-за многократных повторных передач
И по факту пропускная способность будет уже не 100Мбит, а 30 и меньше

[Студент заборстр...]

Но об этом (про рост процента битовых ошибок, про необходимость повторных передач и т.п. "скользкие места" EtherCAT, про снижение надёжности передачи и достоверности принятых данных из-за отказа от CRC) не пишут в рекламных проспектах.



Ведь даже на офф. сайте брехня



Какая контрольная сумма?

слейв просто вставляет данные в опр. место телеграммы при этом CRC16 не меняя

[_pv]

А вот посчитать "на лету" (за доли наносекунды) CRC16 1500байтного пакета не реально

конечно нереально, особенно когда 100Мбит/с это 1500 байт за доли наносекунды.

Ведь даже на офф. сайте брехня

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

[Студент заборстр...]

конечно нереально, особенно когда 100Мбит/с это 1500 байт за доли наносекунды.

Вы не ёрничайте. Чай не Петросян.
Скажите конкретно. Считает слейв CRC16 или нет после того как модифицирует пакет?
И каким образом он сможет сделать это корректно если он ещё не получил "хвост" от пакета (к котором и находится CRC) когда уже следующий слейв в цепочке начал вставлять свои данный и менять пакет, а предыдущий слейв об этом НИЧЕГО НЕ ЗНАЕТ

См. видео https://upload.wikimedia.org/wikipedia/comm...gPrinciple.webm

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

Да куда уж нам. С суконным то рылом, да в калашный ряд

P.S. И таки да.Последний слейв в цепочке слейвов если он считывает и вставляет свои данные в конц пакета, непосредственно перед CRC16, то таки да он должен сформировать CRC16 за доли наносекунды.
Потому что после последнего бита данных начинается бит CRC
Правда при подсчёте нужно будет за доли наносекунды добавить к CRC16 только последнее слово данных пакета и тем не менее. Выполнить это надо за время, существенно меньшее битового интервала, который равен для 100 МБит/с 10 наносекундам

И как быть с этим

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

©

проблемы больше в том что нужно платное членство в изиркат сообществе,

Зачем?
Разве этот протокол не открытый?

Сообщение отредактировал Студент заборстроительного - Jan 13 2018, 20:33

[SSerge]

Вы не ёрничайте. Чай не Петросян.
Скажите конкретно. Считает слейв CRC16 или нет после того как модифицирует пакет?
И каким образом он сможет сделать это корректно если он ещё не получил "хвост" от пакета (к котором и находится CRC) когда уже следующий слейв в цепочке начал вставлять свои данный и менять пакет, а предыдущий слейв об этом НИЧЕГО НЕ ЗНАЕТ

См. видео https://upload.wikimedia.org/wikipedia/comm...gPrinciple.webm

У меня тоже есть для Вас картинки CRC
Каждый узел в сети формирует поток битов на передачу. Не важно как он это делает, просто пропускает через себя принимаемый пакет или что-то в него вставляет на лету. На входе передатчика это просто биты идущие друг за другом каждые 10 нс.
На второй картинке в вики схема которая подсчитывает CRC для такого потока бит одновременно с передачей. Биты кодируются и передаются в линию, одновременно те же биты поступают на вход схемы считающей crc. В тот момент когда последний бит данных передан в регистре будет находится подсчитанная crc, в следующем такте можно уже передавать биты из этого регистра. Как не трудно заметить никакого феноменального быстродействия от этой схемы не требуется.
Фокус в том, что crc никто не модифицирует, её просто вычисляют заново для передаваемого пакета, причём прямо в процессе передачи.

[_pv]

Скажите конкретно. Считает слейв CRC16 или нет после того как модифицирует пакет?

нет, CRC16 не считает, но лишь по той причине что в езернете используется CRC32.

И каким образом он сможет сделать это корректно если он ещё не получил "хвост" от пакета (к котором и находится CRC) когда уже следующий слейв в цепочке начал вставлять свои данный и менять пакет, а предыдущий слейв об этом НИЧЕГО НЕ ЗНАЕТ

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

См. видео https://upload.wikimedia.org/wikipedia/comm...gPrinciple.webm

о да, зачем читать скучные спецификации, когда есть википедия с картинками и рекламные статьи на русском языке.

P.S. И таки да.Последний слейв в цепочке слейвов если он считывает и вставляет свои данные в конц пакета, непосредственно перед CRC16, то таки да он должен сформировать CRC16 за доли наносекунды.
Потому что после последнего бита данных начинается бит CRC

это делает каждый слэйв, а не только последний.

Правда при подсчёте нужно будет за доли наносекунды добавить к CRC16 только последнее слово данных пакета и тем не менее. Выполнить это надо за время, существенно меньшее битового интервала, который равен для 100 МБит/с 10 наносекундам

даже хуже - время одного бита 8 нс.
но если вдруг пакет из слэйва вылезет не прям сразу как залез, а через пару (а может десятков, а то и сотен) тактов, то можно не только CRC посчитать.

[Impartial]

"И потом. Вставить "на лету" 1 байт в 1500 байтовый пакет это реально
А вот посчитать "на лету" (за доли наносекунды) CRC16 1500байтного пакета не реально
Поэтому, я думаю, что слейвы в EtherCAT CRC16 не пересчитывают когда вставляют в него свои данные."


CRC32 считается на лету после приема каждой группы бит. Каждый слейв считает и передает дальше свой црц. Других вариантов просто нет.
Причем считается не только выходной но и входной для проверки целостности пакета на входе.
Реализовать в плисине саму идеологию не проблема. Проблема в том, что бы выдержать стандарт. А там много разных дополнений типа "ethernet
over ethercat".
Если не лезть в эти дебри то реализация в плисе типа циклона 4 занимает где то 1000-1200 LES .
В микрочипе есть готовая микросхема LAN9252.

"И по факту пропускная способность будет уже не 100Мбит, а 30 и меньше"

Не так. Задержки во всей цепочке слейвов нет.
К примеру имеем интерфейс к шине RMII. Прием идет по 2 бита. Эти два бита сразу выставляются на передачу если их не надо изменять в том же тактовом интервале. Или из плиса если нужно. Слейв просто мониторит шину со всеми внутренними вычислениями вставляя в нужные тактовые интервалы свои данные.
В том числе и расчитанные црц. Принимает к исполнению полученные данные после окончания пакета и, соответственно, проверив правильность принятого пакета.

Сообщение отредактировал Impartial - Jan 14 2018, 05:36

[Студент заборстр...]

У меня тоже есть для Вас картинки CRC
Каждый узел в сети формирует поток битов на передачу. Не важно как он это делает, просто пропускает через себя принимаемый пакет или что-то в него вставляет на лету. На входе передатчика это просто биты идущие друг за другом каждые 10 нс.
На второй картинке в вики схема которая подсчитывает CRC для такого потока бит одновременно с передачей. Биты кодируются и передаются в линию, одновременно те же биты поступают на вход схемы считающей crc. В тот момент когда последний бит данных передан в регистре будет находится подсчитанная crc, в следующем такте можно уже передавать биты из этого регистра. Как не трудно заметить никакого феноменального быстродействия от этой схемы не требуется.

Допустим.
Что слейв может подсчитывать "на лету" CRC принимаемого пакета.
Но для этого нужно реализовать схему на логических вентилях.
Считать "на лету" CRC программным путем с помощью микроконтроллера не получится.
Так? Потому что операция CRC-сложения занимает не один так процессора

Фокус в том, что crc никто не модифицирует, её просто вычисляют заново для передаваемого пакета, причём прямо в процессе передачи.

Что значит "никто не модифицирует"?
Если слейв вставил какие-то свои данные в пакет, то он должен и CRC, пакета переписать. Ведь она изменилась. Так?

Тут возникает проблема. Допустим переписать он её сможет.
Но ведь целостность ПРИНЯТОГО пакета он никак не проконтролировал.
Поясню.
Допустим данные слейва находятся а 25-м байте от головы пакета.
А CRC - а 154-м байте
Слейв считывает свои данные на 25-м байте и начинает их использовать ДАЖЕ НЕ ПРОВЕРИВ CRC, потому что она еще не дошла. Она ещё "в пути". И формирует ответные данные которые вставляет в 26-й байт
А вдруг пакет "битый" был?
В результате слейв отработал некорректно

нет, CRC16 не считает, но лишь по той причине что в езернете используется CRC32.

Да хоть CRC128 - это не принципиально.
Принципиально: считает или нет

о да, зачем читать скучные спецификации, когда есть википедия с картинками и рекламные статьи на русском языке.

Вы хотите сказать, что там всё врут?
И в каком конкретно месте там врут?

это делает каждый слэйв, а не только последний.

Это очевидно.
Вот же картинка

даже хуже - время одного бита 8 нс.
но если вдруг пакет из слэйва вылезет не прям сразу как залез, а через пару (а может десятков, а то и сотен) тактов, то можно не только CRC посчитать.

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

CRC32 считается на лету после приема каждой группы бит. Каждый слейв считает и передает дальше свой црц. Других вариантов просто нет.

Это я уже понял.
Также понял, что для подсчета CRC "на лету" нужна ПЛИСина. На MCU общего назначения EtherCAT слейв не реализуешь. Так?

Реализовать в плисине саму идеологию не проблема.

А ПЛИСине да. А вот на MCU - большая проблема

Не так. Задержки во всей цепочке слейвов нет.

Задержка таки есть.
Вы же сами написали:

Причем считается не только выходной но и входной для проверки целостности пакета на входе..

Принимает к исполнению полученные данные после окончания пакета и, соответственно, проверив правильность принятого пакета.

Т.е. есть задержка по крайней мере на 1 цикл шины

Реализовать в плисине саму идеологию не проблема. Проблема в том, что бы выдержать стандарт. А там много разных дополнений типа "ethernet over ethercat".

Т.е. без того, чтобы отстегнуть кругленькую сумму фирме Beckhoff (Германия) реализовать полноценный EtherCAT слейв не получится?

Если не лезть в эти дебри то реализация в плисе типа циклона 4 занимает где то 1000-1200 LES .

Вы сами, лично, реализовали "с нуля" EtherCAT слейв на ПЛИСине не платя ничего фирме Beckhoff? Или Вы чисто теоретически говорите?

В микрочипе есть готовая микросхема LAN9252.

И в техасе, и у хилшера, и ... да много у кого есть
И все же остался открытым вопрос по надёжности реализации

Кто-нибудь проводил такие исследования?
Есть инфа по этому вопросу?
А какой процент битовых ошибок?

Ведь если посмотреть ещё раз на картинку

То каждый из 6-ти слейвов может "запороть" всю телеграмму
А наличие 12 (!!!) промежуточных кабелей... Тоже надежность не увеличивают
И повторю это:

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

©
Вообщем в рекламе все просто замечательно.
А как в жизни?
Если 6 и более слейвов в цепочке и тяжелая электромагнитная обстановка в цеху?
Как себя поведет система на EtherCAT?

Сообщение отредактировал Herz - Jan 14 2018, 11:10

[Impartial]

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

На мокроконтроллере это не сделаешь.

Я реализовал слейв на плисе без поддержки всего стандарта. Задача была узкой специализации. Просто пропускал ненужные поля.