Перейти к содержанию
    

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

Ключевое слово здесь "резервируется фрейм".

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

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

 

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

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

 

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

 

И ещё такая заковыка.

У меня цикл 50 мкс.

А если после синхронизации часы сдвинутся на 200 мкс.

Не приведёт ли это к катастрофе?

Ведь система воспримет это как скачок тока.

Т.е., к примеру, ток рос на 2ма за 50мкс, а то вдруг вырос на 10 (из-за того, что время на часах искусственно сдвинули)

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Да вот хотя бы: https://infosys.beckhoff.com/english.php?co...47.html&id=

Или в описании начиная со 184 страницы https://download.beckhoff.com/download/docu..._en.pdf#page184

Остальная - в мануалах на соответсвующие модули

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

cMfvXzuE.jpg

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

Так?

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

 

Так?

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Вы не поняли вопрос.

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

 

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

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

 

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

В смысле?

 

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

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

А как он определяет что к "downstream" разъему EtherCAT ничего не подключено?

И как быстро?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

При этом при переброске с 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 сто магабитных порта обслуживаются одной ПЛИСиной?

 

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

Не понял.

Разве слейву предназначен не КАЖДЫЙ пакет мастера?

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Вы уверены в этом?

Потому что в доках я читал, что слейв реагирует только на пакеты, приходящие на 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 байт даже если у него нет данных для передачи.

 

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Каждый слейв имеет строго определенную внутреннюю структуру. Ни о каком изменении длины не может быть речи.

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

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Ну т.е. чтобы пакет не все слейвы обрабатывали и модифицировали.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Если речь идет о CanOpen то принцип выглядит так.

У устройств поддерживающих этот стандарт есть всего 4 RXPDO и 4 TXPDO.

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

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

Все остальное сделает сам CAN интерфейс с соответствующими настройками полей COB-ID.

Еще нужно обеспечить возможность настройки CANOpen устройства с помощью пакетов SDO. Но это нужно только на этапе запуска системы.

Изменено пользователем Impartial

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

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

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...