Комментарии 60
КДПВ — это гифка. Через какое-то время Шэрон Стоун перекинет ногу...
Что касается моделирования – это вопрос для наших приводщиков не новый. А вот автоматическую кодогенерацию программы контроллера электропривода из его модели, и в мировом масштабе, мало кто пробовал.…
Простите, но для кого тогда придумали Simulink? MATLAB генерит код для микроконтроллеров уже не знаю сколько времени, как. Есть целые компании, занимающиеся реалтаймовыми симуляторами моделей (dSPACE, как пример).
Вопрос лишь в том, что легальное использование стека технологий на базе MATLAB стоит неприлично огромных денег, потому все обходятся велосипедами
Что бы загрузить код сгенерированный из matlab в микроконтроллер и отладить вам нужно столько же програмистов, сколько для того, что бы его написать + специалист по matlab. А если у вас двигатель такой как в статье см. Рис.1, где модель двигателя из Simulinka не подойдет. И нужно будет писать еще и модель двигателя.
Ну и удаленная отладка, когда работа алгоритма, в контроллере отображается на схеме, этого тоже нет в Simulink.
А стоимость ПО это не главное.
Для все ключевых MCU для управления приводами (TI, например) она есть. Более того, ребята хорошо показывают, что и высокочастотное управление на ПЛИС не сложно реализовывать. Вот трехлетний вебинар где и удаленная отладка, и генерация кода для СнК показываются. http://matlab.ru/webinars/razrabotka-sistem-upravleniya-na-baze-zynq-v-matlab-i-simulink.
Нет, зачем. Там же просто подключаются результаты моделирования моторов в максвеле том же, если очень точно процесс нужно помотреть. А так готовые блоки отлично работают. Ещё очень нравится как реализованна завязка на тепло элементов схемы, при моделировании длительных процессов нам очень полезно оказалось.
Исторически SimInTech работает там, где русские продавцы Matlab Simulink не могли решить конкретные производтвенные задачи (не важно это рукожопость продавцов или фатальный недостаток Simulink). :))))))
Если не барть в пример задачи управления АЭС, откуда изначально появлися SimInTech. то последнии кейсы:
1) расчет охлаждение датацентра, с учетом 8 000 юнитов на три сервера в каждом из которых 4 вентелятора со своей логикой управления.
2) расчет солнечной батареи спутника с учетом затенения от воспомогательных устройств.
В обоих случаях первое решение предлагаемое продавцами Matlab Simulink нихрена не работало так как нужно заказчику. С приводом получилось так же. Калачев Юрий Николаевич занимается приводами с 1987 года Автор книги Вектороно регулирование. Заметки практика. (в книге есть его почта для связи) И он всегда использовал Simulink пока как то раз не встретился с разработчиками SimInTech. В итоге он объяснил разработчику электрической модели SimInTech, что ему не хватет для счастья, электрик из SimInTech поставил задачу для доработки в математическом ядре и в итоге получился в продукт который покрывает Simulink в области моделирования электропривода как бык овцу. Сам удивлен. Подробнее в книге "Моделирование в электроприводе" Специалисты после практического использования решения в восторге об этом и текст.
Юрий Николаевич, кстатие еще книги писал и модели в simulink делал.
В общем мне не понятно откуда крытье вашего быка овцами взялось, уверен проблема на user side.
Конечно если вы копнете нашу среду то выкопаете косяк и не один, но в отличие от Simulinк вы не будете посланы нах, поскольку найти разработчика который накосячил в MatLab невозможно. Мы же устраняем косяки практически сразу. Это преимущества тюнингованого барбуса, над среийной ренологан.
Например вот в этом примере (Скрещивая ежа и ужа), у меня модель двигателя изначально была на фортране и я для меня это темный лес и фортран и тем более двигатель авиационный. Но когда фортран привели к структурной схеме (причем не важно Simulink или SimInTech) то сразу стало понятно, где и что нужно поменять для учета новых эффектов. Я подключал гидравлическую систему с расчетом течения топлива и управления электроприводом клапана и наглядно видел как мой двигатель изменения положения. В случае если бы это двигатель был на фортране мне пришлось бы потрать год на изучение теории двигателей и еще месяца 2 на освоение фортрана.
engineerandreev.livejournal.com/3918.html
Цитата:
«Видно, что результат практически не отличается, за тем исключением, что Simscape почему-то начинает неистово дробить шаг в конце переходного процесса. Возможно, это связано со способом расчёта расхода, который в конце становится очень маленьким, а может и нет...»
«Примерно та же самая история. Результаты практически не отличаются, но Simscape почему-то безосновательно начинает дробить шаг. Что у него в голове? Я не знаю..»
Мои утверждения базируются на твредом финасовом оснвании, разработчики SimInTech уже 20 лет зарабатывает деньги на проблемах Simulink и с оптимизьмом смотрят в будущее! :))))
Видео сравнения скорости расчет Simulink и SimInTech
«VEOS is part of the MathWorks Connections Program. dSPACE works closely together with MathWorks to make sure that C code generated with the Simulink® Coder™ can be integrated and simulated with VEOS.»
А если вспомнить что для получение кода таргета и Simulink нужно использовать 3 (ТРИ!!!) продукта:
1)MATLAB Coder
2)Simulink Coder
3)Embedded Coder
При этом вся это красота сразу перестает работать, как только вы берете отечественный Миландр и проектируете свою плату, для которого нет поддержки соответствующего таргета.
В статье же пример реальный, когда весь процесс (Модель объекта — Создание ПО — Загрузка — Отладка на контроллере), выполняется в одной среде отсюда и восторг участников процесса.
выполняется в одной среде отсюда
Хорошо, среда поддерживает МК от TI или Infineon? Мне вот не интересен Миландр. Понятное дело, что продукты поддерживают ограниченный диапазон вендоров.
Монстроузность dSPACE-овских решений в том, что они делают Hardware-In-Loop тесты, то есть объект управления имитируется в FPGA _в_реальномвремени. Понятное дело, если вам не нужно тестировать алгоритм в реальном времени без реального железа, от этого можно отказаться.
Объект управления в реальном времени в FPGA это возможно только для ограниченного набора моделей. Например уложить в логику FPGA модель какой нибудь теплообменника с «честной» теплофизикой вряд ли возможно.
С моей точки зрения, попытки загнать работу модели в «реальное время» на стадии отладки и проектирования ПО, не всегда оправданы. На стадии проектирования, достаточно обеспечить синхронизацию работы управляющей программы по тактам с модельным временем. И добиться того, что при заданных входных воздействиях система управляет объектом, так как требует проект. Даже если моделирование происходит медленнее или быстрее реального времени. После этого достаточно убедится, что цикл вычислений укладывается в временной такт работы в реальном времени на контроллере.
Хотя возможно для систем, где простые алгоритмы и главная проблема обеспечить передачу данных от сенсоров в контроллер и воздействия на исполнительные механизмы тестирование реальном времени действительно необходимы.
Да что угодно поддерживает, если среда открыта и настраиваема, то обеспечить поддержку любого МК не является проблемой.
О поддержке отечественных МК в иностранном Simulink:
Это костыли и палки от продавцов в России
Хм-м… Кажется, всё дело в фатальном недостатке Simulink!
Когда вы настраиваете чужой продукт, без доступа к разработчику — вы бьетесь головой о стену, найти автора не представляется возможным физически и исправить по вашему желанию ничего нельзя. Потому что западному разработчику на 0.001% мирового рынка просто плевать. А когда вы можете зайти к разработчикам и поговорить о ваших проблемах, и для вас внесут изменения в ядро и допишут нужные функции это бесценно.
Или вот это недавник кейс, когда просто солнечную батарейку Simulink не осили в нужно постановке для заказчика. Простую солнечную батарейку.
simintech.ru/articles/2017_solar_panels.pdf
И немцы SimInTech используют для того что бы не платить за лицензию!
The ATHLET GCSM Modeler was developed by GRS on the basis of the software SimInTech by 3V-Services, Russia (free run time licence). It substitutes the former GCSM Input Data Generator based on the expert system shell G2 of Gensym, USA, which required a license.
1)MATLAB Coder
2)Simulink Coder
3)Embedded Coder
К тому же модель электродвигателя в этом проекте из Simulink не подходит. В реальности она работает по другому см. рисунок 1
Потом нельзя отобразить на схеме в процессе отладки кода в контролере его работу. Последний рисунок из модели которая подключена к контроллеру и отображает его работу на схеме.
Ну и сам код ПО из автоматического кодогенератора, тоже не без странностей. Например, для интегратора matlab генерирует такой код:
Отличное решение, -0.01 это временной шаг интегрирования.
Как только запустил с другим шагом система не работает. Опять генерит код, опять заливаем.
А ведь определение оптимального такта работы управляющей программы это практическая и реальная задача, при проектировании любой системы управления.
Так что восторг участников когда у них реально заработала понятен
Придирка к коду тоже странно выглядит, учитывая, что из Simulink без проблем можно генерировать код, исполняемый с произвольным тактом.
А выбрать оптимальный такт работы проще простого благодаря PIL-тестированию, которое работает по нажатию кнопки и позволяет проводить профилирование исполняемого кода на микроконтроллере прямо из Simulink.
Вы если что, всегда можете обратиться к российским представителям, они вас просветят по поводу возможностей. Может быть и модель двигателя более точную покажут.
Модель более точную они покажут? У них на стенде модель с реальной не совпадают в вебинаре выше ссылка. А здесь для двигателя с нестандартной ЭДС, да еще на нашем Миландре который сам по себе работает не так как написано в документации у них все заработает. Да верю, конечно в эти сказки венского леса.
По какому нажатю кнопки изменяется такт? Посмотрите внимательно это пример из матлаба, в коде шаг интегрирования в виде числа 0.1. Запускать это код с другим тактам просто нельзя.
Сгенерированный код нужно запускать ровно с тем тактом, с которым алгоритм работает в модели, потому что код — это артефакт, производная модели, и расходиться с ней не должен.
Если же нужно сделать алгоритм, исполняемый с произвольным тактом, это в Simulink делается легко, например с помощью Triggered Subsystem, из которой также генерируется код. Если у вас есть лицензия на Embedded Coder, попробуйте. Если нет, можете запросить триал у представителей, они вам и с Миландром помогут разобраться. В сказки верить не обязательно, как и рассказывать их.
На самом деле в модельно-ориентированном проектировании слово модель, это про модель объекта управления. Почему пользователи и продавцы Matlab считают, что здесь речь идет о модели программы управления, лично я не понимаю. Даже статью написал по этому поводу. Модельно ориентированное проектирование
Код программы управления и модель программы управления в нормальной среде это одно и тоже. По хорошему они вообще должны быть математически тождественны, с учетом возможностей таргета конечно.
Когда вы говорит о совпадении значения такта в моделирующей среде и на таргете, вы говорите о последних стадиях отладки кода.
Я же рассматриваю процесс проектирования целиком. На стадии проектирования, я ставлю блок интегратор, который должен интегрировать переменную и выдавать накопленное значение. С точки зрения разработчика СУ не важно какой шаг интегрирования важна накопленная сумма. А в процессе проектирования я должен иметь возможность запустить алгоритм с разным тактом, причем здесь Triggered Subsystem? Задача то исследовательская, я не знаю в начале какой шаг меня удовлетворит. В Simulink я должен при измени шага заново генерировать кода загружать его на таргет что бы посмотреть как он работает. В SimInTech я могу менять шаг интегрирования и такт исполнения, не запуская снова генерацию кода, при этом интеграл у меня будет содержать правильное значение вне зависимости от такта исполнения. Для больших проектов возможность анализировать запуск с разным тактом без повторной генерации большой плюс. Код Simulink этого не позволяет.
Например, измеренная ЭДС двигателя имела весьма причудливую форму, представленную на Рис.1.
Возможно, это техника third harmonic injection. В результате ток синусоидальный, а напряжение питания может быть меньше.
Чисто интуитивно вариант со «слабой» искусственной средней точкой мне не очень нравится. Сам бы наверное начал с того, что посадил землю осциллографа на одну из фаз и измерил относительно нее ЭДС на двух других. Третий сигнал получил бы как разность двух полученных. Но может и не прав. Хочу разобраться.
К фазным надо будет переходить по известным формулам.
Если необходимо знать фазные ЭДС, то начинать следует с измерения линейных ЭДС по описанной выше методике в режиме холостого хода. Затем необходимо оценить насколько близко эти графики могут быть апроксимированы синусоидами. Если получилось, то можно воспользоваться виртуальной средней точкой и напрямую измерить фазные ЭДС. Если линейные ЭДС на синусоиду не похожи, то виртуальную среднюю точку использовать нельзя, ее потенциал будет колбасить с тройной частотой и амплитудой до десятков процентов от амплитуды фазной ЭДС в зависимости от степени ее несинусоидальности. В этом плохом для нас случае все еще можно попытаться численно решить задачу. Будет попроще, если экспериментальные графики ЭДС имеют близкую форму, отличающуюся только фазой и возможно амплитудой. Если они заметно отличаются по форме, то задача усложнится еще на порядок.
Вывод:
Лучше разобрать двигатель и найти среднюю точку. Это будет надежно, точно и без мучений. Численное решение или измерения с виртуальной средней точкой при отличии линейных ЭДС от синусоиды могут дать плохую точность и трудно предсказать насколько.
Последнее замечание, наверное самое интересное, но и самое голословное:
Пока это интуитивно, доказательства не проводил. Назовем это гипотезой. Хайли лайкли, нам совершенно не нужно знать как ведет себя средняя точка обмоток относительно земли драйвера и соответственно не нужно пытаться ее просчитать. Более того, у нас есть значительная свобода в способе формирования линейных напряжений, которую и используют при «инжекции третьей гармоники» в виде синуса, треугольника или любой другой формы по желанию разработчика, выигрывая тем самым в понижении минимально необходимого напряжения на DC шине драйвера. Гипотеза состоит в том, что должна существовать методика, которая позволяет вычислять правильный закон управления для драйвера прямо из экспериментальных линейных ЭДС двигателя, минуя промежуточное вычисление фазных ЭДС. Причем, решение не единственное, если не задать дополнительные условия.
Как-то так. Не знаю только нужно ли это кому-нибудь из практиков. Им расковырять двигатель попроще будет. А вот для диплома или курсовой кто-нибудь мог бы и попробовать.
Наша система (СИМИНТЭК) мне удобней.
Очень важно, что она именно наша. Разработчики рядом, все тонкости знают, если что — помогут. Кодогенерацию тоже ориентируем на отечественные процессоры.
Сколько можно, господа, жить чужим умом? (причем обычно ворованным)
Резануло слух — "приводщик". У нас говорили "приво́дчик". Наверное в разных школах свои традиции...
Модельно ориентированное проектирование. Электропривод с бесколлекторным двигателем постоянного тока