[syoma 1]

У устройств поддерживающих этот стандарт есть всего 4 RXPDO и 4 TXPDO

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

Еще нужно обеспечить возможность настройки CANOpen устройства с помощью пакетов SDO. Но это нужно только на этапе запуска системы.

Я думаю, что вот это самое интересное. Мастер сможет это сделать через EtherCAT-CANopen интерфейс? Судя по описанию на EL6751 - да. Ну а вообще там много чего интересного в мануале расписано.

 

 

[Impartial 0]

Это максимальное количество ПДО.

 

СДО это всего один кадр на передачу и прием.

Просто мастер должен поддерживать стандарт DS 301.

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

Каждый слейв имеет строго определенную внутреннюю структуру. Ни о каком изменении длины не может быть речи.

Для каждого слейва есть конфигурация и конфигурационный файл. Общая длина пакета складывается у мастера на этапе конфигурации приложения и может измениться только при реконфигурации. Слейв может пропускать через себя чужие пакеты но к приложению они не имеют никакого отношения. Идентификация встроена в сам пакет.

Ну как же. Если во фрамэ нет адреса слейва в общем "логическом пространстве задачи" то он игнорирует такой пакет (не использует его и ничего не пишет в него). Слейв "вылавливает" и реагирует только на свои адреса.

Или я не прав?

Почему смущает количество обрабатываемых в плисине потоков? Там максимальная частота 50 мгц. Одна плисина может их хоть сто штук обработать. Хватило бы ножек и триггеров внутри. Это же не микроконтроллер. В плисине все обрабатывается параллельно.

Т.е., грубо говоря, у PHY микросхемы есть сигнал "connection failed", который заводится в ПЛИСину?

Ну собственно, наверное и так можно. Только вот лично мне мешает то, что я никогда такого ни в одном мастере не видел.

Может потому, что это никому было не нужно?

Или ещё вариант: никто просто не знал о такой возможности

То есть если взять любой доступный мастер - TwinCAT или Codesys и посмотреть, как у него сделан EtherCAT обмен тем же Wiresharkом, то все очень примитивно. После того, как все запустилось, мастер конфигурирует в слейвах т.н. physical-logical mapping

А что мешает мастеру менять этот "physical-logical mapping" на лету?

Но моя идея была даже не в этом.

Вы говорили, что каждый слейв реагирует только на свой диапазон адресов в общем 4-х гигабайтном логическом пространстве задачи.

Тогда что мешает мастеру читать только один слейв, чтобы этот слейв занял весь пакет, все 1498 байт?

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

Вы не совсем поняли.

И ухудшения не будет.

Моя идея в том: зачем слейву ЗРЯ тратить трафик если ему НЕЧЕГО передавать мастеру?

Разве не разумно будет отдать в этом случае весь трафик слейву, у которого есть что передавать и который "зашивается" уже от потока событий по причине не хватки трафика?

[syoma 1]

А что мешает мастеру менять этот "physical-logical mapping" на лету?

Для этого надо перевести нужный слейв в конфигурационный режим и записать в него новые параметры. "На лету" это не очень получится.

Моя идея в том: зачем слейву ЗРЯ тратить трафик если ему НЕЧЕГО передавать мастеру?

Разве не разумно будет отдать в этом случае весь трафик слейву, у которого есть что передавать и который "зашивается" уже от потока событий по причине не хватки трафика?

По-моему это была одна из основных причин появления EtherCAT. Тот же CANopen исповедует вашу модель, так как он построен на принципе "передавай, если есть что передать". Это отлично снижает нагрузку на сеть, но создает огромную проблему для проектировщика, заключающуюся в том, что сеть должна быть рассчитана на случай, что все вдруг начнут передавать свои данные одновременно. Иначе вы получите недопустимые задержки, если не потерю данных.

Поэтому люди искали такую шину, которая позволяла бы получить большую пропускную способность, независящую от количества слейвов и их желания или нежелания передавать данные и имеющую гарантированную латентность и минимальное время цикла без каких-либо компромиссов, типа "передачи" трафика какому либо конкретному слейву, если ему вдруг это требуется и пр. Это и есть требования реального времени.

 

[Димыч 0]

Если речь идет о CanOpen то принцип выглядит так.

У устройств поддерживающих этот стандарт есть всего 4 RXPDO и 4 TXPDO.

Каждый из них состоит максимум из 8 байт с структурой определяемой изготовителем устройства.

Принцип моста состоит в том, чтобы отзеркалить эти ПДО в приеме и передаче на соответствующие поля в пакете слейва.

Все остальное сделает сам CAN интерфейс с соответствующими настройками полей COB-ID.

