Студент заборстроительного 0 17 января, 2018 Опубликовано 17 января, 2018 (изменено) · Жалоба В EtherCat тоже такое есть. Резервируется полоса - фрейм, в котором можно любой не-реалтаймовый трафик слать - хоть FTP, хоть вебсайты, хоть видео. Но я думал, что вам надо динамически размер реальных данных менять, поэтому и рассказал. Ключевое слово здесь "резервируется фрейм". Т.е. есть у тебя в данный момент данных (простите за невольную тавтологию), которые нужно срочно передавать нету, фрейм всё равно резервируется и трафик тратится вхолостую (если данных нет). Что мешает ДИНАМИЧЕСКИ (по команде мастера) реконфигурировать размеры фреймов для каждого слейва? Не знаю, особо IEEE1588 не изучал. По Distributed clock в Ethercat есть достаточно много своей документации. Не знаю, где Вы видели "много", а я кроме общих слов, что в EtherCAT есть некая технология "распределенных часов" ничего не нашёл. Интересует главным образом как механизм "синхронизации часов" повлияет на общую пропускную способность, джиттер и Latence Time. И ещё такая заковыка. У меня цикл 50 мкс. А если после синхронизации часы сдвинутся на 200 мкс. Не приведёт ли это к катастрофе? Ведь система воспримет это как скачок тока. Т.е., к примеру, ток рос на 2ма за 50мкс, а то вдруг вырос на 10 (из-за того, что время на часах искусственно сдвинули) Изменено 17 января, 2018 пользователем Студент заборстроительного Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
syoma 1 17 января, 2018 Опубликовано 17 января, 2018 · Жалоба Не знаю, где Вы видели "много", а я кроме общих слов, что в EtherCAT есть некая технология "распределенных часов" ничего не нашёл. Да вот хотя бы: https://infosys.beckhoff.com/english.php?co...47.html&id= Или в описании начиная со 184 страницы https://download.beckhoff.com/download/docu..._en.pdf#page184 Остальная - в мануалах на соответсвующие модули Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Kabdim 0 18 января, 2018 Опубликовано 18 января, 2018 · Жалоба del Что, студент, очередной мультиакк запалил? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Студент заборстроительного 0 20 января, 2018 Опубликовано 20 января, 2018 (изменено) · Жалоба Я так понимаю, что весь трафик 4 портов должен идти через одну ПЛИСину? Обычно ПЛИС на лету передает трафик с порта RX1 на порт TX2. И ОДНОВРЕМЕННО с порта RX2 на порт TX1. При этом при переброске с RX1 на TX2 ПЛИСина вставляет свои данные в пакет, а при переброске с RX2 на TX1 ничего не вставляет. Так? Но если к порту TX2 ничего не подключено - ПЛИС перебрасывает трафик с порта RX1 на порт TX1, и прием по RX2 блокируется? Так? Изменено 20 января, 2018 пользователем Студент заборстроительного Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Impartial 0 21 января, 2018 Опубликовано 21 января, 2018 · Жалоба Все зависит от конфигурации приложения. Если слейву нужны данные от других слейвов он их принимает и модифицирует без участия мастера. Мастер может (как вариант) только настраивать и синхронизировать сеть. Если слейв находится в конце цепочки то он закольцовывает через себя трафик. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Студент заборстроительного 0 21 января, 2018 Опубликовано 21 января, 2018 · Жалоба Все зависит от конфигурации приложения. Вы не поняли вопрос. Меня интересует 4 порта обслуживает одна ПЛИСина или две? Или 4? Если слейву нужны данные от других слейвов он их принимает и модифицирует без участия мастера. Вы про перекрестный трафик? Мастер может (как вариант) только настраивать и синхронизировать сеть. В смысле? Если слейв находится в конце цепочки то он закольцовывает через себя трафик. Трафик ВСЕГДА закольцовывается. В смысле, пакет два раза проходит через слейв: "туда" и "обратно" А как он определяет что к "downstream" разъему EtherCAT ничего не подключено? И как быстро? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
syoma 1 22 января, 2018 Опубликовано 22 января, 2018 · Жалоба При этом при переброске с 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, обрабатывая на лету. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Студент заборстроительного 0 22 января, 2018 Опубликовано 22 января, 2018 · Жалоба Не очень. Каждый пакет, проходящий через каждый слейв модифицируется слейвом, если этот слейв каким-то образом адресуется этим пакетом - т.е. в этом пакете есть команды, на которые должен реагировать данный слейв. В этом случае слейв как минимум инкрементирует так называемый Working Counter - определенный регистр в поле данных этой команды. Мастер шлет фреймы с Working Counter, равным 0, а в ответ ожидает фреймы с определенным значением, в зависимости от конфигурации сети и количества слейвов. Если Working Counter не соответствует ожидаемому - значит в сети произошли несанкционированные изменения. Вы уверены в этом? Потому что в доках я читал, что слейв реагирует только на пакеты, приходящие на upstream-порт. Пакеты приходящие на downstrean-порт слейв просто перебрасывает на upstream-порт. Возможно я не правильно понял доки. Если к порту TX2/RX2 что-то подключено, ПЛИС принимает пакет из RX1 и шлет его дальше в TX2, обрабатывая на лету. Если из RX2 принимается пакет, ПЛИС принимает его и шлет в TX1. Если к порту TX2/RX2 ничего не подключено, плис принимает пакет с RX1 и посылает обратно в порт TX1, обрабатывая на лету. А как ПЛИСина понимает, что к RX2/TX2 ничего не подключено? И как быстро? И вопрос насчет кол-ва ПЛИСин остался открытым: получается все 4 сто магабитных порта обслуживаются одной ПЛИСиной? если этот слейв каким-то образом адресуется этим пакетом Не понял. Разве слейву предназначен не КАЖДЫЙ пакет мастера? Ведь слейв жёстко конфигурируется на обработку ОДНИХ И ТЕХ же жестко заданных (зарезервированных для него) полей пакета. Или это не так? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
syoma 1 23 января, 2018 Опубликовано 23 января, 2018 · Жалоба Вы уверены в этом? Потому что в доках я читал, что слейв реагирует только на пакеты, приходящие на upstream-порт. Пакеты приходящие на downstrean-порт слейв просто перебрасывает на upstream-порт. Возможно я не правильно понял доки. Возможно Вы правы. Я как-бы применяльщик EtherCAT, а не разработчик Slave устройств (хотя готовое IP Core мы применяли), поэтому меня не интересовали тонкости протокола. И вопрос насчет кол-ва ПЛИСин остался открытым: получается все 4 сто магабитных порта обслуживаются одной ПЛИСиной? Их вроде как не 4, а всего 2. RX/TX - это один порт. И да - они обслуживаются одной плисиной. По крайней мере покупные IP ядра имеют по два порта. По-моему есть еще на 3, но это для ответвлений на шине. Не понял. Разве слейву предназначен не КАЖДЫЙ пакет мастера? Ведь слейв жёстко конфигурируется на обработку ОДНИХ И ТЕХ же жестко заданных (зарезервированных для него) полей пакета. Конкретно данному слейву - не каждый. В EtherCAT есть различные команды - чтение, запись, чтение с записью, логическая, физическая адресация, обновление синхронизации и т.д. Они формируют фрейм. Вполне может оказаться, что во фрейме будет команда, которая записывает какой-то конкретный слейв. Тогда другие слейвы просто пропускают эту команду дальше, не модифицируя working counter. В конце концов эта команда дойдет до нужного слейва, он ее примет и инкрементирует working counter. Команда пройдет дальше, развернется где-то и вернется к мастеру. И мастер увидит, что его команда записи в конкретный слейв получила working counter 1 - значит она достигла ровно одного адресата. Также слейвы, которые имеют только входы, не реагируют на команды записи. Ну примерно так я это понимаю. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Студент заборстроительного 0 23 января, 2018 Опубликовано 23 января, 2018 (изменено) · Жалоба Их вроде как не 4, а всего 2. RX/TX - это один порт. Ну если так считать - то два. Я почему посчитал их за 4, ведь Rx и Tx работают независимо (в том числе могут параллельно/одновременно) Тогда получается ПЛИСина должна "перемалывать" поток 400Мбит/с. Да? Конкретно данному слейву - не каждый. В EtherCAT есть различные команды - чтение, запись, чтение с записью, логическая, физическая адресация, обновление синхронизации и т.д. Они формируют фрейм. Вполне может оказаться, что во фрейме будет команда, которая записывает какой-то конкретный слейв. Тогда другие слейвы просто пропускают эту команду дальше, не модифицируя working counter. В конце концов эта команда дойдет до нужного слейва, он ее примет и инкрементирует working counter. Команда пройдет дальше, развернется где-то и вернется к мастеру. И мастер увидит, что его команда записи в конкретный слейв получила working counter 1 - значит она достигла ровно одного адресата. Также слейвы, которые имеют только входы, не реагируют на команды записи. Ну примерно так я это понимаю. А ведь я раньше спрашивал: "Что мешает ДИНАМИЧЕСКИ (по команде мастера) реконфигурировать размеры фреймов для каждого слейва?" А теперь получается, то таки можно так делать. Ну т.е. чтобы пакет не все слейвы обрабатывали и модифицировали. В вырожденном случае вообще один слейв может занять своим данными все 1486 байт пакета. Так? А в другом пакете этот же слейв - вообще 0 байтов. Я к тому, что формат EtherCAT пакетов очень гибкий. И позволяет ДИНАМИЧЕСКИ менять как кол-во фреймов в одном пакете, так и их длину. Так? А то я боялся, что каждый слейв жёстко резервирует в пакете 10+N байт даже если у него нет данных для передачи. Боялся что мне не хватит длины пакета чтобы охватить все слейвы. А раз некоторые слейвы можно просто не опрашивать, то тогда хватит Изменено 23 января, 2018 пользователем Студент заборстроительного Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Impartial 0 24 января, 2018 Опубликовано 24 января, 2018 · Жалоба Каждый слейв имеет строго определенную внутреннюю структуру. Ни о каком изменении длины не может быть речи. Для каждого слейва есть конфигурация и конфигурационный файл. Общая длина пакета складывается у мастера на этапе конфигурации приложения и может измениться только при реконфигурации. Слейв может пропускать через себя чужие пакеты но к приложению они не имеют никакого отношения. Идентификация встроена в сам пакет. Почему смущает количество обрабатываемых в плисине потоков? Там максимальная частота 50 мгц. Одна плисина может их хоть сто штук обработать. Хватило бы ножек и триггеров внутри. Это же не микроконтроллер. В плисине все обрабатывается параллельно. Функция определения подключен дальше в цепочке слейв или нет выполняется на уровне физического драйвера. В этом процессе ни плис ни наличие данных в канале не участвуют. Это происходит на аппаратном уровне PHY. Если глубже залезть то это функция кодера\декодера 8b/10b. В этой избыточности заложены коды которыми обменивается физика для определения своего состояния. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
syoma 1 24 января, 2018 Опубликовано 24 января, 2018 · Жалоба А ведь я раньше спрашивал: "Что мешает ДИНАМИЧЕСКИ (по команде мастера) реконфигурировать размеры фреймов для каждого слейва?" А теперь получается, то таки можно так делать. Ну т.е. чтобы пакет не все слейвы обрабатывали и модифицировали. В вырожденном случае вообще один слейв может занять своим данными все 1486 байт пакета. Так? А в другом пакете этот же слейв - вообще 0 байтов. Я к тому, что формат EtherCAT пакетов очень гибкий. И позволяет ДИНАМИЧЕСКИ менять как кол-во фреймов в одном пакете, так и их длину. Ну собственно, наверное и так можно. Только вот лично мне мешает то, что я никогда такого ни в одном мастере не видел. То есть если взять любой доступный мастер - TwinCAT или Codesys и посмотреть, как у него сделан EtherCAT обмен тем же Wiresharkом, то все очень примитивно. После того, как все запустилось, мастер конфигурирует в слейвах т.н. physical-logical mapping - т.е. именно то, за что любят EtherCAT - в какие биты фрейма слейв должен вставлять и считывать свои данные. Затем мастер тупо начинает слать всего две команды - Logical Read и Logical Write, которые адресуют все слейвы одновременно и которые реализуют этот самый паровозик и обеспечивают эту хваленую сумасшедшую скорость, латентость и пропускную способность EtherCAT. Любые другие варианты адресации и динамическая реконфигурация, о которой вы говорите - это значительное ухудшение всех этих параметров и скорей всего не дают EtherCAT никаких других преимуществ перед другими протоколами. Но опять же я говорю о применении EtherCAT, как очень простой и быстрой последовательной шины ввода/вывода различных физических сигналов в центральный контроллер и по моим прикидкам это 99% всех его применений. Вы же хотите что-то другое. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Димыч 0 24 января, 2018 Опубликовано 24 января, 2018 · Жалоба Коллеги, а вот что известно о стандартизации мостов, использующих EtherCAT, смотрящий на мастера? То есть, как устроена трансформация пакетов идущих, например, от EC мастера на EC слэйв, который должен отправить/принять данные с CAN или Modbus подчинённого устройства? Такие Gateways делают разные компании (Anybus, Hilscher, etc.), но вот насколько эти мосты одинаковы/универсальны? Или с каждым типом (к примеру, на EtherCAT-CAN Gateway) должен идти свой SDK от производителя, с помощью которого я свои CAN запросы запеку в EC фреймы, а Gateway их уже распарсит и отправит на CAN шину? P.S. syoma, гляньте "личку", плиз Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
syoma 1 24 января, 2018 Опубликовано 24 января, 2018 · Жалоба Димыч, надо бы читать документацию на конкретное изделие. С мостами, как таковыми, я не сталкивался и собираюсь только в скором времени попробовать CANopen и RS232. Вроде есть стандарт CANopen over EtherCAT, в котором даже задаются словари и прочее, но надо читать... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Impartial 0 24 января, 2018 Опубликовано 24 января, 2018 (изменено) · Жалоба Если речь идет о CanOpen то принцип выглядит так. У устройств поддерживающих этот стандарт есть всего 4 RXPDO и 4 TXPDO. Каждый из них состоит максимум из 8 байт с структурой определяемой изготовителем устройства. Принцип моста состоит в том, чтобы отзеркалить эти ПДО в приеме и передаче на соответствующие поля в пакете слейва. Все остальное сделает сам CAN интерфейс с соответствующими настройками полей COB-ID. Еще нужно обеспечить возможность настройки CANOpen устройства с помощью пакетов SDO. Но это нужно только на этапе запуска системы. Изменено 24 января, 2018 пользователем Impartial Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться