Версия для печати темы

Автор: Jagdhund May 11 2014, 17:02

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

Автор: AlexandrY May 11 2014, 18:03

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

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

Автор: Jagdhund May 12 2014, 20:49

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

Автор: demiurg_spb May 13 2014, 10:55

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

Автор: Флюктуация ваккума Dec 15 2015, 18:40

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

Автор: Siargy Dec 17 2015, 06:46

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


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


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

ща глянул, они уже предлагают ип-ядра для фпга http://electronix.ru/redirect.php?https://www.beckhoff.com/english/ethercat/ec_entwicklungsprodukte_overview.htm?id=3557177466

Автор: _pv Dec 17 2015, 17:19

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

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

вот вроде обычные intelовские сетевые карточки бехофом как etherCAT compatible объявлены.
http://electronix.ru/redirect.php?http://infosys.beckhoff.com/english.php?content=content/1033/tcsystemmanager/reference/ethercat/html/ethercat_supnetworkcontroller.htm

Автор: Флюктуация ваккума Dec 17 2015, 17:41

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

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

Автор: Corvus Dec 17 2015, 17:56

Не так, чтоб никто
http://electronix.ru/redirect.php?https://en.wikipedia.org/wiki/PROFINET

Автор: Огурцов Dec 17 2015, 18:04

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



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

Автор: Флюктуация ваккума Dec 17 2015, 21:50

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 мс.
А это уже ни в какие ворота не лезет.
Такие тормоза

Автор: Огурцов Dec 18 2015, 00:17

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

Автор: Флюктуация ваккума Dec 18 2015, 04:19

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

Автор: Огурцов Dec 18 2015, 09:10

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

Автор: _pv Dec 18 2015, 11:32

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

Автор: Огурцов Dec 18 2015, 12:42

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

Автор: Флюктуация ваккума Dec 18 2015, 13:57

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

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

Автор: _pv Dec 18 2015, 14:40

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


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

Автор: Огурцов Dec 18 2015, 14:43

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

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

Автор: _pv Dec 18 2015, 16:17

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

Автор: Огурцов Dec 18 2015, 16:59

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

Автор: Флюктуация ваккума Dec 18 2015, 17:26

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


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


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


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

Автор: _pv Dec 18 2015, 17:28

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

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

Автор: Флюктуация ваккума Dec 18 2015, 17:34

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

Автор: Огурцов Dec 18 2015, 17:56

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

Автор: Флюктуация ваккума Dec 18 2015, 18:01

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

Автор: Огурцов Dec 18 2015, 18:04

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

Автор: Флюктуация ваккума Dec 18 2015, 18:09

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


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


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

Автор: Огурцов Dec 18 2015, 18:34

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


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


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

Автор: Флюктуация ваккума Dec 18 2015, 18:50

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



Не понял


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

Автор: Огурцов Dec 18 2015, 19:56

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

Автор: Флюктуация ваккума Dec 19 2015, 18:16

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

Автор: Флюктуация ваккума Jan 22 2016, 17:35

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

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

Автор: syoma Jan 28 2016, 09:24

Мне 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 купается в деньгах.

Автор: gosha-z Jan 28 2016, 10:28

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

Автор: svss Feb 16 2016, 03:24

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

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

Автор: Myron Mar 6 2016, 15:31

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

Автор: BloomJack Mar 8 2016, 08:11

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

Автор: Myron Mar 8 2016, 14:45

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

Автор: bbb Mar 8 2016, 18:17

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

Автор: Myron Mar 9 2016, 00:44

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

Автор: bbb Mar 9 2016, 15:26

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

Автор: Myron Mar 9 2016, 15:34

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

Автор: syoma Mar 9 2016, 16:13

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

Автор: bbb Mar 9 2016, 16:36

© Гуголь

Автор: bbb Mar 22 2016, 17:58

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

Автор: bbb Mar 23 2016, 15:46

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

Автор: СНБ May 2 2016, 14:38

Не нашел в форуме больше тем про реал-тайм 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. http://electronix.ru/redirect.php?http://entas.ru/sites/default/files/epsg_sravnenie_protokolov.pdf статью читал естественно.
Как и множество других. Информации много. Но все равно не могу остановится на чем-то одном.
Помогите определиться с выбором. Кто реально работал с протоколами RT Ethernet.
Расскажите о своем опыте использования протоколов RT езернета на практике

Автор: Make_Pic May 3 2016, 12:31

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

Автор: Make_Pic May 4 2016, 07:16

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

Автор: gosha-z May 4 2016, 15:25

Только что http://electronix.ru/redirect.php?https://e2e.ti.com/tags/industrial%2bEthernet%2bseries?DCMP=industrialethernet&HQS=sys-ind-fa-industrialethernet-aut-blog-series-wwe%20&sp_rid_pod4=MTE1NzI3NTgwNjY5S0&sp_mid_pod4=51025778&detailID=500069817 от техасцев.

Автор: СНБ May 4 2016, 17:01

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

Автор: Make_Pic May 4 2016, 20:02

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

Автор: СНБ May 5 2016, 16:16

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

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

Автор: romasv May 23 2016, 11:54

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

Автор: syoma Mar 29 2017, 09:03

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

Автор: _pv Mar 29 2017, 12:09

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

Автор: AlexandrY Mar 29 2017, 14:26

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

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


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

Автор: syoma Mar 29 2017, 14:59

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

Автор: AlexandrY Mar 29 2017, 16:58

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

Автор: syoma Mar 29 2017, 19:30

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

Автор: Make_Pic Apr 1 2017, 07:15

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


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

Автор: syoma Apr 5 2017, 10:47

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

Автор: AlexandrY Apr 5 2017, 18:28

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

Автор: syoma Apr 6 2017, 07:49

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

Автор: AlexandrY Apr 6 2017, 09:26

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

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

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

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

Автор: syoma Apr 6 2017, 10:07

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

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

Автор: AlexandrY Apr 6 2017, 14:27

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

Автор: syoma Apr 6 2017, 17:32

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

Автор: gte Apr 6 2017, 18:35

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

http://electronix.ru/redirect.php?http://iprog.pp.ru/forum/read.php?f=1&i=28499&t=28474

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 Apr 6 2017, 19:55

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

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