Еще нужно обеспечить возможность настройки CANOpen устройства с помощью пакетов SDO. Но это нужно только на этапе запуска системы.

 

Спасибо, Impartial.

Благодарю, syoma.

 

Собственно, в моём случае речь идёт о ModBus (CAN где-то в неясной перспективе) и есть ли какие то соглашения о том, как ему дружить с EtherCAT, я сходу не нашёл.

 

Но пока вопросы более общие, а именно:

1) какой софт имеет смысл использовать для наиболее быстрого старта и поддержки разрабатываемого устройства (мост: слейв для EtherCAT и он же мастер для ModBus)?

На сайте https://www.ethercat.org/en/products.html есть список, но - возможно - опытные товарищи сразу скажут, мол это использовать не стоит, а вот это - хороший Tool...

Да, TwinCAT XAE установил, но пока с ним ничего не взлетело: винда с ним периодически уходит в синий экран, а тестовый ESC он не видит.

 

Пока что для себя сделал такой список:

 

"ET9000 Beckhoff (EtherCAT Configurator)"

EtherCAT Workbench

XML Editor (есть)

Network Analyzer (есть)

Что-то ещё нужно для взлёта? :)

 

2) организационный вопрос: сколько времени и ресурсов может уйти (уйдёт) на разработку слэйва, готового для передачи в производство?

Очевидно, что должны быть реализованы функциональности:

- сам мост

- Device Firmware Update (нужно через Ethernet порт слейва обновлять Firmware Host-процессора, который соединён с EtherCAT ASIC'ом через SPI DP-RAM)

- удобная первичная прошивка

- самодиагностика

- документация

- сервисный софт (конфигуратор? апдейтер? что-то ещё?)

 

Опять же, как черновой вариант, процесс выглядит так (и занимает полтора человеко-года):

 

Prototyping

Stand Seting-Up

Running a test application on Eval Board (EVB)

Writing a communication between EVB and a Modbus device

Running the tests with Prototype Gateway (купить готовый мост) and ModBus

Running the tests with 3-rd party’s EtherCAT devices

 

PCB and Housing

Power Dissipation/Thermal Evals

Suggestions concerning Housing and PCBs arrangement

Schematics

Layout

PCBA

Tests and Evaluations

 

Firmware

Boot-loading and DFU Functionality

HAL and low-level drivers/functions

POST and Debug Interface

CDC VCP - for Debug interface and optional DFU

MODBUS Stack

Working with API from EtherCAT ASIC supplier

Porting to a lower-grade MCU

 

Software

Ethernet Device Set-Up

Configuration Software

Firmware Upgrade Utility

 

Re-Design to Cost

Eliminating unused components (e.g., QSPI EEPROM), replacing Ethernet connector, …

Firmware modifications

Software’s changes

Performing the test

Issuing documentation

 

in-house tests (protocol and EMC)

EMC tests

Protocol conformance

 

Documentation

User Manual

Ethernet Configuration

Programming Guide and Examples

(Sample) Configuration Files

ESI / GSD(ML) Files

Certificates

[Arjun 0]

Для этого надо перевести нужный слейв в конфигурационный режим и записать в него новые параметры. "На лету" это не очень получится.

Почему? Что мешает?

 

По-моему это была одна из основных причин появления EtherCAT. Тот же CANopen исповедует вашу модель, так как он построен на принципе "передавай, если есть что передать". Это отлично снижает нагрузку на сеть, но создает огромную проблему для проектировщика, заключающуюся в том, что сеть должна быть рассчитана на случай, что все вдруг начнут передавать свои данные одновременно. Иначе вы получите недопустимые задержки, если не потерю данных.

Поэтому люди искали такую шину, которая позволяла бы получить большую пропускную способность, независящую от количества слейвов и их желания или нежелания передавать данные и имеющую гарантированную латентность и минимальное время цикла без каких-либо компромиссов, типа "передачи" трафика какому либо конкретному слейву, если ему вдруг это требуется и пр. Это и есть требования реального времени.

А в чем проблема делать два цикла.

В первом цикле опрашиваем у кого есть срочные данные. И если ни у кого нет - во втором цикле отдаем трафик тому, у кого есть что передедавать?

 

Получается и рилтайме не нарушается и линия используется более эффективно за счет того, что не нужно гонять пустые пакеты

 

Как думаете?

 

 

Допустим есть два девайса.

Один нужно опрашивать каждый 6 мкс. А другой - раз в 10 мс.

И какой смысл тогда второму устройству передавать пустые фреймы каждый 6 мкс если у него состояние обновляется раз в 10 мс?

[Impartial 0]

Любая попытка использовать какую либо адресацию подразумевает использование общих полей в пакете.

Это противоречит идеологии реалтайма.

 

Вообще езеркат хорошо работает только на специально спроектированном для него оборудовании мастера.

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

Попытка запустить драйвер будет приводить к синим экранам на одних компьютерах и нормальной работе на других.

 

Есть такая любительская система управления станками ЧПУ LinuxCNC. Она с открытым исходным кодом и я много интересного узнал разбирая некоторые куски кода.

Там есть исходник драйвера езерката и его нормальная работа гарантируется только на нескольких чипах.

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

[syoma 1]

Собственно, в моём случае речь идёт о ModBus (CAN где-то в неясной перспективе) и есть ли какие то соглашения о том, как ему дружить с EtherCAT, я сходу не нашёл.

Сходу все ИМХО очень просто - берете EtherCAT терминал с RS485 или RS232. Он делает Вам виртуальный COM порт. Далее берете обыкновенный Modbus мастер и общаетесь через этот порт со своими MODBUS слейвами. Или Вам надо что-то другое?

 

Вам вообще нужно просто что-то в единственном экземпляре для своего проекта? Тогда проще купить что-то готовое. А если разрабатывать для продажи - вы уверены, что найдете много клиентов, чтобы окупить разработку?

 

1) какой софт имеет смысл использовать для наиболее быстрого старта и поддержки разрабатываемого устройства (мост: слейв для EtherCAT и он же мастер для ModBus)?

