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

[Jagdhund]

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

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

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 и меньше

[_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 никто не модифицирует, её просто вычисляют заново для передаваемого пакета, причём прямо в процессе передачи.