Автор: gte Apr 6 2017, 20:37

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

Автор: AlexandrY Apr 6 2017, 21:24

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

Автор: syoma Apr 7 2017, 07:28

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


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

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

Автор: gte Apr 7 2017, 08:50

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

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

Автор: AlexandrY Apr 7 2017, 10:49

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

Автор: syoma Apr 7 2017, 12:56

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

Автор: AlexandrY Apr 7 2017, 13:18

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

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

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

Автор: syoma Apr 7 2017, 13:30

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

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

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

Автор: AlexandrY Apr 7 2017, 14:15

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

Автор: syoma Apr 7 2017, 17:40

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

Автор: syoma May 3 2017, 10:33

Наткнулся на неплохую презентацию по EtherCAT, правда от 2012 года.
http://electronix.ru/redirect.php?https://indico.cern.ch/event/201794/attachments/302856/423072/EtherCAT_WorkshopCERN_120920.pdf

Автор: Студент заборстроительного Dec 30 2017, 09:55

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

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

Автор: Студент заборстроительного Dec 30 2017, 21:04

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

Автор: gosha-z Dec 31 2017, 13:01

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

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

Автор: syoma Dec 31 2017, 14:57

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

Автор: Студент заборстроительного Jan 1 2018, 20:51

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

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

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

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

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

Автор: Impartial Jan 9 2018, 16:09

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

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

Автор: Студент заборстроительного Jan 13 2018, 10:38

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

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


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

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

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

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

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

Автор: SSerge Jan 13 2018, 11:30

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

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

Автор: Студент заборстроительного Jan 13 2018, 14:07

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

Автор: Студент заборстроительного Jan 13 2018, 15:48

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



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



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

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

Автор: _pv Jan 13 2018, 16:51

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


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

Автор: Студент заборстроительного Jan 13 2018, 20:57

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

См. видео http://electronix.ru/redirect.php?https://upload.wikimedia.org/wikipedia/commons/8/8f/EthercatOperatingPrinciple.webm


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

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

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

http://electronix.ru/redirect.php?http://qoo.by/3zP3


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

Автор: SSerge Jan 13 2018, 23:07

У меня тоже есть для Вас картинки http://electronix.ru/redirect.php?https://ru.wikipedia.org/wiki/%D0%A6%D0%B8%D0%BA%D0%BB%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B8%D0%B9_%D0%B8%D0%B7%D0%B1%D1%8B%D1%82%D0%BE%D1%87%D0%BD%D1%8B%D0%B9_%D0%BA%D0%BE%D0%B4
Каждый узел в сети формирует поток битов на передачу. Не важно как он это делает, просто пропускает через себя принимаемый пакет или что-то в него вставляет на лету. На входе передатчика это просто биты идущие друг за другом каждые 10 нс.
На второй картинке в вики схема которая подсчитывает CRC для такого потока бит одновременно с передачей. Биты кодируются и передаются в линию, одновременно те же биты поступают на вход схемы считающей crc. В тот момент когда последний бит данных передан в регистре будет находится подсчитанная crc, в следующем такте можно уже передавать биты из этого регистра. Как не трудно заметить никакого феноменального быстродействия от этой схемы не требуется.
Фокус в том, что crc никто не модифицирует, её просто вычисляют заново для передаваемого пакета, причём прямо в процессе передачи.

Автор: _pv Jan 13 2018, 23:50

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


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


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


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

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

Автор: Impartial Jan 14 2018, 05:07

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


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

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

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

Автор: Студент заборстроительного Jan 14 2018, 08:35

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


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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

http://electronix.ru/redirect.php?http://qoo.by/3zP3
Вообщем в рекламе все просто замечательно.
А как в жизни?
Если 6 и более слейвов в цепочке и тяжелая электромагнитная обстановка в цеху?
Как себя поведет система на EtherCAT?

Автор: Impartial Jan 14 2018, 08:42

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

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

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

Автор: Студент заборстроительного Jan 14 2018, 09:28

Специфика спецификой, но хотелось бы знать цифры (статистику), полученные на практике. Как часто пакеты приходят "битыми". В том числе как часто "коцает" пакеты именно ПЛИСина. Она же тоже может сбойнуть (пропустить такт например), а не только помехи коцают пакеты. А когда таких ПЛИСин шесть и более в цепочке, то вероятность получить "битый" пакет экспоненциально растет.
Вот я и стремаюсь. У меня в цеху жесткая электромагнитная обстановка (инверторы, сварочные автоматы, плазменная резка, куча силовых контакторов и реле клацают, станки шумят и ШИМят и т.п.), а я ещё 8 территориально разнесенных EtherCAT слейвов в цепочку поставить хочу.
Насколько надёжно все это будет работать?
Не получится ли так, что каждый второй пакет будет битый.
Но это еще полбеды.
А вот что два ПОДРЯД и более пакетов будут битыми - вот это пипец.
Потому что у ИУ цикл должен быть порядка 50 мкс.
А если пакеты будут часто биться, то можно и не уложиться


Жаль


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

Автор: Impartial Jan 14 2018, 10:01

Это где нужно 50мкс?.
Ни один сканер не обеспечивает меньше 1мс. Или имеется в виду детерминизм?

Помехоустойчивость отличная. Битые пакеты появляются очень редко. Тоже в окружении инверторов.

По поводу реализации. Делал и сканер и слейв. Все на уровне интуиции. Но работает с стандартными слейвами. WireShark вам в помощь.

И еще, я рекомендую использовать Ethernet/IP и CIP. Там полностью открытый стандарт поддерживаемый OVDA.

Автор: Студент заборстроительного Jan 14 2018, 10:10

Управление позиционированием станков
Там нужно каждый 50мкс подавать управляющий сигнал на ЦАПы.
Не успеем - будет сбой позиционирования на доли мм. И брак

А вообще
Какой минимальный цикл у этеркота?
А то в инете данные разнятца.
Кто-то пишет по 6 мкс, кто-то про 30, кто-то про 100, кто-то (как Вы к примеру) про 1 мс
Кому верить?


Что значит "сканер"?
EtherCAT мастер? Или WireShark ?


Редко это как? 1 на 10^12? (требование к маршрутизаторам интернета)


