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

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

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

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

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

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

Первый использует скомпилированную библиотеку MQX, второй компилирует вместе с исходниками MQX.
Можно выбирать между двумя вариантами библиотек: MQX_LIBRARY_O0.a и MQX_LIBRARY_O3.a
Первая без оптимизации, вторая с максимальной оптимизацией по скорости.

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

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

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

Если у вас есть свое промежуточное ПО взамен тому что есть у MQX, то конечно вы можете все сделать без RTOS.
Но у меня половина прерываний в драйверах используют объекты событий.
Даже не знаю чем вы их сможете заменить без RTOS. Циклами ожидания?

у меня был один суперцикл с флагами от прерываний + поллинг + state machine. не идеально но хватало. хотя там не было драйвера 3-х фазного двигателя со всей его алгоритмикой и наворотами.

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

И кто вас этому обязывает?


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

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



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

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

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


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

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

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


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


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

или стек переписать

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



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

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

Что значит старый или не старый пакет? Естественно DMA-пакеты обрабатываются стеком в порядке их прихода. Если в очереди их сразу несколько, то естественно первым будет обработан самый старый в очереди. А как иначе TCP-стек ещё может работать?
И в чём проблема броадкастов? Они принимаются в ту же самую очередь DMA-блоков. И обрабатываются тем же самым стеком. Если там нет места - пропуск.


да.


Управится. Вот именно в эти 340 тактов и укладывается вычисление арктангенса угла по полученным синусу и косинусу. И прочие вычисления.
Прерывания АЦП синхронизированы с периодом ШИМ.
Арктангенс - по таблице.
Все вычисления - в фиксированной точке.

А Ethernet flow control не судьба была сделать?
По мне так наиболее логичный путь для тех кто не на EtherCat-е.

А что - это разве спасёт от флуда, о котором говорит khach?
А при штатной работе и так всё успевает с любым наполнением web-сервера. А может даже flow-control уже включён, не помню уже тонкостей.

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

5 страниц, задача не озвучена.
Управление мотором:
- алгоритм - как мотор должен работать?
- диапазон рабочих скоростей?
- точность позиционирования в движении?
- точность позиционирования при остановке?
- частота импульсов датчика?
- время реверса?
- целевая цена?
... и еще куча вопросов

Зато разговор о веб-сервере

Нашел вот такое чудо.
http://www.allegromicro.com/en/Products/Mo...rs/A3930-1.aspx
Это ж просто праздник какой то. Получается не нужно никаких FOC библиотек в камне? Пару управляющих пинов и вопрос решен?

Замените файлы ссылками.

Они ж только модуляцию обеспечивают и только трапецию.
FOC же включает тюнинг PI контроллера момента, этого никакая логика не заменит.

от Allegro A4964 интереснее будет.

А если мне не нужны особые требования к системе? Я вижу там есть выходы позиция и ток наружу. Я могу их отслеживать и реагировать соответсвенно.


Не пойму принцип. Входов HALL нет , B-EMF тоже нет а какая обратная связь? неужели по току, по одному шунту?

Тогда валяйте.
Я делал на них контроллер на 1.5 КВт.
В принципе остался доволен. Но с цепями измерения тока пришлось повозиться.
Нажмите для просмотра прикрепленного файла

там ток меряется на одном шунте насколько я понимаю. нужно что то добавлять?

Да, у меня стоял 0.002.
Вот недавний возврат после 6-и лет службы.
Выгорел этот шунт из-за переполюсовки. На фото он уже снят.
Транзисторы остались целы, но A3930 выгорел.
Он всегда самый первый выгорает, если что. Так что лучше от него отгородиться гальваноизоляцией.
Нажмите для просмотра прикрепленного файла

так может шунт поставить большей мощности? у вас сколько ватт было?
или поставить защиту от переполюсовки.

А цель? Слышали такой термин - управление качеством?
Управление это не только повышение, но и понижение.

ну вобщем то я так понимаю это решение вопроса. а пины TACHO и CSOUT дадут мне позицию и ток?

TACHO и DIR дадут позицию.
В некоторых случаях дерганья мотора их будет трудно отследить.
CSOUT даст ток.
Но опять же, чтобы не принимать шум надо измерение синхронизировать с ШИМ-ом

а как синхронизировать? я ведь не знаю когда скомутирована фаза. фазу ведь коммутирует A3930 а контролер об этом ничего не знает.

Синхронизировать не по коммутации фазы надо, а по коммутации модулирующих импульсов с частотой которых открываются и закрываются силовый транзисторы.
Это десятки килогерц.
Вы их сами должны генерировать микроконтроллером.

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

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

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

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

С аллегровскими МС никогда проблем не было, кроме их цены