Jump to content

    
Sign in to follow this  
jagdhund

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

Recommended Posts

Зачем в этих пакетах заголовки?

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

 

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

 

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

 

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

по физике езернета.

 

Share this post


Link to post
Share on other sites
Зачем в этих пакетах заголовки?

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

 

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

Но тогда это уже будет не EtherCAT, а какой-то самопальный протокол отдалённо напоминающий EtherCAT.

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

 

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

Тем не менее мир АСУТП развивается именно в этом направлении.

Выбросить все промежуточные стойки контроллеров и рулить всей системой с помощью обычного компа и кабеля. Дёшево и сердито.

Если боитесь и нужна надёжность - поставьте два компа и реализуйте дублирование управления.

 

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

Понятно.

Ну а как вы оцениваете сложность той работы?

Как долго делался проект? В чем заключалась ГЛАВНАЯ СЛОЖНОСТЬ?

Вот если нанять ПЛИСовода "средней руки" как быстро он сможет "врубиться" в тему и сделать слейв?

 

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

по физике езернета.

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

Share this post


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

Мне больше POWERLINK симпатичен из всех видов реал-тайм эзернетов.

Но он не обеспечит цикл 50 мкс при том кол-ве ИУ, что у нас ест в локальной сети

Share this post


Link to post
Share on other sites
Тем не менее мир АСУТП развивается именно в этом направлении.

 

Лет 7 назад я тоже восторженно воспринимал эту концепцию.

На деле оказалось наоборот. Даже яскава бросила эту затею выпускать только усилители к приводам. При том что использовался спец вычислитель а не персоналка. Может Вы и векторное управление собираетесь в компе считать? :)

Вы предлагаете делать самопал при этом рассуждаете о сетевых стандартах.

Попробуйте сначала определить объем вычислений в компе на 1 сервоцикл. А он как я понял 50мкс.

На мой взгляд пустая трата времени.

Плисовод не станет тратить время на копание в пакетах с непредсказуемым результатом.

Если сможете поставить задачу то с этим и студент справится.

 

Share this post


Link to post
Share on other sites
Вы предлагаете делать самопал при этом рассуждаете о сетевых стандартах.

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

Если сможете поставить задачу то с этим и студент справится.

В смысле "студент справится"?

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

Share this post


Link to post
Share on other sites
А телеграмма должна пройти СКВОЗЬ них, то в принципе любой из них может "ЗАПОРОТЬ"телеграмму, "сбившись со счета" из-за помех и сбоев тактового генератора.

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

Ведь когда слейвы вставляют свои данные в телеграмму они же CRC пакета не меняют.

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

 

Share this post


Link to post
Share on other sites
С чего вдруг? Ethernet по сути своей асинхронен.

Ну вот смотрите (это лишь один из возможных сценариев "сбивания" ПЛИСины).

Ошиблась ПЛИСина всего на 1 такт и начала вставлять свои данные не с 12547-го такта, а с 12548-го.

Пакету кирдык.

 

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

Вы тему не читали что ли?

Уже разобрались. Меняют. На лету.

Я ошибался

Share this post


Link to post
Share on other sites
Вот я и стремаюсь. У меня в цеху жесткая электромагнитная обстановка (инверторы, сварочные автоматы, плазменная резка, куча силовых контакторов и реле клацают, станки шумят и ШИМят и т.п.), а я ещё 8 территориально разнесенных EtherCAT слейвов в цепочку поставить хочу.

Насколько надёжно все это будет работать?

Не получится ли так, что каждый второй пакет будет битый.

Но это еще полбеды.

А вот что два ПОДРЯД и более пакетов будут битыми - вот это пипец.

Потому что у ИУ цикл должен быть порядка 50 мкс.

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

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

 

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

Share this post


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

"Нормально" - это не инженерный термин.

Какой процент "битых" пакетов?

 

to ALL:

Уважаемые господа русские специалисты по EtherCAT!

Подскажите пожалуйста.

Если слейву (в зависимости от его состояния) нужно передавать то 1 байт, то 1 кБайт. То как быть? Как в EtherCAT разруливается такая ситуация?

Постоянно резервировать 1 килобайт в пакете не хотелось бы. Бо не эффективное использование пропускной способности канала.

Я к тому, что можно ли динамически менять границу данных каждого слейва в пакете?

Если совсем "на пальцах", допускает ли стандарт на EtherCAT такое поведение слейва, когда он то читает (или пишет) то байты 45...56, а то 20...1433

"Дробить" дамп и отправлять в несколько заходов тоже не айс.

 

 

И ещё, господа, вопрос.

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

 

Сколько пропускной способности "сожрёт" IEEE1588?

И как загрузка канала пакетами IEEE1588 повлияет на джиттер и время цикла основных пакетов

 

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

 

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

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

Share this post


Link to post
Share on other sites
Нормально" - это не инженерный термин.

Какой процент "битых" пакетов?

0%

 

Если слейву (в зависимости от его состояния) нужно передавать то 1 байт, то 1 кБайт. То как быть? Как в EtherCAT разруливается такая ситуация?

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

Если у вас есть входы/выходы, которые нужно читать/обновлять каждые 25мкс и, например, другие входы/выходы, которые можно обновлять реже, например раз в 1мс, то вы попросту конфигурируете систему с двумя разными фреймами, первый из которых генерируется раз в 25мкс,, а второй - раз в 1мс.

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

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

Share this post


Link to post
Share on other sites
0%

 

 

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

Если у вас есть входы/выходы, которые нужно читать/обновлять каждые 25мкс и, например, другие входы/выходы, которые можно обновлять реже, например раз в 1мс, то вы попросту конфигурируете систему с двумя разными фреймами, первый из которых генерируется раз в 25мкс,, а второй - раз в 1мс.

Спасибо. Понял.

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

 

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

А разве Distributed clock не понятие из IEEE1588?

И по поводу трафика и увеличения латентности с джиттером из-за пакетов синхронизации распределенных часов не ответили.

Насколько пакеты синхронизации "забивают" линию?

Share this post


Link to post
Share on other sites
POWERLINK тоже протокол реального времени. Но там можно и "реальные" маленькие данные передавать и "не реальные" большие (типа видео с камер наблюдения)

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

 

А разве Distributed clock не понятие из IEEE1588?

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

 

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this