[SSerge 4]

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

так уже:

http://www.microchip.com/DevelopmentTools/...B-LAN9252-DIGIO

16 цифровых входов/выходов как с куста, на одной микросхеме без контроллеров и программирования.

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

И по CRC16 не ясно.

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

Получается, что мастер получает пакет с испорченной CRC?

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

Кстати, в обычном Ethernet контрольную сумму пакета тоже в процессе передачи (как правило) считают.

[Студент заборстроительного 0]

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

Так слейвов много. И каждый что-то вставляет в пакет в свой место.

И потом. Вставить "на лету" 1 байт в 1500 байтовый пакет это реально

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

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

Т.е. получается, что целостность данных НИКАК не контролируется.

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

К примеру.

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

Но тогда весь цимус етерката (маленький цикл обмена) пропадает из-за многократных повторных передач

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

[Студент заборстроительного 0]

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

 

 

 

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

 

 

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

 

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

[_pv 53]

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

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

 

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

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

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

[Студент заборстроительного 0]

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

Вы не ёрничайте. Чай не Петросян.

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

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

 

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

 

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

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

 

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

Потому что после последнего бита данных начинается бит CRC

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

 

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

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

...

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

©

 

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

Зачем?

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

Изменено 13 января, 2018 пользователем Студент заборстроительного

[SSerge 4]

Вы не ёрничайте. Чай не Петросян.

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

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

 

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

У меня тоже есть для Вас картинки CRC

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

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

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

[_pv 53]

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

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

 

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

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

 

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

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

 

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

Потому что после последнего бита данных начинается бит CRC

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

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

даже хуже - время одного бита 8 нс.

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

[Impartial 0]

"И потом. Вставить "на лету" 1 байт в 1500 байтовый пакет это реально

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

Поэтому, я думаю, что слейвы в EtherCAT CRC16 не пересчитывают когда вставляют в него свои данные."

 

 

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

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

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

over ethercat".

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

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

 

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

 

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

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

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

Изменено 14 января, 2018 пользователем Impartial

[Студент заборстроительного 0]

У меня тоже есть для Вас картинки 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?

Изменено 14 января, 2018 пользователем Herz

[Impartial 0]

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

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

 

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

 

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

[Студент заборстроительного 0]

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

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

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

Вот я и стремаюсь. У меня в цеху жесткая электромагнитная обстановка (инверторы, сварочные автоматы, плазменная резка, куча силовых контакторов и реле клацают, станки шумят и ШИМят и т.п.), а я ещё 8 территориально разнесенных EtherCAT слейвов в цепочку поставить хочу.

Насколько надёжно все это будет работать?

Не получится ли так, что каждый второй пакет будет битый.

Но это еще полбеды.

А вот что два ПОДРЯД и более пакетов будут битыми - вот это пипец.

Потому что у ИУ цикл должен быть порядка 50 мкс.

А если пакеты будут часто биться, то можно и не уложиться

 

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

Жаль

 

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

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

Изменено 14 января, 2018 пользователем Студент заборстроительного

[Impartial 0]

Это где нужно 50мкс?.

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

 

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

 

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

 

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

 

Изменено 14 января, 2018 пользователем Impartial

[Студент заборстроительного 0]

Это где нужно 50мкс?.

Управление позиционированием станков

Там нужно каждый 50мкс подавать управляющий сигнал на ЦАПы.

Не успеем - будет сбой позиционирования на доли мм. И брак

 

А вообще

Какой минимальный цикл у этеркота?

А то в инете данные разнятца.

Кто-то пишет по 6 мкс, кто-то про 30, кто-то про 100, кто-то (как Вы к примеру) про 1 мс

Кому верить?

 

Ни один сканер не обеспечивает меньше 1мс.

Что значит "сканер"?

EtherCAT мастер? Или WireShark ?

 

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

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

 

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

Т.е. Вам было достаточно открытой инфы, имеющейся в инете?

Ничего у бекхова не покупали?

А где, кстати, доки брали, которые использовали при написании слейва?

Ссылка есть?

Изменено 14 января, 2018 пользователем Студент заборстроительного

[Impartial 0]

Получить можно и 1мкс. Но есть разумный выбор.

Если для управления нужно 50мкс то неверно спроектирована вся система движения.

Подавать на цапы и управлять после этого скоростью или ускорением не очень хорошее решение. Еще степ-дир вспомните :).

Управлять нужно подавая код прямо в цифровую систему.

 

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

[Студент заборстроительного 0]

Получить можно и 1мкс.

А вроде бы по стандарту минимальная длина пакета 64 байта. С преамбулой 72 байта. Или 576 бит.

При скорости 100Мбит/с получается, что цикл шины не может быть короче 5.76 мкс

Так?

Если для управления нужно 50мкс то неверно спроектирована вся система движения.

Это раньше так считалось. Что нужен распределенный интеллект.

Но с появлением EtherCAT всё изменилось. Теперь Вам не нужны контроллеры "на местах".

Всем рулит один обычный писюк по езеркату. И в ПЛК нет никакой надобности.

Что существенно удешевляет АСУТП

 

Да да.

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

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

Впервые слышу этот термин, хотя АСУТП занимаюсь более 30 лет

Impartial

Про доки не ответили.

Где брали инфу (и какую конкретно) при разработке EtherCAT слейва?

Изменено 14 января, 2018 пользователем Herz