Т.е. Вам было достаточно открытой инфы, имеющейся в инете?
Ничего у бекхова не покупали?
А где, кстати, доки брали, которые использовали при написании слейва?
Ссылка есть?

Автор: Impartial Jan 14 2018, 10:27

Получить можно и 1мкс. Но есть разумный выбор.
Если для управления нужно 50мкс то неверно спроектирована вся система движения.
Подавать на цапы и управлять после этого скоростью или ускорением не очень хорошее решение. Еще степ-дир вспомните .
Управлять нужно подавая код прямо в цифровую систему.

Сканером называется в системах автоматики блок выдающий настройки системы и, возможно, осуществляющий общую синхронизацию.

Автор: Студент заборстроительного Jan 14 2018, 11:00

А вроде бы по стандарту минимальная длина пакета 64 байта. С преамбулой 72 байта. Или 576 бит.
При скорости 100Мбит/с получается, что цикл шины не может быть короче 5.76 мкс
Так?

Это раньше так считалось. Что нужен распределенный интеллект.
Но с появлением EtherCAT всё изменилось. Теперь Вам не нужны контроллеры "на местах".
Всем рулит один обычный писюк по езеркату. И в ПЛК нет никакой надобности.
Что существенно удешевляет АСУТП

Да да.
Именно так говорится в рекламных буклетах по эзеркату

Впервые слышу этот термин, хотя АСУТП занимаюсь более 30 лет
Impartial
Про доки не ответили.
Где брали инфу (и какую конкретно) при разработке EtherCAT слейва?

Автор: Impartial Jan 14 2018, 11:16

Зачем в этих пакетах заголовки?
Единственное необходимое поле это црц в конце. Передавая 4-8 байт можно и больше быстродействие получить.

По моему использования компа в качестве управления то это очень рискованная затея. Особенно управляя скоростью или ускорением.

Информация из разных источников в основном из вирешарка. Делалось это давно и сейчас поднимать доки нет желания.

Я давно перешел на Ethernet/IP. По моему езеркат хорош только в случае если нужно в комп получить скоростной поток например от скоростного ацп
по физике езернета.

Автор: Студент заборстроительного Jan 14 2018, 12:05

Потому что этого требует 803-й стандарт


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


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


Понятно.
Ну а как вы оцениваете сложность той работы?
Как долго делался проект? В чем заключалась ГЛАВНАЯ СЛОЖНОСТЬ?
Вот если нанять ПЛИСовода "средней руки" как быстро он сможет "врубиться" в тему и сделать слейв?


Ну да. Именно ради короткого цикла она нам и нужен.

Автор: Студент заборстроительного Jan 14 2018, 13:12

Мне больше POWERLINK симпатичен из всех видов реал-тайм эзернетов.
Но он не обеспечит цикл 50 мкс при том кол-ве ИУ, что у нас ест в локальной сети

Автор: Impartial Jan 14 2018, 13:23

Лет 7 назад я тоже восторженно воспринимал эту концепцию.
На деле оказалось наоборот. Даже яскава бросила эту затею выпускать только усилители к приводам. При том что использовался спец вычислитель а не персоналка. Может Вы и векторное управление собираетесь в компе считать?
Вы предлагаете делать самопал при этом рассуждаете о сетевых стандартах.
Попробуйте сначала определить объем вычислений в компе на 1 сервоцикл. А он как я понял 50мкс.
На мой взгляд пустая трата времени.
Плисовод не станет тратить время на копание в пакетах с непредсказуемым результатом.
Если сможете поставить задачу то с этим и студент справится.

Автор: Студент заборстроительного Jan 14 2018, 16:09

Нет. Мне нужен СТАНДАРТНЫЙ EtherCAT слейв

В смысле "студент справится"?
С реализацией приема и передачи "на лету" данных по EtherCAT?

Автор: Impartial Jan 14 2018, 17:40

Я имел ввиду сервопривод.

Нет там ничего сложного. Я первые опытные реализации укладывал в 120 триггеров первого циклона.

Автор: gosha-z Jan 15 2018, 08:11

С чего вдруг? Ethernet по сути своей асинхронен. SyncE - совершенно отдельная песня.

Почему не меняют? Пруф можете привести?

Автор: Студент заборстроительного Jan 15 2018, 16:09

Ну вот смотрите (это лишь один из возможных сценариев "сбивания" ПЛИСины).
Ошиблась ПЛИСина всего на 1 такт и начала вставлять свои данные не с 12547-го такта, а с 12548-го.
Пакету кирдык.


Вы тему не читали что ли?
Уже разобрались. Меняют. На лету.
Я ошибался

Автор: gosha-z Jan 16 2018, 06:37

Один такт чего?

Автор: syoma Jan 16 2018, 11:09

Я не понимаю такого "стрема". Раз у Вас супер точные и, наверное, дорогие станки, и огромный цех, то что вам стоит потратить 1000 баксов на R&D и купить несколько модулей Beckhof, поставить у себя в цеху, прокинуть Ethernet кабель, подключить к компьютеру или лаптопу, да посмотреть сколько ошибочных фреймов вы получите на 50мкс? А потом уже развивать демагогию?

Мы испытывали наши шкафы с EtherCAT на восприимчивость ко всем помехам по стандарту для силовых подстанций - это как минимум на один уровень выше, чем для промышленных применений. EtherCAT работает нормально.

Автор: Студент заборстроительного Jan 16 2018, 16:53

"Нормально" - это не инженерный термин.
Какой процент "битых" пакетов?

to ALL:
Уважаемые господа русские специалисты по EtherCAT!
Подскажите пожалуйста.
Если слейву (в зависимости от его состояния) нужно передавать то 1 байт, то 1 кБайт. То как быть? Как в EtherCAT разруливается такая ситуация?
Постоянно резервировать 1 килобайт в пакете не хотелось бы. Бо не эффективное использование пропускной способности канала.
Я к тому, что можно ли динамически менять границу данных каждого слейва в пакете?
Если совсем "на пальцах", допускает ли стандарт на EtherCAT такое поведение слейва, когда он то читает (или пишет) то байты 45...56, а то 20...1433
"Дробить" дамп и отправлять в несколько заходов тоже не айс.


И ещё, господа, вопрос.
Нужно в слейвах синхронизировать часы с мастером с точностью 1мкс по IEEE1588.

Сколько пропускной способности "сожрёт" IEEE1588?
И как загрузка канала пакетами IEEE1588 повлияет на джиттер и время цикла основных пакетов

Вот у меня цикл 50мкс нужно очень жёстко выдерживать (1мкс) и с малым джитером (1мкс)

Смогу ли я в таких условиях заюсать IEEE1588 для синхронизации "распределенных часов" с точностью 1 мкс?

Автор: syoma Jan 16 2018, 19:47

0%


EtherCAT - это протокол реального времени. А это подразумевает гарантированную пропускную способность шины, даже если все 10000 передаваемых переменных вдруг обновятся одновременно. Поэтому хотите или нет, а резервировать придется 1кБайт, хоть в какие-то моменты обновлять будете даже 1 бит. Размер и места в кадре Ethercat задаются и фиксируются на этапе конфигурации и в процессе работы не меняются.
Если у вас есть входы/выходы, которые нужно читать/обновлять каждые 25мкс и, например, другие входы/выходы, которые можно обновлять реже, например раз в 1мс, то вы попросту конфигурируете систему с двумя разными фреймами, первый из которых генерируется раз в 25мкс,, а второй - раз в 1мс.

Хмм, вы точно уверены, что это то, что вам действительно нужно? В EtherCAT есть собственный механизм синхронизации слейвов с мастером и между самими собой, который называется Distributed clock. Благодаря ему достигается точность синхронизации с мастером < 100 наносекунд, не говоря уже о микросекундах. И можно быть уверенным, что все слейвы примут или выдадут управляющий сигнал синхронно, даже если между ними 20 узлов и километры кабеля.

Автор: Студент заборстроительного Jan 17 2018, 03:52

Спасибо. Понял.
POWERLINK тоже протокол реального времени. Но там можно и "реальные" маленькие данные передавать и "не реальные" большие (типа видео с камер наблюдения)


А разве Distributed clock не понятие из IEEE1588?
И по поводу трафика и увеличения латентности с джиттером из-за пакетов синхронизации распределенных часов не ответили.
Насколько пакеты синхронизации "забивают" линию?

Автор: syoma Jan 17 2018, 05:54

В EtherCat тоже такое есть. Резервируется полоса - фрейм, в котором можно любой не-реалтаймовый трафик слать - хоть FTP, хоть вебсайты, хоть видео. Но я думал, что вам надо динамически размер реальных данных менять, поэтому и рассказал.


Не знаю, особо IEEE1588 не изучал. По Distributed clock в Ethercat есть достаточно много своей документации.

Автор: Вне зоны доступа Jan 17 2018, 16:33

del

Автор: Студент заборстроительного Jan 17 2018, 16:34

Ключевое слово здесь "резервируется фрейм".
Т.е. есть у тебя в данный момент данных (простите за невольную тавтологию), которые нужно срочно передавать нету, фрейм всё равно резервируется и трафик тратится вхолостую (если данных нет).
Что мешает ДИНАМИЧЕСКИ (по команде мастера) реконфигурировать размеры фреймов для каждого слейва?


Не знаю, где Вы видели "много", а я кроме общих слов, что в EtherCAT есть некая технология "распределенных часов" ничего не нашёл.

Интересует главным образом как механизм "синхронизации часов" повлияет на общую пропускную способность, джиттер и Latence Time.

И ещё такая заковыка.
У меня цикл 50 мкс.
А если после синхронизации часы сдвинутся на 200 мкс.
Не приведёт ли это к катастрофе?
Ведь система воспримет это как скачок тока.
Т.е., к примеру, ток рос на 2ма за 50мкс, а то вдруг вырос на 10 (из-за того, что время на часах искусственно сдвинули)

Автор: syoma Jan 17 2018, 20:24

Да вот хотя бы: http://electronix.ru/redirect.php?https://infosys.beckhoff.com/english.php?content=../content/1033/ethercatsystem/2469118347.html&id=
Или в описании начиная со 184 страницы http://electronix.ru/redirect.php?https://download.beckhoff.com/download/document/io/ethercat-terminals/ethercatsystem_en.pdf#page184
Остальная - в мануалах на соответсвующие модули

Автор: Kabdim Jan 18 2018, 11:54

Что, студент, очередной мультиакк запалил?

Автор: Студент заборстроительного Jan 20 2018, 09:43

Я так понимаю, что весь трафик 4 портов должен идти через одну ПЛИСину?

Обычно ПЛИС на лету передает трафик с порта RX1 на порт TX2. И ОДНОВРЕМЕННО с порта RX2 на порт TX1. При этом при переброске с RX1 на TX2 ПЛИСина вставляет свои данные в пакет, а при переброске с RX2 на TX1 ничего не вставляет.
Так?
Но если к порту TX2 ничего не подключено - ПЛИС перебрасывает трафик с порта RX1 на порт TX1, и прием по RX2 блокируется?

Так?

Автор: Impartial Jan 21 2018, 02:42

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

Автор: Студент заборстроительного Jan 21 2018, 19:52

Вы не поняли вопрос.
Меня интересует 4 порта обслуживает одна ПЛИСина или две? Или 4?


Вы про перекрестный трафик?


В смысле?


Трафик ВСЕГДА закольцовывается. В смысле, пакет два раза проходит через слейв: "туда" и "обратно"
А как он определяет что к "downstream" разъему EtherCAT ничего не подключено?
И как быстро?

Автор: syoma Jan 22 2018, 07:24

Не очень. Каждый пакет, проходящий через каждый слейв модифицируется слейвом, если этот слейв каким-то образом адресуется этим пакетом - т.е. в этом пакете есть команды, на которые должен реагировать данный слейв. В этом случае слейв как минимум инкрементирует так называемый Working Counter - определенный регистр в поле данных этой команды. Мастер шлет фреймы с Working Counter, равным 0, а в ответ ожидает фреймы с определенным значением, в зависимости от конфигурации сети и количества слейвов. Если Working Counter не соответствует ожидаемому - значит в сети произошли несанкционированные изменения.

Если к порту TX2/RX2 что-то подключено, ПЛИС принимает пакет из RX1 и шлет его дальше в TX2, обрабатывая на лету. Если из RX2 принимается пакет, ПЛИС принимает его и шлет в TX1. Если к порту TX2/RX2 ничего не подключено, плис принимает пакет с RX1 и посылает обратно в порт TX1, обрабатывая на лету.