На сайте https://www.ethercat.org/en/products.html есть список, но - возможно - опытные товарищи сразу скажут, мол это использовать не стоит, а вот это - хороший Tool...

Да, TwinCAT XAE установил, но пока с ним ничего не взлетело: винда с ним периодически уходит в синий экран, а тестовый ESC он не видит.

TwinCAT 3 эволюционный. С готовыми EtherCAT модулями Codesys также неплохо работает, но нужно подключить XML описания.

 

А в чем проблема делать два цикла.

В первом цикле опрашиваем у кого есть срочные данные. И если ни у кого нет - во втором цикле отдаем трафик тому, у кого есть что передедавать?

Получается и рилтайме не нарушается и линия используется более эффективно за счет того, что не нужно гонять пустые пакеты

Как думаете?

Допустим есть два девайса.

Один нужно опрашивать каждый 6 мкс. А другой - раз в 10 мс.

И какой смысл тогда второму устройству передавать пустые фреймы каждый 6 мкс если у него состояние обновляется раз в 10 мс?

Давайте сначала посчитаем реальность всего этого для EtherCAT. Вообще я не очень понимаю, что мастер успеет сделать за 6мкс с данными, но допустим успеет и цикл опроса у нас 6мкс. При скорости в 100Мбит за 6мкс мы успеваем передать/получить 600бит или 75 байт - a это в принципе минимальная длина Ethernet пакета. То есть при цикле опроса в 6мкс даже один самый маленький пакет полностью забьет нашу шину. Куда вы собрались всовывать пакет для 10-милисекундного опроса?

 

Вообще езеркат хорошо работает только на специально спроектированном для него оборудовании мастера.

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

Попытка запустить драйвер будет приводить к синим экранам на одних компьютерах и нормальной работе на других.

Не встречался с особыми проблемами. Нужна нормальная сетевуха, да и все вроде. Работал и с TwinCAT и с Codesys. Последний, кстати с EtherCAT работает даже на Raspberry Pi и не глючит. Конечно, не стоит ожидать от него реального времени с обычной операционкой.

[Димыч 0]

Сходу все ИМХО очень просто - берете EtherCAT терминал с RS485 или RS232. Он делает Вам виртуальный COM порт. Далее берете обыкновенный Modbus мастер и общаетесь через этот порт со своими MODBUS слейвами. Или Вам надо что-то другое?

 

Вам вообще нужно просто что-то в единственном экземпляре для своего проекта? Тогда проще купить что-то готовое. А если разрабатывать для продажи - вы уверены, что найдете много клиентов, чтобы окупить разработку?

 

 

TwinCAT 3 эволюционный. С готовыми EtherCAT модулями Codesys также неплохо работает, но нужно подключить XML описания.

 

Доброго дня!

 

Да, выглядит действительно просто и легко. Вопросы, тем не менее, тоже есть :) :

Драйвер берём (покупаем лицензию под ТвинКАТ) от Бекхофа (драйвер)?

Но тогда это тянет за собой и покупку Твинката, разве нет? А какой порядок его стоимости (в отличие от бесплатного XAE) ?

 

