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

Ну как же. Если во фрамэ нет адреса слейва в общем "логическом пространстве задачи" то он игнорирует такой пакет (не использует его и ничего не пишет в него). Слейв "вылавливает" и реагирует только на свои адреса. Или я не прав? Т.е., грубо говоря, у PHY микросхемы есть сигнал "connection failed", который заводится в ПЛИСину? Может потому, что это никому было не нужно? Или ещё вариант: никто просто не знал о такой возможности А что мешает мастеру менять этот "physical-logical mapping" на лету? Но моя идея была даже не в этом. Вы говорили, что каждый слейв реагирует только на свой диапазон адресов в общем 4-х гигабайтном логическом пространстве задачи. Тогда что мешает мастеру читать только один слейв, чтобы этот слейв занял весь пакет, все 1498 байт? Вы не совсем поняли. И ухудшения не будет. Моя идея в том: зачем слейву ЗРЯ тратить трафик если ему НЕЧЕГО передавать мастеру? Разве не разумно будет отдать в этом случае весь трафик слейву, у которого есть что передавать и который "зашивается" уже от потока событий по причине не хватки трафика?

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

Вы уверены в этом? Потому что в доках я читал, что слейв реагирует только на пакеты, приходящие на upstream-порт. Пакеты приходящие на downstrean-порт слейв просто перебрасывает на upstream-порт. Возможно я не правильно понял доки. А как ПЛИСина понимает, что к RX2/TX2 ничего не подключено? И как быстро? И вопрос насчет кол-ва ПЛИСин остался открытым: получается все 4 сто магабитных порта обслуживаются одной ПЛИСиной? Не понял. Разве слейву предназначен не КАЖДЫЙ пакет мастера? Ведь слейв жёстко конфигурируется на обработку ОДНИХ И ТЕХ же жестко заданных (зарезервированных для него) полей пакета. Или это не так?

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

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

Какие логи. Устройств ещё нет. Даже в проекте. Пока только общая архитектура системы прорабатывается

Такую чушь мог написать только полный кретин и неадекват. Если речь шла о простых текстовых логах, то можно было привести отдаленный непохожий пример, прояснить суть обработки. Она может быть как просто и идеально ложиться на элементную базу ПЛИС, так и быть вовсе нереализуемой. Мне часто приходится решать рабочие задачи, обращаясь за помощью, при этом я стараюсь как могу дать отдаленный пример, относящийся к сути дела, но не раскрывающий общую задачу. То что Вы сделали на форуме - это просто насрали всем в душу, потрепали нервы и отняли время у уважаемых мной специалистов. Советую полечить голову, набраться воспитания, устроил он бесплатный ликбез нам, мать его, калач бляха муха. Идите к черту, уважаемый. Вам лечиться надо Я не знаю что это такое. И чего от меня хотят

Мы вроде с Вами пока не заключали контракт

Так мне и надо очень примитивные процессоры. Самая крутая и навароченная ПЛИСина стоит 10000евро. Получается что 1 процессор будет стоить 100 евро. Копейки же А в интернете я читал, что как раз для этого и нужна плисина. Для распаралеливания обработки. В этом её назначение и преимущество Вот вот. Именно это я и имел в виду. "Врожденная" параллельность ПЛИС :beer: Она меня привлекает и возбуждает

.

Ключевое слово здесь "резервируется фрейм". Т.е. есть у тебя в данный момент данных (простите за невольную тавтологию), которые нужно срочно передавать нету, фрейм всё равно резервируется и трафик тратится вхолостую (если данных нет). Что мешает ДИНАМИЧЕСКИ (по команде мастера) реконфигурировать размеры фреймов для каждого слейва? Не знаю, где Вы видели "много", а я кроме общих слов, что в EtherCAT есть некая технология "распределенных часов" ничего не нашёл. Интересует главным образом как механизм "синхронизации часов" повлияет на общую пропускную способность, джиттер и Latence Time. И ещё такая заковыка. У меня цикл 50 мкс. А если после синхронизации часы сдвинутся на 200 мкс. Не приведёт ли это к катастрофе? Ведь система воспримет это как скачок тока. Т.е., к примеру, ток рос на 2ма за 50мкс, а то вдруг вырос на 10 (из-за того, что время на часах искусственно сдвинули)

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

Я об этом не просил. Задача в другом

Нет. У меня представление, что на ПЛИС можно реализовать "сколько хош" мокропроцессоров. А это как раз то, что мне нужно: очень много параллельно работающие микропроцессоров в одном чипе Вся идея в картинке: И в который раз повторю "зачем но надо" Есть тыща устройств. У каждого устройства есть контроллер. 1000 устройств связаны 1000 контроллеров 1000 кабелями А я хочу сделать так: 1000 устройств 3 кабеля (можно 1, но вдруг оборвётся). А контроллеры загнать в одну ПЛИСину. Что тут непонятно?

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

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

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

Нет. Мне нужен СТАНДАРТНЫЙ EtherCAT слейв В смысле "студент справится"? С реализацией приема и передачи "на лету" данных по EtherCAT?

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

Потому что этого требует 803-й стандарт Но тогда это уже будет не EtherCAT, а какой-то самопальный протокол отдалённо напоминающий EtherCAT. Тут вопрос возникает: если любой подросток на коленке сможет сделать на ПЛИСине этот протокол, то чего тогда оборудование бекхофа стоит таких огромных бабок? Тем не менее мир АСУТП развивается именно в этом направлении. Выбросить все промежуточные стойки контроллеров и рулить всей системой с помощью обычного компа и кабеля. Дёшево и сердито. Если боитесь и нужна надёжность - поставьте два компа и реализуйте дублирование управления. Понятно. Ну а как вы оцениваете сложность той работы? Как долго делался проект? В чем заключалась ГЛАВНАЯ СЛОЖНОСТЬ? Вот если нанять ПЛИСовода "средней руки" как быстро он сможет "врубиться" в тему и сделать слейв? Ну да. Именно ради короткого цикла она нам и нужен.