Автор: Студент заборстроительного Jan 22 2018, 18:03

Вы уверены в этом?
Потому что в доках я читал, что слейв реагирует только на пакеты, приходящие на upstream-порт.
Пакеты приходящие на downstrean-порт слейв просто перебрасывает на upstream-порт. Возможно я не правильно понял доки.


А как ПЛИСина понимает, что к RX2/TX2 ничего не подключено? И как быстро?


И вопрос насчет кол-ва ПЛИСин остался открытым: получается все 4 сто магабитных порта обслуживаются одной ПЛИСиной?


Не понял.
Разве слейву предназначен не КАЖДЫЙ пакет мастера?
Ведь слейв жёстко конфигурируется на обработку ОДНИХ И ТЕХ же жестко заданных (зарезервированных для него) полей пакета.

Или это не так?

Автор: syoma Jan 23 2018, 06:29

Возможно Вы правы. Я как-бы применяльщик EtherCAT, а не разработчик Slave устройств (хотя готовое IP Core мы применяли), поэтому меня не интересовали тонкости протокола.

Их вроде как не 4, а всего 2. RX/TX - это один порт. И да - они обслуживаются одной плисиной. По крайней мере покупные IP ядра имеют по два порта. По-моему есть еще на 3, но это для ответвлений на шине.

Конкретно данному слейву - не каждый. В EtherCAT есть различные команды - чтение, запись, чтение с записью, логическая, физическая адресация, обновление синхронизации и т.д. Они формируют фрейм. Вполне может оказаться, что во фрейме будет команда, которая записывает какой-то конкретный слейв. Тогда другие слейвы просто пропускают эту команду дальше, не модифицируя working counter. В конце концов эта команда дойдет до нужного слейва, он ее примет и инкрементирует working counter. Команда пройдет дальше, развернется где-то и вернется к мастеру. И мастер увидит, что его команда записи в конкретный слейв получила working counter 1 - значит она достигла ровно одного адресата. Также слейвы, которые имеют только входы, не реагируют на команды записи. Ну примерно так я это понимаю.

Автор: Студент заборстроительного Jan 23 2018, 21:16

Ну если так считать - то два.
Я почему посчитал их за 4, ведь Rx и Tx работают независимо (в том числе могут параллельно/одновременно)

Тогда получается ПЛИСина должна "перемалывать" поток 400Мбит/с.
Да?


А ведь я раньше спрашивал: "Что мешает ДИНАМИЧЕСКИ (по команде мастера) реконфигурировать размеры фреймов для каждого слейва?"

А теперь получается, то таки можно так делать.
Ну т.е. чтобы пакет не все слейвы обрабатывали и модифицировали.
В вырожденном случае вообще один слейв может занять своим данными все 1486 байт пакета. Так?
А в другом пакете этот же слейв - вообще 0 байтов.

Я к тому, что формат EtherCAT пакетов очень гибкий.
И позволяет ДИНАМИЧЕСКИ менять как кол-во фреймов в одном пакете, так и их длину.

Так?

А то я боялся, что каждый слейв жёстко резервирует в пакете 10+N байт даже если у него нет данных для передачи.

Боялся что мне не хватит длины пакета чтобы охватить все слейвы.
А раз некоторые слейвы можно просто не опрашивать, то тогда хватит

Автор: Impartial Jan 24 2018, 03:40

Каждый слейв имеет строго определенную внутреннюю структуру. Ни о каком изменении длины не может быть речи.
Для каждого слейва есть конфигурация и конфигурационный файл. Общая длина пакета складывается у мастера на этапе конфигурации приложения и может измениться только при реконфигурации. Слейв может пропускать через себя чужие пакеты но к приложению они не имеют никакого отношения. Идентификация встроена в сам пакет.

Почему смущает количество обрабатываемых в плисине потоков? Там максимальная частота 50 мгц. Одна плисина может их хоть сто штук обработать. Хватило бы ножек и триггеров внутри. Это же не микроконтроллер. В плисине все обрабатывается параллельно.

Функция определения подключен дальше в цепочке слейв или нет выполняется на уровне физического драйвера. В этом процессе ни плис ни наличие данных в канале не участвуют. Это происходит на аппаратном уровне PHY. Если глубже залезть то это функция кодера\декодера 8b/10b. В этой избыточности заложены коды которыми обменивается физика для определения своего состояния.

Автор: syoma Jan 24 2018, 06:16

Ну собственно, наверное и так можно. Только вот лично мне мешает то, что я никогда такого ни в одном мастере не видел.
То есть если взять любой доступный мастер - TwinCAT или Codesys и посмотреть, как у него сделан EtherCAT обмен тем же Wiresharkом, то все очень примитивно. После того, как все запустилось, мастер конфигурирует в слейвах т.н. physical-logical mapping - т.е. именно то, за что любят EtherCAT - в какие биты фрейма слейв должен вставлять и считывать свои данные. Затем мастер тупо начинает слать всего две команды - Logical Read и Logical Write, которые адресуют все слейвы одновременно и которые реализуют этот самый паровозик и обеспечивают эту хваленую сумасшедшую скорость, латентость и пропускную способность EtherCAT. Любые другие варианты адресации и динамическая реконфигурация, о которой вы говорите - это значительное ухудшение всех этих параметров и скорей всего не дают EtherCAT никаких других преимуществ перед другими протоколами.
Но опять же я говорю о применении EtherCAT, как очень простой и быстрой последовательной шины ввода/вывода различных физических сигналов в центральный контроллер и по моим прикидкам это 99% всех его применений. Вы же хотите что-то другое.

Автор: Димыч Jan 24 2018, 06:49

Коллеги, а вот что известно о стандартизации мостов, использующих EtherCAT, смотрящий на мастера? То есть, как устроена трансформация пакетов идущих, например, от EC мастера на EC слэйв, который должен отправить/принять данные с CAN или Modbus подчинённого устройства?

