Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток DIY доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 29
оформление не очень. по терминологии то canbas (а этов обще то непраильноре название) то can bus то can-шина
Возможно вы правы, что лучше использовать одну и ту же аббревиатуру в статье. Я даже изменил CAN bus в названии статьи. Однако, если спросить у Google, то получим такой ответ: "Оба варианта — CAN bus (раздельно) и canbus (слитно) — являются правильными и общепринятыми в технической среде, означая «шина контроллеров» (Controller Area Network). Чаще используется раздельное написание или через дефис (CAN-bus), указывающее на автомобильный интерфейс передачи данных." Поэтому далее по тексту оставлю как есть
Стиль статьи - курсовик. Ну очень схоже
Арбитраж в CAN-bus — это механизм, который позволяет нескольким узлам одновременно претендовать на доступ к шине без потери данных и без необходимости в диспетчере. Этот процесс основан на принципе CSMA/CD + AMP (Carrier Sense Multiple Access with Collision Detection and Arbitration on Message Priority). В основе арбитража лежат два физических правила:
CSMA/CD - это вообще относится к Ethernet.
https://ru.wikipedia.org/wiki/CSMA/CD
механизм основан на случайной паузе при повторной отправке.
Арбитраж CAN - полная противоположность алгоритму CSMA/CD, где арбитраж происходит без пауз, на лету.
Могу согласиться вами только в том, что CSMA/CD используется в Ethernet. Но если внимательно почитать в той же википедии, лучше в английском варианте, то говориться, что CSMA/CD в основном используется в Ethernet, но это не значит, что только в этой технологии. Далее можете почитать документ от Texas instruments Introduction to the Controller Area Network. Там в третьем разделе: Standard CAN or Extended CAN The CAN communication protocol is a carrier-sense, multiple-access protocol with collision detection and arbitration on message priority (CSMA/CD+AMP). CSMA means that each node on a bus must wait for a prescribed period of inactivity before attempting to send a message. Т.е. CAN - это протокол множественного доступа с контролем несущей, обнаружением коллизий и арбитражем приоритета сообщения (CSMA/CD+AMP).
Формат DBC (Data Base CAN) — это текстовый стандарт описания обмена данными в CAN-сети, который служит переводчиком между бинарными кадрами шины и понятными параметрами (ток, скорость, температура)
Про работу с .dbc фалами и про то как из них генерировать си код парсеров CAN пакетов следует написать отдельный текст.
Это очень хорошая практика разработки.
Добрый день. Не понимаю чего многие взбеленились на статью. То им вместе пиши canbus , то раздельно. Завидуют наверное :-) Мне статья очень понравилась. На мои статьи по BLE так же в первую очередь набегали местные хомячки, с претензиями не по сути, а по стилю оформления. Я в данный момент так же изучаю 6-ю версию SDK. В 5-й у меня почему то не получается собрать проект. С большим удовольствием изучу раздел Формат DBC. Это прошло мимо меня :-) Я то же приобрел комплект платы с моторчиком и stm32G431. А так же сделал макетную плату на основе данного контроллера и платы DRV8302, купленной на Озоне. И это заработало. Чудо, не иначе :-) Так же использую переходник canable 2.0. Однако я при изучении работы CAN опирался на протокол Lawicel. Он простой и понятный. Думаю нам есть чему поучиться друг у друга. Раньше BLE занимался, но со сменой работы стал специалистом в DronCan-e. А моторами занялся потому что делаю сейчас свой собственный регулятор на основе экосистемы ST. Было бы интересно обменяться опытом. Если интересно - пиши в личку.
Глянул на ваши статьи по BLE. Пока не изучал, но, думаю, почитаю. У вас реально всё статьи про BLE. ) Год назад пытался немного в эту тему вникать, тоже была комплексная демка с ML на ESP32 с передачей данных по BLE.
BLE тема очень насыщенная. На заре становления, что бы не было проблем с разными форматами, учредители ввели рад жестких правил. Но, по-моему, перегнули палку. Тонкостей так много, что всё охватить просто невозможно. Поэтому разбираться в этой теме крайне затруднительно. Поэтому я и стал записывать информацию, сначала для себя, ну а потом и в общий доступ.
Раньше BLE занимался
Я тоже.
Разбор примера BLE Audio от Nordic Semiconductor (или переходник I2S->BLE-Audio)
https://habr.com/ru/articles/705506/
BLE стек - самая Vendor lock технология во всем embedded. Мегатонны кода от вендоров, который непонятно как отлаживать.
Формат DBC. Это прошло мимо меня :-)
Вы не один. Это прошло мимо свей России. При этом весь мир уже этим пользуется.
Да уж, поэтому стоит подучиться, раз весь мир этим пользуется :-) Просто в DronCane свои фишки, там DBC нет. Есть общий протокол, но каждый производитель лепит над ним свою надстройку. Что бы разобраться, требуется немало времени. Ну и как обычно информации в интернете с гулькин нос. Может уже стоит запускать цикл статей по DronCan :-)
Есть вопрос по теме MotorControl Workbench_6.4.1. Я создал проект, прогнал его через CubeMX и CubeIDE, залил в процессор. При нажатии кнопки start/stop у меня сначала происходит калибровка двигателя, порядка минуты-полторы, а только затем запускается двигатель. Дальше всё происходит быстро. Нажал - запустился, нажал ещё раз - остановился. И так до отключения питания. Отсюда вывод - проект не помнит параметры мотора из планировщика. Почему такое может быть. Плата у меня самопальная на модуле stm32G431 и плате мощности на основе DRV830x
Если верить документации, то калибровка - это процедура Self-Commissioning.
Все результаты настройки хранятся в ОЗУ. Микроконтроллер не имеет никакой автоматической записи во Flash. При отключении питания ОЗУ обнуляется, и параметры теряются.
После того как настройка завершилась и двигатель запустился: 1. В Motor Control Workbench перейти на вкладку Motor Profile -> нажать кнопку "Update Motor Profile" 2. Скопировать измеренные Rs, Ls, Ke в настройки мотора в проекте MCW 3. Перегенерировать код (обновятся pmsm_motor_parameters.h, drive_parameters.h, PID-коэффициенты) 4. Пересобрать проект в CubeIDE -> перепрошить. После этого параметры будут скомпилированы во Flash и не будут зависеть от ОЗУ.
Я тоже столкнулся с тем, что параметры не сохранялись после изменения, например в Control Pilot. Т.е. в любом случае надо перешивать, но или попытаться изменить исходники, чтобы сразу хранить параметры в энергонезависимой памяти
Спасибо, сейчас попробую. Странно то, что по умолчанию не используются настройки мотора из проекта, которые вшиты в него при создании проекта.
Попробовал различные варианты. Судя по тому что вы используете Motor Control Workbench, то скорее всего вы пользуетесь 5-й версией MCSDK (я использую версию MotorControl Workbench_6.4.1). Ну и пытаетесь подменить данные мотора "по-умолчанию", новыми. Я это понимаю. Но у меня вопрос не в том, почему новые данные не сохраняются во FLASH. У меня проблема в другом. Почему после включения питания регулятор в обязательном порядке проводит калибровку, а не использует данные мотора "по-умолчанию" из FLASH. У вас этого не происходит?
Тоже использую MotorControl Workbench_6.4.1
Я экспортировал документацию в RAG и сделал запрос по калибровке. Выложу здесь ответ.
По умолчанию при подаче питания состояние системы измерения смещений всегда устанавливается в NOT_DONE. Однако SDK предусматривает механизм использования заранее сохраненных значений.
Вот как это можно реализовать:
Сохранение данных в энергонезависимую память (FLASH): Вам нужно один раз провести успешную калибровку, получить измеренные значения с помощью функции MC_GetPolarizationOffsetsMotor1() и сохранить структуру
PolarizationOffsets_tв FLASH-память контроллера.Загрузка данных при включении: После перезагрузки или включения питания, до того как будет вызвана команда старта мотора, ваше приложение должно:
Считать сохраненные значения из FLASH.
Передать их в SDK с помощью функции MC_SetPolarizationOffsetsMotor1().
Результат:
Как только вы успешно вызываете
MC_SetPolarizationOffsetsMotor1(), состояние процедуры измерения смещений переходит в COMPLETED.При последующем вызове функции запуска двигателя MC_StartMotor1(), SDK проверит наличие известных смещений. Поскольку они уже предоставлены, процедура калибровки будет пропущена, и мотор начнет запускаться немедленно
Еще обнаружил в коде mc_tasks_foc.c есть место:
if (pwmcHandle[M1]->offsetCalibStatus == false)
{
(void)PWMC_CurrentReadingCalibr(pwmcHandle[M1], CRC_START);
Mci[M1].State = OFFSET_CALIB;
}
можно попробовать с этим поработать
Огромное спасибо. Пока ещё не пробовал, но хоть какая то ясность появилась. Я собирался искать место в коде, где проц принимает решение о калибровке. Теперь стало более понятно куда приложить силы. Главное в том, что и спросить то не у кого. В документации я много чего нашел, но не этот момент. Буду сейчас пробовать. О результатах напишу.
Пока не справился. Анализирую код. Моя проблема в том, что при первом старте идет процесс похожий на профилирование двигателя. Регулятор делает несколько попыток стартовать двигателем. Получается не с первой попытки. Затем, после удачного старта, разгоняет мотор до предельных значений, а после переходит на скорость заданную через ST Motor Pilot. Всё это занимает 20-30 секунд. Собственно через эту программу можно далее взаимодействовать с регулятором. При повторном старте он происходит быстро, за 2-3 секунды. Старты можно делать через физическую кнопку или виртуальную в программе. Разницы нет. Смотрел значения поляризации датчиков тока. Они у меня не меняются. Ниже я их приведу. Но проблема, как мне кажется не в них. Измерение смещения на датчиках происходит достаточно быстро ~несколько миллисекунд. И эту процедуру регулятор делает при каждом старте. Сейчас наверное вернусь к заводской плате ST и и посмотрю что происходит на ней. Так же первый старт долгий или нет. Значения поляризации у меня такие: phaseAOffset=0x20008000 phaseBOffset=0x80032c9 phaseCOffse=0x8003319
Первоначальное застревание происходит в этой функции. После того как ObserverConverged становится TRUE, мы проскакиваем дальше.
(void)VSS_SetStartTransition(&VirtualSpeedSensorM1, ObserverConverged);
if (ObserverConverged)
{
qd_t StatorCurrent = MCM_Park(FOCVars[M1].Ialphabeta, SPD_GetElAngle(&STO_PLL_M1._Super));
/* Start switch over ramp. This ramp will transition from the revup to the closed loop FOC */
REMNG_Init(pREMNG[M1]);
(void)REMNG_ExecRamp(pREMNG[M1], FOCVars[M1].Iqdref.q, 0);
(void)REMNG_ExecRamp(pREMNG[M1], StatorCurrent.q, TRANSITION_DURATION);
Mci[M1].State = SWITCH_OVER;
}
Короче всё дело в константах разгона при разомкнутой петле обратной связи. Есть такая структура STO_PLL_M1 – данные о текущем состоянии наблюдателя (оценка угла, скорости и внутренние параметры фильтрации) хранятся в оперативной памяти. Первоначально инициализируется в файле mc_tasks_foc.c в функции FOC_Init() . В двух словах, в ней лежат как первоначальные данные о моторе, посчитанные в программе профилирования двигателя, так и вычисленные настройки наблюдателя. Если эти настройки не оптимальны для двигателя и нагрузки, наблюдатель может долго не сходиться, или система будет предпринимать попытки перезапуска в рамках одного цикла разгона. Именно это у меня и происходит. После подбора оптимальных настроек, мотор начинает крутится, а сама структура хранится в ОЗУ. Я думаю это получается потому, что профилирование двигателя я делаю без нагрузки, поэтому есть большой разброс параметров одного и того же мотора при последовательных попытках.
на официальной плате от ST P-IHM03 такая же история. Первый полноценный старт происходит секунд через 15 после нажатия кнопки, а второй и последующие через3-5 секунд
Серьезно вы раскопали параметры старта. Можно уже писать статью)
Судя по всему так и есть. Если параметры мотора были получены без нагрузки, то они будут оптимальны только для этого случая. В структуре STO_PLL_M1 действительно много параметров: регулятор скорости, параметры разгона, коэффициенты наблюдателя. Вобщем, есть пространство для экспериментов. Я пока опыты с этим комплектом отложил, но на будущее - информация будет полезной.
Можно и написать :-) Правда я сейчас другую статью готовлю по DroneCan. Посмотрел, на Хабре вроде бы ни одной на эту тему. А со стартом я разобрался. Кучу времени убил, все исходники проштудировал, ИИ своими вопросами замучил, но причину нашел. Она оказалась в одном параметре. При создании своего проекта можно в разделе Application Configuration выбрать (поставить галочку) напротив Motor Profiler. Это позволяет пользоваться GUI-ем ST Motor Pilot для отладки проекта. При выставлении галочки, в проект интегрируется доп.софт, аналогично бутлоадеру, через который и проходят все команды. Вот на инициализацию этого софта при первом старте и уходит секунд 15-20. Он похоже самостоятельно делает профилирование двигателя, потому что снаружи всё выглядит именно так. Фото выбора этой функции в проекте, приведу ниже. Думаю что на этом всё. После написания своей статьи, сюда кину ссылку. Всем хорошего дня.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Интеграция CAN bus в STM32 Motor Control проект