[khach 33]

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

сразу ethercat - другая крайность, эзернета было бы достаточно, хотя да, это должен был быть точно не обычный эзернет, обычный легко может случиться медленнее чем profibus

Ну да, обычный медный RS485 с телеграммами profidrive разогнанный то ли до 6 то ли до 12 мегабит ( длина кабеля определяла максимальную скорость). Менять это как? Фирмварь сервоприводов недоступна. Конечно можно менять сервоприводы на более продвинутые, с тем же ethercat ( profinet варианта в каталоге просто не было).

 

[gosha-z 2]

Вот решение близко к идеальному. https://geektimes.ru/post/286324/

Автор в этой теме уже выступал.

[AlexandrY 3]

Вот решение близко к идеальному. https://geektimes.ru/post/286324/

Хороший выбор. ;)

У меня уже вышла 3-я версия этого контроллера.

Но никак руки не дойдут зафиксить и выложить релиз.

Все время идут изменения.

Обязательное условие для применения моего фреймворка это использование RTOS MQX и IAR не выше 7.80.1 поскольку только до этой версии поддерживается плагин для MQX 4.2

Уровень OS abstraction layer я не применяю.

 

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

В пределе на единичном выходе получаю 50% ШИМ частотой 500 кГц с токами до 100А.

В последней моей версии стоит гальваноизолированный CAN.

Можно без опасений соединять CAN-ом разбросанную сеть таких плат управляющих моторами в несколько сот ватт.

[khach 33]

В последней моей версии стоит гальваноизолированный CAN.

Можно без опасений соединять CAN-ом разбросанную сеть таких плат управляющих моторами в несколько сот ватт.

Это хорошее дело, особенно при таких токах. А вот можете посоветовать стек протокола в исходниках, на основе которого можно много осей синхронизировать? Желательно совместимый с чем- либо стандартным типа canopen.

 

 

 

[VCucumber 0]

canopen

вам может сильно не хватить мегабита, коль уж двенадцати не хватило

 

 

[khach 33]

вам может сильно не хватить мегабита, коль уж двенадцати не хватило

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

Вообще это отдельная большая тема по выбору интерфейса и протокола для распределенного многоосоевого синхронного движения.

[AlexandrY 3]

Это хорошее дело, особенно при таких токах. А вот можете посоветовать стек протокола в исходниках, на основе которого можно много осей синхронизировать? Желательно совместимый с чем- либо стандартным типа canopen.

Это будет Time Triggered CAN (TTCAN), но моя платформы не поддерживает это. Поэтому пока этим не занимаюсь.

[VCucumber 0]

Вообще это отдельная большая тема по выбору интерфейса и протокола для распределенного многоосоевого синхронного движения.

can неплохой интерфейс для, но ethernet явно не хуже, не вижу никаких причин использовать can и не использовать ethernet

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

 

Изменено 30 октября, 2017 пользователем Огурцов

[jenya7 0]

Хороший выбор. ;)

а где можно взять недостающие файлы? у меня проект не компилируется.

Изменено 30 октября, 2017 пользователем Herz
Избыточное цитирование

[AlexandrY 3]

а где можно взять недостающие файлы? у меня проект не компилируется.

Открываете файл рабочего пространства с названием U3HB_MQXLib.eww в IAR 7.80.1, можно до IAR 7.20

Только что скачал и проверил. Все компилируется.

Чтобы компилировался U3HB_full.eww нужно прислать мне запрос.

[jenya7 0]

Открываете файл рабочего пространства с названием U3HB_MQXLib.eww в IAR 7.80.1, можно до IAR 7.20

Только что скачал и проверил. Все компилируется.

Чтобы компилировался U3HB_full.eww нужно прислать мне запрос.

да. спасибо. в 7.7 компилируется. а какая разница между U3HB_MQXLib.eww и U3HB_full.eww?

Изменено 30 октября, 2017 пользователем Jenya7

[AlexandrY 3]

да. спасибо. в 7.7 компилируется. а какая разница между U3HB_MQXLib.eww и U3HB_full.eww?

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

Можно выбирать между двумя вариантами библиотек: MQX_LIBRARY_O0.a и MQX_LIBRARY_O3.a

Первая без оптимизации, вторая с максимальной оптимизацией по скорости.

[jenya7 0]

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

Можно выбирать между двумя вариантами библиотек: MQX_LIBRARY_O0.a и MQX_LIBRARY_O3.a

Первая без оптимизации, вторая с максимальной оптимизацией по скорости.

понял. спасибо. а можно без MQX? насколько операционка интегрирована в проект? может можно без нее?

Изменено 30 октября, 2017 пользователем Jenya7

[AlexandrY 3]

понял. спасибо. а можно без MQX? насколько операционка интегрирована в проект? может можно без нее?

Без RTOS абсолютно невозможно. Там же и CAN сеть, и USB HS, и куча разных файловых операций, и связь по Bluetooth и т.д. и т.п. Все работает одновременно.

В последней версии добавились две библитеки пространственной ориентации.

Можно пытаться переделать под другую ось.

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

MQX же идет со своим аутентичным промежуточным ПО. Т.е. придется искать под другую ось аналоги USB стека, файловой, логов, менеджеров памяти, и т.д.

[jenya7 0]

Без RTOS абсолютно невозможно. Там же и CAN сеть, и USB HS, и куча разных файловых операций, и связь по Bluetooth и т.д. и т.п. Все работает одновременно.

В последней версии добавились две библитеки пространственной ориентации.

Можно пытаться переделать под другую ось.

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

MQX же идет со своим аутентичным промежуточным ПО. Т.е. придется искать под другую ось аналоги USB стека, файловой, логов, менеджеров памяти, и т.д.

я понял. нет, я хотел отказаться вообще от операционки. у меня CAN, USB HS, Bluetooth, Log, SD и еще куча всего бежали без операционки.