Такие Gateways делают разные компании (Anybus, Hilscher, etc.), но вот насколько эти мосты одинаковы/универсальны? Или с каждым типом (к примеру, на EtherCAT-CAN Gateway) должен идти свой SDK от производителя, с помощью которого я свои CAN запросы запеку в EC фреймы, а Gateway их уже распарсит и отправит на CAN шину?

P.S. syoma, гляньте "личку", плиз

Автор: syoma Jan 24 2018, 09:16

Димыч, надо бы читать документацию на конкретное изделие. С мостами, как таковыми, я не сталкивался и собираюсь только в скором времени попробовать CANopen и RS232. Вроде есть стандарт CANopen over EtherCAT, в котором даже задаются словари и прочее, но надо читать...

Автор: Impartial Jan 24 2018, 10:37

Если речь идет о CanOpen то принцип выглядит так.
У устройств поддерживающих этот стандарт есть всего 4 RXPDO и 4 TXPDO.
Каждый из них состоит максимум из 8 байт с структурой определяемой изготовителем устройства.
Принцип моста состоит в том, чтобы отзеркалить эти ПДО в приеме и передаче на соответствующие поля в пакете слейва.
Все остальное сделает сам CAN интерфейс с соответствующими настройками полей COB-ID.
Еще нужно обеспечить возможность настройки CANOpen устройства с помощью пакетов SDO. Но это нужно только на этапе запуска системы.

Автор: syoma Jan 24 2018, 11:18

Насколько я знаю CANopen это во первых зависит от профиля и во вторых - это чисто настройки по умолчанию. Количество PDO может быть разным, но статическим в одной системе.

Я думаю, что вот это самое интересное. Мастер сможет это сделать через EtherCAT-CANopen интерфейс? Судя по описанию на http://electronix.ru/redirect.php?https://download.beckhoff.com/download/document/io/ethercat-terminals/el6751en.pdf- да. Ну а вообще там много чего интересного в мануале расписано.

Автор: Impartial Jan 24 2018, 11:29

Это максимальное количество ПДО.

СДО это всего один кадр на передачу и прием.
Просто мастер должен поддерживать стандарт DS 301.

Автор: Студент заборстроительного Jan 24 2018, 15:57

Ну как же. Если во фрамэ нет адреса слейва в общем "логическом пространстве задачи" то он игнорирует такой пакет (не использует его и ничего не пишет в него). Слейв "вылавливает" и реагирует только на свои адреса.
Или я не прав?

Т.е., грубо говоря, у PHY микросхемы есть сигнал "connection failed", который заводится в ПЛИСину?

Может потому, что это никому было не нужно?
Или ещё вариант: никто просто не знал о такой возможности

А что мешает мастеру менять этот "physical-logical mapping" на лету?
Но моя идея была даже не в этом.
Вы говорили, что каждый слейв реагирует только на свой диапазон адресов в общем 4-х гигабайтном логическом пространстве задачи.
Тогда что мешает мастеру читать только один слейв, чтобы этот слейв занял весь пакет, все 1498 байт?

Вы не совсем поняли.
И ухудшения не будет.
Моя идея в том: зачем слейву ЗРЯ тратить трафик если ему НЕЧЕГО передавать мастеру?
Разве не разумно будет отдать в этом случае весь трафик слейву, у которого есть что передавать и который "зашивается" уже от потока событий по причине не хватки трафика?

Автор: syoma Jan 24 2018, 16:18

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

По-моему это была одна из основных причин появления EtherCAT. Тот же CANopen исповедует вашу модель, так как он построен на принципе "передавай, если есть что передать". Это отлично снижает нагрузку на сеть, но создает огромную проблему для проектировщика, заключающуюся в том, что сеть должна быть рассчитана на случай, что все вдруг начнут передавать свои данные одновременно. Иначе вы получите недопустимые задержки, если не потерю данных.
Поэтому люди искали такую шину, которая позволяла бы получить большую пропускную способность, независящую от количества слейвов и их желания или нежелания передавать данные и имеющую гарантированную латентность и минимальное время цикла без каких-либо компромиссов, типа "передачи" трафика какому либо конкретному слейву, если ему вдруг это требуется и пр. Это и есть требования реального времени.

Автор: Димыч Jan 24 2018, 16:40

Спасибо, Impartial.
Благодарю, syoma.

Собственно, в моём случае речь идёт о ModBus (CAN где-то в неясной перспективе) и есть ли какие то соглашения о том, как ему дружить с EtherCAT, я сходу не нашёл.

Но пока вопросы более общие, а именно:
1) какой софт имеет смысл использовать для наиболее быстрого старта и поддержки разрабатываемого устройства (мост: слейв для EtherCAT и он же мастер для ModBus)?
На сайте http://electronix.ru/redirect.php?https://www.ethercat.org/en/products.html есть список, но - возможно - опытные товарищи сразу скажут, мол это использовать не стоит, а вот это - хороший Tool...
Да, TwinCAT XAE установил, но пока с ним ничего не взлетело: винда с ним периодически уходит в синий экран, а тестовый ESC он не видит.

Пока что для себя сделал такой список:

"ET9000 Beckhoff (EtherCAT Configurator)"
EtherCAT Workbench
XML Editor (есть)
Network Analyzer (есть)
Что-то ещё нужно для взлёта?

