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


Жаль


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

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

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

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

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

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

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


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


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


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

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

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

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

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

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

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

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

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

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

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

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


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


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


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


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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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


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

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

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

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

0%


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

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

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


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

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


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

del

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


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

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

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

Да вот хотя бы: https://infosys.beckhoff.com/english.php?co...47.html&id=
Или в описании начиная со 184 страницы https://download.beckhoff.com/download/docu..._en.pdf#page184
Остальная - в мануалах на соответсвующие модули

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

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

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

Так?

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

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


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


В смысле?


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

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

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

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


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


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


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

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

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

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

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

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

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


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

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

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

Так?

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

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

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

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

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

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

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

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

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

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

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

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

Я думаю, что вот это самое интересное. Мастер сможет это сделать через EtherCAT-CANopen интерфейс? Судя по описанию на EL6751 - да. Ну а вообще там много чего интересного в мануале расписано.

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

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

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

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

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

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

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

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

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

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

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

Но пока вопросы более общие, а именно:
1) какой софт имеет смысл использовать для наиболее быстрого старта и поддержки разрабатываемого устройства (мост: слейв для EtherCAT и он же мастер для ModBus)?
На сайте 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

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


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

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

Как думаете?


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

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

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

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

Сходу все ИМХО очень просто - берете 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 и не глючит. Конечно, не стоит ожидать от него реального времени с обычной операционкой.

Доброго дня!

Да, выглядит действительно просто и легко. Вопросы, тем не менее, тоже есть :
Драйвер берём (покупаем лицензию под ТвинКАТ) от Бекхофа (драйвер)?
Но тогда это тянет за собой и покупку Твинката, разве нет? А какой порядок его стоимости (в отличие от бесплатного XAE) ?

Этот драйвер ведь будет работать только с Бекхофскими coupler'ами и терминалами типа этого и этого, так ведь? А хочется сделать свой слейв со своими VID, ESI и пр.

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


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

Спасибо!

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



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




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

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

.

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



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

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

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

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