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

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

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

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

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

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

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

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

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

[syoma]

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

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

[Kabdim]

del

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

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

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

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

Так?

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

[Impartial]

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

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

Все зависит от конфигурации приложения.

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

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

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

Мастер может (как вариант) только настраивать и синхронизировать сеть.

В смысле?

Если слейв находится в конце цепочки то он закольцовывает через себя трафик.

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

[syoma]

При этом при переброске с RX1 на TX2 ПЛИСина вставляет свои данные в пакет, а при переброске с RX2 на TX1 ничего не вставляет.
Так?

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

Но если к порту TX2 ничего не подключено - ПЛИС перебрасывает трафик с порта RX1 на порт TX1, и прием по RX2 блокируется?

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

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

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

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

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

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


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

если этот слейв каким-то образом адресуется этим пакетом

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

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

[syoma]

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

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

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

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

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

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

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

Их вроде как не 4, а всего 2. RX/TX - это один порт.

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

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

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

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

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

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

Так?

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

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

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

[Impartial]

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

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

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

[syoma]

А ведь я раньше спрашивал: "Что мешает ДИНАМИЧЕСКИ (по команде мастера) реконфигурировать размеры фреймов для каждого слейва?"
А теперь получается, то таки можно так делать.
Ну т.е. чтобы пакет не все слейвы обрабатывали и модифицировали.
В вырожденном случае вообще один слейв может занять своим данными все 1486 байт пакета. Так?
А в другом пакете этот же слейв - вообще 0 байтов.
Я к тому, что формат EtherCAT пакетов очень гибкий.
И позволяет ДИНАМИЧЕСКИ менять как кол-во фреймов в одном пакете, так и их длину.

Ну собственно, наверное и так можно. Только вот лично мне мешает то, что я никогда такого ни в одном мастере не видел.
То есть если взять любой доступный мастер - 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, гляньте "личку", плиз

[syoma]

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

[Impartial]

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

Сообщение отредактировал Impartial - Jan 24 2018, 10:41