[Impartial 0]

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

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

 

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

 

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

 

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

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

 

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

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

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

 

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

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

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

 

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

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

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

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

 

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

Понятно.

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

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

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

 

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

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

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

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

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

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

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

[Impartial 0]

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

 

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

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

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

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

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

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

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

 

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

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

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

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

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

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

[Impartial 0]

Я имел ввиду сервопривод.

 

Нет там ничего сложного. Я первые опытные реализации укладывал в 120 триггеров первого циклона.

[gosha-z 2]

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

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

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

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

 

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

С чего вдруг? Ethernet по сути своей асинхронен.

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

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

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

 

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

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

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

Я ошибался

[gosha-z 2]

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

Один такт чего?

 

[syoma 1]

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

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

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

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

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

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

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

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

 

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

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

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

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

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

 

to ALL:

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

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

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

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

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

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

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

 

 

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

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

 

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

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

 

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

 

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

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

[syoma 1]

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

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

0%

 

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

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

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

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

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

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

0%

 

 

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

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

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

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

 

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

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

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

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

[syoma 1]

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

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

 

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

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

 

[Вне зоны доступа 0]

del

Изменено 17 января, 2018 пользователем Вне зоны доступа