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

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

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

 

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

 

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

 

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

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

 

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


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

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

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

 

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

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

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

 

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

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

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

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

 

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

Понятно.

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

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

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

 

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

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

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

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


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

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

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

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

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


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

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

 

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

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

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

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

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

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

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

 

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


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

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

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

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

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

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

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


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

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

 

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

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


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

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

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

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

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

 

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


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

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

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

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

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

 

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

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

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

Я ошибался

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


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

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

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

 

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


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

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

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

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

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

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

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

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

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

 

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

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


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

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

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

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

 

to ALL:

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

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

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

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

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

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

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

 

 

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

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

 

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

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

 

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

 

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

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

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


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

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

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

0%

 

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

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

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

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

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

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


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

0%

 

 

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

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

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

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

 

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

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

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

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

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


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

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

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

 

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

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

 

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


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

del

Изменено пользователем Вне зоны доступа

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


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

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

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

Гость
К сожалению, ваш контент содержит запрещённые слова. Пожалуйста, отредактируйте контент, чтобы удалить выделенные ниже слова.
Ответить в этой теме...

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

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

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

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

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

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