Этот драйвер ведь будет работать только с Бекхофскими coupler'ами и терминалами типа этого и этого, так ведь? А хочется сделать свой слейв со своими VID, ESI и пр.

 

Эх, если бы единственное, то и не вопрос. Но нужно для масс-продакшен. Окупаемость - вопрос правильный, но на разработку выделяются (пока что) просто копейки. Опять же, сколько, в норме, может стоить разработка такого девайса (а-ля Serial Interface от Beckhoff)?

 

 

А с ТвинКАТом, наверное, всё хорошо. Но пока он у меня разве что комп вешает :) И будущий вопрос генерации отчуждаемой программы, сделанной на нём, также остаётся.

 

Спасибо!

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

Любая попытка использовать какую либо адресацию подразумевает использование общих полей в пакете.

Это противоречит идеологии реалтайма.

Говорите, что нет никакой адресации?

А это Вы видели?

 

Вообще езеркат хорошо работает только на специально спроектированном для него оборудовании мастера.

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

Попытка запустить драйвер будет приводить к синим экранам на одних компьютерах и нормальной работе на других.

 

Есть такая любительская система управления станками ЧПУ LinuxCNC. Она с открытым исходным кодом и я много интересного узнал разбирая некоторые куски кода.

Там есть исходник драйвера езерката и его нормальная работа гарантируется только на нескольких чипах.

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

Вместо пространной демагогии лучше ответьте на вопрос:

Допустим есть два девайса.

Один нужно опрашивать каждый 6 мкс. А другой - раз в 10 мс.

И какой смысл тогда второму устройству передавать пустые фреймы каждый 6 мкс если у него состояние обновляется раз в 10 мс?

 

 

Давайте сначала посчитаем реальность всего этого для EtherCAT. Вообще я не очень понимаю, что мастер успеет сделать за 6мкс с данными, но допустим успеет и цикл опроса у нас 6мкс. При скорости в 100Мбит за 6мкс мы успеваем передать/получить 600бит или 75 байт - a это в принципе минимальная длина Ethernet пакета. То есть при цикле опроса в 6мкс даже один самый маленький пакет полностью забьет нашу шину. Куда вы собрались всовывать пакет для 10-милисекундного опроса?

Что значит "забьёт шину"?

Если мы как раз для этого его и используем, чтобы шину загрузить на 100% (хотя на 100 все равно не получится).

А насчет "всовывать" не понятно, что Вы имеете в виду

 

[syoma 1]

И какой смысл тогда второму устройству передавать пустые фреймы каждый 6 мкс если у него состояние обновляется раз в 10 мс?

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

Каждый слейв может вставлять свои данные в фрейм или нет. Зависит от того, как он сконфигурирован.

 

[Arjun 0]

.

Изменено 26 января, 2018 пользователем Arjun

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

Вся прелесть EtherCAT

У меня возникли сомнения. Насчёт "прелести"

 

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

Уточню. Под пустыми я подразумевал Фреймы, не несущие новой информации и НАПРАСНО "забивающие" линию связи своим трафиком. Т.е., к примеру, если в устройстве состояние меняется раз в 10 мс, а цикл шины 6мкс, то получается, что более 99% времени он передают "порожняк"

Как быть в этом случае?

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

[AlexandrY 3]

Уточню. Под пустыми я подразумевал Фреймы, не несущие новой информации и НАПРАСНО "забивающие" линию связи своим трафиком. Т.е., к примеру, если в устройстве состояние меняется раз в 10 мс, а цикл шины 6мкс, то получается, что более 99% времени он передают "порожняк"

Как быть в этом случае?

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

Система каждый цикл должна подтверждать свое состояние.

Проверяется горьким опытом.

Тут вот буквально на днях под Гамбургом объект у нас работает на шине CAN и есть частотник.

Система взяла и ушла в ступор, в логе сообщение об отключении сетевого напряжения. А отключения не было.

По CAN-у из-за наводок с частотника прошел ложный пакет об отключении и CRC не помогло, а передавались такие пакеты только по событию отключения и включения напряжения.

Такая вот история. Сейчас надо править программу.

 

 

 

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

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

Система каждый цикл должна подтверждать свое состояние.

Ну вот смотрите.

Если система инерционная и за 10 мс в ней НИЧЕГО не может случиться по определению. То смысл передавать её состояние каждые 6 мкс?

 

А ведь такое бывает сплошь и рядом. Что на шине EtherCAT "висят" как быстрые устройства, так инерционные.

И как тут быть?

Передавать "порожняк" впустую расходуя драгоценный трафик?

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