2) организационный вопрос: сколько времени и ресурсов может уйти (уйдёт) на разработку слэйва, готового для передачи в производство?
Очевидно, что должны быть реализованы функциональности:
- сам мост
- Device Firmware Update (нужно через Ethernet порт слейва обновлять Firmware Host-процессора, который соединён с EtherCAT ASIC'ом через SPI DP-RAM)
- удобная первичная прошивка
- самодиагностика
- документация
- сервисный софт (конфигуратор? апдейтер? что-то ещё?)

Опять же, как черновой вариант, процесс выглядит так (и занимает полтора человеко-года):

Prototyping
Stand Seting-Up
Running a test application on Eval Board (EVB)
Writing a communication between EVB and a Modbus device
Running the tests with Prototype Gateway (купить готовый мост) and ModBus
Running the tests with 3-rd party’s EtherCAT devices

PCB and Housing
Power Dissipation/Thermal Evals
Suggestions concerning Housing and PCBs arrangement
Schematics
Layout
PCBA
Tests and Evaluations

Firmware
Boot-loading and DFU Functionality
HAL and low-level drivers/functions
POST and Debug Interface
CDC VCP - for Debug interface and optional DFU
MODBUS Stack
Working with API from EtherCAT ASIC supplier
Porting to a lower-grade MCU

Software
Ethernet Device Set-Up
Configuration Software
Firmware Upgrade Utility

Re-Design to Cost
Eliminating unused components (e.g., QSPI EEPROM), replacing Ethernet connector, …
Firmware modifications
Software’s changes
Performing the test
Issuing documentation

in-house tests (protocol and EMC)
EMC tests
Protocol conformance

Documentation
User Manual
Ethernet Configuration
Programming Guide and Examples
(Sample) Configuration Files
ESI / GSD(ML) Files
Certificates

Автор: Arjun Jan 24 2018, 20:50

Почему? Что мешает?


А в чем проблема делать два цикла.
В первом цикле опрашиваем у кого есть срочные данные. И если ни у кого нет - во втором цикле отдаем трафик тому, у кого есть что передедавать?

Получается и рилтайме не нарушается и линия используется более эффективно за счет того, что не нужно гонять пустые пакеты

Как думаете?


Допустим есть два девайса.
Один нужно опрашивать каждый 6 мкс. А другой - раз в 10 мс.
И какой смысл тогда второму устройству передавать пустые фреймы каждый 6 мкс если у него состояние обновляется раз в 10 мс?

Автор: Impartial Jan 24 2018, 23:00

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

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

Есть такая любительская система управления станками ЧПУ LinuxCNC. Она с открытым исходным кодом и я много интересного узнал разбирая некоторые куски кода.
Там есть исходник драйвера езерката и его нормальная работа гарантируется только на нескольких чипах.
Плюс ко всему операционка с которой работает эта программа специально под нее собрана с использованием RTAI ядра и все равно джиттер на разных компьютерах, особенно современных, часто не отвечает ее требованиям.

Автор: syoma Jan 25 2018, 07:52

Сходу все ИМХО очень просто - берете EtherCAT терминал с RS485 или RS232. Он делает Вам виртуальный COM порт. Далее берете обыкновенный Modbus мастер и общаетесь через этот порт со своими MODBUS слейвами. Или Вам надо что-то другое?

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


TwinCAT 3 эволюционный. С готовыми EtherCAT модулями Codesys также неплохо работает, но нужно подключить XML описания.


Давайте сначала посчитаем реальность всего этого для EtherCAT. Вообще я не очень понимаю, что мастер успеет сделать за 6мкс с данными, но допустим успеет и цикл опроса у нас 6мкс. При скорости в 100Мбит за 6мкс мы успеваем передать/получить 600бит или 75 байт - a это в принципе минимальная длина Ethernet пакета. То есть при цикле опроса в 6мкс даже один самый маленький пакет полностью забьет нашу шину. Куда вы собрались всовывать пакет для 10-милисекундного опроса?


Не встречался с особыми проблемами. Нужна нормальная сетевуха, да и все вроде. Работал и с TwinCAT и с Codesys. Последний, кстати с EtherCAT работает даже на Raspberry Pi и не глючит. Конечно, не стоит ожидать от него реального времени с обычной операционкой.

Автор: Димыч Jan 25 2018, 09:18

Доброго дня!

Да, выглядит действительно просто и легко. Вопросы, тем не менее, тоже есть :
Драйвер берём (покупаем лицензию под ТвинКАТ) от Бекхофа (http://electronix.ru/redirect.php?https://www.beckhoff.com/english.asp?twincat/twincat_virtual_serial_com_driver.htm)?
Но тогда это тянет за собой и покупку Твинката, разве нет? А какой порядок его стоимости (в отличие от бесплатного XAE) ?

Этот драйвер ведь будет работать только с Бекхофскими coupler'ами и терминалами http://electronix.ru/redirect.php?https://www.beckhoff.com/english/ethercat/el6001.htm и http://electronix.ru/redirect.php?https://www.beckhoff.com/english.asp?ethercat/ek1101.htm, так ведь? А хочется сделать свой слейв со своими VID, ESI и пр.

Эх, если бы единственное, то и не вопрос. Но нужно для масс-продакшен. Окупаемость - вопрос правильный, но на разработку выделяются (пока что) просто копейки. Опять же, сколько, в норме, может стоить разработка такого девайса (а-ля Serial Interface от Beckhoff)?


А с ТвинКАТом, наверное, всё хорошо. Но пока он у меня разве что комп вешает И будущий вопрос генерации отчуждаемой программы, сделанной на нём, также остаётся.

Спасибо!

Автор: Вне зоны доступа Jan 25 2018, 16:07

Говорите, что нет никакой адресации?
А это Вы видели?



Вместо пространной демагогии лучше ответьте на вопрос:




Что значит "забьёт шину"?
Если мы как раз для этого его и используем, чтобы шину загрузить на 100% (хотя на 100 все равно не получится).
А насчет "всовывать" не понятно, что Вы имеете в виду

Автор: syoma Jan 26 2018, 10:34

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

Автор: Arjun Jan 26 2018, 14:44

.

Автор: Вне зоны доступа Jan 26 2018, 14:45

У меня возникли сомнения. Насчёт "прелести"



Уточню. Под пустыми я подразумевал Фреймы, не несущие новой информации и НАПРАСНО "забивающие" линию связи своим трафиком. Т.е., к примеру, если в устройстве состояние меняется раз в 10 мс, а цикл шины 6мкс, то получается, что более 99% времени он передают "порожняк"
Как быть в этом случае?

Автор: AlexandrY Jan 26 2018, 15:07

Передавать состояние только в моменты его изменения крайне плохая практика.
Система каждый цикл должна подтверждать свое состояние.
Проверяется горьким опытом.
Тут вот буквально на днях под Гамбургом объект у нас работает на шине CAN и есть частотник.
Система взяла и ушла в ступор, в логе сообщение об отключении сетевого напряжения. А отключения не было.
По CAN-у из-за наводок с частотника прошел ложный пакет об отключении и CRC не помогло, а передавались такие пакеты только по событию отключения и включения напряжения.
Такая вот история. Сейчас надо править программу.

Автор: Вне зоны доступа Jan 26 2018, 16:45

Ну вот смотрите.
Если система инерционная и за 10 мс в ней НИЧЕГО не может случиться по определению. То смысл передавать её состояние каждые 6 мкс?

А ведь такое бывает сплошь и рядом. Что на шине EtherCAT "висят" как быстрые устройства, так инерционные.
И как тут быть?
Передавать "порожняк" впустую расходуя драгоценный трафик?

Автор: syoma Jan 26 2018, 18:15

Вне зоны доступа, я вначале писал насчет проблем 6мкс только потому, что самый минимальный Ethernet фрейм имеет длину 70 байт и на 100мбит его длительность уже составляет 6мкс, точнее 6,42, как мне написал Twincat. Поэтому цикл опроса в 6мкс Вы по-любому не сделаете.
Для EtherCAT цикл опроса обычно 50мкс или медленней.

Сделать фрейм с двумя разными временами опроса - быстрым и медленным в EtherCAT можно без проблем. При этом трафик будет расходоваться эффективно, как вы хотите.

Автор: Вне зоны доступа Jan 26 2018, 20:56

Это не так. Максимальный пакет 64 байта. Плюс 8 байт преамбулы. Получается 72 байта.
Или 576 бит. или 5,76 мкс.

Цикл 6 мкс вполне себе часто используется


Как?

Автор: AlexandrY Jan 26 2018, 22:04

Как split transaction в USB.

Автор: syoma Jan 27 2018, 07:52

Еще вроде есть минимальный межкадровый интервал, который надо учитывать.


В EtherCAT?

Автор: Вне зоны доступа Jan 27 2018, 08:10

Да.
5,76 мкс + 0,96мкс = 6,72 мкс

Т.е. с таким периодом вполне можно опрашивать 3 слейва в сети


Да. Именно в EtherCAT
В этом главная прелесть EtherCAT - сверхмалый цикл шины.


Всё гораздо проще.
http://electronix.ru/redirect.php?http://f4.s.qip.ru/cMfvXAd4.jpg картинку видели же?
Мастер устанавливая соответствующий [LOGICAL ADDRESS] логического пространства задачи может опрашивать слейвы с любым периодом независимо друг от друга.

Так?

Автор: syoma Jan 27 2018, 08:13

За счет логической адресации. Допустим у вас имеется 2 EtherCAT устройства, одно из которых надо опрашивать каждые 6мкс, а другое - раз в 10мс. В EtherCAT слейвах есть такая штука, которая называется FMMU, которая позволяет отобразить физические сигналы слейва в общее логическое адресное пространство по определенным адресам. При чтении/записи мастером по этим адресам командами LRD/LWR слейв будет вставлять свои сигналы, если совпадут запрограммированные адреса. Допустим и тот и другой слейв - это 4 канала АЦП по 16 бит каждый. Т.е на каждый слейв нам надо 16*4=8 байт логического адресного пространства.
Отображаем слейв, который будем опрашивать каждые 6мкс по логическому адресу 0х1000, а второй слейв -по адресу 0х1008. Тогда команда LRD по адресу 0х1000 и длиной 8 байт с автоинкрементацией адреса прочитает первый слейв - ее будем слать в фрейме каждые 6мкс. А команда LRD по тому же адресу, но длиной 16 байт, прочитает оба слейва. Ее можно слать раз в 10мс. При этом у вас в этом фрейме нагрузка возрастет аж на 8 байт.

Теперь вопрос на засыпку. Что мешает слать второй фрейм каждые 6мкс, а не 10мс?

Автор: Вне зоны доступа Jan 27 2018, 08:14

А кто нибудь в курсе?
Почему "отцы основатели" EtherCAT (фирма Beckhoff) не торопятся переходить на 1G и 10G EtherCAT?
Случайно наткнулся где-то в дебрях их сайта на инфу, что даже теоретические работы в этом направлении пока не ведутся.
Хотя их конкурент POWERLINK уже выкатил 1G и 10G решения.
Или там какие-то сложности принципиального характера?
--------------------

Я это уже сказал выше.
Но спасибо что "разжевали" более подробно

Автор: mantech Jan 27 2018, 14:34

А не рассматривали такой вариант, что может это и не нужно? Сейчас, когда поголовно все лезут все быстрее и быстрее, то в основном это касается передачи интернета с его постоянно распухающими html, xml, json и прочей текстовой фигней, непонятно зачем передающей все в текстовом виде, тут же все довольно консервативно, скорости всегда хватало. Плюс если переходите на гигабит, уменьшается длина сегмента, увеличивается вероятность ошибок, а это явно не в пользу устройствам промавтоматики...

Автор: Вне зоны доступа Jan 27 2018, 15:59

"Хватало" потому лишь, что не было относительно дешевых и технически относительно просто реализуемых решений увеличения скорости на порядки.

Знаете же поговорку "Аппетит приходит во время еды"©

А теперь, когда это всё есть - приходит и "аппетит".
Появляются такие возможности, о которых раньше мы (АСУТПшники) даже мечтать мы раньше не могли.

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


Оптоволокно спасёт отца русской демократии
Там хоть 10 Терабит в секунду передавай. На 20 километров

Автор: syoma Jan 27 2018, 17:15

Помоему, Вы далеко от АСУТПшников. Я вас спрашивал выше, откуда у вас 6мкс, и вы тут рассуждаете еще и о 1мкс времени опроса, когда в АСУТП время выполнения цикла самой быстрой программы - основного потребителя и производителя информации для EtherCAT >50мкс и ему еще долго уменьшаться... Поэтому всем в АСУТП и хватает 100Мбит.

А у вас что-то другое... признавайтесь :-)

Автор: Вне зоны доступа Jan 27 2018, 19:49

С чего Вы взяли?
Когда в инете есть инфа, что есть системы на EtherCAT где сервопривода управляются с частотой от 30 кГц, а это уже никак не 50 мкс, а поменьше.

Существует АСУТП быстропротекающих процессов.
Там нужны короткие циклы.

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

А для этого нужные микросекундные циклы опроса

Автор: syoma Jan 28 2018, 10:10

Ну 30кГц - все же это не 6мкс, а немного больше. :-)

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

Автор: Николай Семёнович Feb 8 2018, 16:03

А то что десятки устройств будут соединяться в цепочку не увеличивает ли вероятность обрыва кольца?