А вроде бы по стандарту минимальная длина пакета 64 байта. С преамбулой 72 байта. Или 576 бит. При скорости 100Мбит/с получается, что цикл шины не может быть короче 5.76 мкс Так? Это раньше так считалось. Что нужен распределенный интеллект. Но с появлением EtherCAT всё изменилось. Теперь Вам не нужны контроллеры "на местах". Всем рулит один обычный писюк по езеркату. И в ПЛК нет никакой надобности. Что существенно удешевляет АСУТП Да да. Именно так говорится в рекламных буклетах по эзеркату Впервые слышу этот термин, хотя АСУТП занимаюсь более 30 лет Impartial Про доки не ответили. Где брали инфу (и какую конкретно) при разработке EtherCAT слейва?

Управление позиционированием станков Там нужно каждый 50мкс подавать управляющий сигнал на ЦАПы. Не успеем - будет сбой позиционирования на доли мм. И брак А вообще Какой минимальный цикл у этеркота? А то в инете данные разнятца. Кто-то пишет по 6 мкс, кто-то про 30, кто-то про 100, кто-то (как Вы к примеру) про 1 мс Кому верить? Что значит "сканер"? EtherCAT мастер? Или WireShark ? Редко это как? 1 на 10^12? (требование к маршрутизаторам интернета) Т.е. Вам было достаточно открытой инфы, имеющейся в инете? Ничего у бекхова не покупали? А где, кстати, доки брали, которые использовали при написании слейва? Ссылка есть?

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

Допустим. Что слейв может подсчитывать "на лету" CRC принимаемого пакета. Но для этого нужно реализовать схему на логических вентилях. Считать "на лету" CRC программным путем с помощью микроконтроллера не получится. Так? Потому что операция CRC-сложения занимает не один так процессора Что значит "никто не модифицирует"? Если слейв вставил какие-то свои данные в пакет, то он должен и CRC, пакета переписать. Ведь она изменилась. Так? Тут возникает проблема. Допустим переписать он её сможет. Но ведь целостность ПРИНЯТОГО пакета он никак не проконтролировал. Поясню. Допустим данные слейва находятся а 25-м байте от головы пакета. А CRC - а 154-м байте Слейв считывает свои данные на 25-м байте и начинает их использовать ДАЖЕ НЕ ПРОВЕРИВ CRC, потому что она еще не дошла. Она ещё "в пути". И формирует ответные данные которые вставляет в 26-й байт А вдруг пакет "битый" был? В результате слейв отработал некорректно Да хоть CRC128 - это не принципиально. Принципиально: считает или нет Вы хотите сказать, что там всё врут? И в каком конкретно месте там врут? Это очевидно. Вот же картинка Только проблема, что слейв может писать только в определенный выделенный ему тайм-слот пакета, а не в весь пакет Это я уже понял. Также понял, что для подсчета CRC "на лету" нужна ПЛИСина. На MCU общего назначения EtherCAT слейв не реализуешь. Так? А ПЛИСине да. А вот на MCU - большая проблема Задержка таки есть. Вы же сами написали: Т.е. есть задержка по крайней мере на 1 цикл шины Т.е. без того, чтобы отстегнуть кругленькую сумму фирме Beckhoff (Германия) реализовать полноценный EtherCAT слейв не получится? Вы сами, лично, реализовали "с нуля" EtherCAT слейв на ПЛИСине не платя ничего фирме Beckhoff? Или Вы чисто теоретически говорите? И в техасе, и у хилшера, и ... да много у кого есть И все же остался открытым вопрос по надёжности реализации Кто-нибудь проводил такие исследования? Есть инфа по этому вопросу? А какой процент битовых ошибок? Ведь если посмотреть ещё раз на картинку То каждый из 6-ти слейвов может "запороть" всю телеграмму А наличие 12 (!!!) промежуточных кабелей... Тоже надежность не увеличивают И повторю это: © Вообщем в рекламе все просто замечательно. А как в жизни? Если 6 и более слейвов в цепочке и тяжелая электромагнитная обстановка в цеху? Как себя поведет система на EtherCAT?

Вы не ёрничайте. Чай не Петросян. Скажите конкретно. Считает слейв CRC16 или нет после того как модифицирует пакет? И каким образом он сможет сделать это корректно если он ещё не получил "хвост" от пакета (к котором и находится CRC) когда уже следующий слейв в цепочке начал вставлять свои данный и менять пакет, а предыдущий слейв об этом НИЧЕГО НЕ ЗНАЕТ См. видео https://upload.wikimedia.org/wikipedia/comm...gPrinciple.webm Да куда уж нам. С суконным то рылом, да в калашный ряд P.S. И таки да.Последний слейв в цепочке слейвов если он считывает и вставляет свои данные в конц пакета, непосредственно перед CRC16, то таки да он должен сформировать CRC16 за доли наносекунды. Потому что после последнего бита данных начинается бит CRC Правда при подсчёте нужно будет за доли наносекунды добавить к CRC16 только последнее слово данных пакета и тем не менее. Выполнить это надо за время, существенно меньшее битового интервала, который равен для 100 МБит/с 10 наносекундам И как быть с этим © Зачем? Разве этот протокол не открытый?