Контролер для 3-х двигателей. Опции

[Jenya7]

Мне нужно сделать драйвер для 3-х двигателей. Двигатели обычные DC Motors 24V. Двигатели имеют энкодеры для отслеживания позиции.
Хотелось чтоб энкодеры были апаратные. Обычно это делается на таймерах.
Вот задумался какой контроллер выбрать. PWM+Encoders требуют таймера. К тому же на мои нужды нужно еще 3 таймера.
У ST вроде нет контролеров заточенных под motion. У TI есть но что то не хочется связываться с TI. К тому же 3 двигателя. Есть контроллеры под такую задачу?
Основная проблема - аппаратно обработать 3 энкодера. На атмеловских AVRках я пользовался внешними интераптами но это, как мне кажется, не очень хороший способ.

Эскизы прикрепленных изображений

 

[Jenya7]

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

Сообщение отредактировал Jenya7 - Oct 29 2017, 12:27

[AlexandrY]

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

Хороший выбор.
У меня уже вышла 3-я версия этого контроллера.
Но никак руки не дойдут зафиксить и выложить релиз.
Все время идут изменения.
Обязательное условие для применения моего фреймворка это использование RTOS MQX и IAR не выше 7.80.1 поскольку только до этой версии поддерживается плагин для MQX 4.2
Уровень OS abstraction layer я не применяю.

Тут недавно приложение для этой платы сделал - прграммируемый генератор пачек импульсов произвольной скважности.
В пределе на единичном выходе получаю 50% ШИМ частотой 500 кГц с токами до 100А.
В последней моей версии стоит гальваноизолированный CAN.
Можно без опасений соединять CAN-ом разбросанную сеть таких плат управляющих моторами в несколько сот ватт.

[khach]

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

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

[Огурцов]

canopen

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

[khach]

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

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

[Огурцов]

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

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


Сообщение отредактировал Огурцов - Oct 30 2017, 00:22

[khach]

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

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

[mantech]

Эзернет может отличаться непредсказуемым флудом пакетов, который заторомозит любую RTOS до невменяемости.

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

Затормозить могут только кривые руки программиста. Какая бы ни была RTOS, но драйвер MAC-уровня Ethernet пишет всё-таки программист. Если у него есть голова на плечах, то никакой флуд не страшен.

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

[jcxz]

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

У меня вообще задача обслуживания стека Ethernet-а имеет самый низший приоритет. И не может затормозить никого.
А приём/передача пакетов Ethernet выполняются по DMA.

PS: Тут как обычно - тема про плохого танцора которому что-то мешает....

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

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

[khach]

У меня вообще задача обслуживания стека Ethernet-а имеет самый низший приоритет. И не может затормозить никого.

А зачем его делать? Ну потеряются эти пакеты, не получит их программа и что?

Ну у нас же управление движением, по сети идут не только пакеты задания скорости, но и пакеты положения с оптических линеек ( обычно это отдельное устройство со своим адресом).
Потеря пакетов в случае если петля ос по положению заведена через интерфейс чревата непрятностями. А если еще и рассинхронизация осей произойдет.
А прерывания от ДМА по окончанию приема пакета могут перегрузить например прерывания управлени ШИМ BLDC мотора совсем уж с грустными последствиями
А флуд может произойти из за банальности- портальный станок, витая пара идет на подвижную часть шпинделя, постоянно перегибается, протерлась изоляция ( именно витой пары, почему то они это любят). Появляется мерцающий контакт, свитч на станке получает кучу битых пакетов, начинается флуд. Это реальный пример, с весьма печальными финасовыми последствиями, хотя эзернет и был дублированный.
После этого интерфейс подвижной части поменяли на световоды.
Ну и от длительности сервоцикла зависит, мне например требовалось около 2 мсек в вышеописанном примере. Это надо было и датчики позиций осей опросить, и задание раскидать по сервоприводам, и со шпинделя скорость и позицию считать.

[jcxz]

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

Ну это у вас. Непонятно только - зачем вы тогда так сделали?
У нас, например, по Ethernet осуществляется только конфигурирование. Да в будущем будет осуществляться мониторинг возможно.
А задание скорости, передача положения угла ротора и др. критичные по времени операции - по специально для этого выделенным интерфейсам (даже не по общему CAN-у).

А прерывания от ДМА по окончанию приема пакета могут перегрузить например прерывания управлени ШИМ BLDC мотора совсем уж с грустными последствиями

Не могут в принципе. Прерывания по завершению DMA генерятся когда принят очередной пакет DMA. Который в свою очередь может быть принят только если есть свободное место в очереди DMA-пакетов. А это свободное место появляется только в случае обработки и удаления из очереди одного из пакетов низкоприоритетной задачей TCP-стека.
Более того - после обработки очередного RX-пакета, прерывание о завершении RX-DMA следующего пакета может генериться только одно, а на следующие пакеты прерывания генериться не будут, до момента удаления из очереди RX-DMA-пакетов хотя-бы одного пакета задачей TCP-стека.
Т.е. - всё завязано на низкоприоритетную задачу TCP-стека и всё что выше её по приоритету будет работать независимо от её загрузки.
Да и мест пакетов в очереди RX-DMA немного - у меня всего-то их 5 в цепочке.
Если свободного места в очереди RX-DMA пакетов нет, то очередной пакет будет потерян. И выставится флажок о его потере в соотв. регистре контроллера Ethernet.

и со шпинделя скорость и позицию считать.

В текущей задаче у нас считывание и вычисление позиции ротора занимает ~340 тактов CPU. Это вместе с фильтрацией, коррекцией нелинейности, вычислением скоростей и т.п.
С ресольвера или синус-косинусных датчиков. Это на частоте >100 МГц сущие копейки...
Вычисляем её каждый период ШИМ 10кГц.

[khach]

Ну это у вас. Непонятно только - зачем вы тогда так сделали?
У нас, например, по Ethernet осуществляется только конфигурирование. Да в будущем будет осуществляться мониторинг возможно.
А задание скорости, передача положения угла ротора и др. критичные по времени операции - по специально для этого выделенным интерфейсам (даже не по общему CAN-у).

Это не мы, это готовый общепромышленный ethercat.
Если для критической информации есть отдельный CAN то конечно мои замечания теряют смысл.

Если свободного места в очереди RX-DMA пакетов нет, то очередной пакет будет потерян. И выставится флажок о его потере в соотв. регистре контроллера Ethernet.

Интерсный вариант. Хотя возможно и чреват рассинхронизацией, т.к доступен наиболее старый пакет. Мы наоборот старались сохранить самый последний пакет из валидных.
Вот только что с броадкастами делать? Вообще их не обрабатывать? Флуд по ним самый убийственный.

В текущей задаче у нас считывание и вычисление позиции ротора занимает ~340 тактов CPU. Это вместе с фильтрацией, коррекцией нелинейности и т.п.
С ресольвера или синус-косинусных датчиков. Это на частоте >100 МГц сущие копейки...
Вычисляем её каждый период ШИМ 10кГц.

Ну это же не петля положения, а петля скорости. А ШИМ это вообще петля тока/момента, самая быстрая.
Кстати, в случае ресолверов, что там с приоритетом прерываний АЦП? Ресолверы ведь синус-косинусом запитаны? Или два канала в квадратурах на прием? А потом обрабатывать тригонометрию. за 340 тактов никак не управится.