Страница 1 из 1

MexBIOS

Добавлено: 01 дек 2015, 15:16
lyapunov@tpu.ru
Здравствуйте, уважаемые коллеги!
Меня зовут Ляпунов Данил, работаю доцентом Томского политехнического университета.
Интересно узнать, используете ли Вы среду MexBIOS, предназначенную для создания систем управления электроприводов и другого оборудования, в своих разработках?
Эта тема интересна, нам, доцентам, и, в то же время, тревожна, так как среда MexBIOS приобретает популярность среди студентов, которые в ней уже хорошо разбираются, и в большинстве случаев, без помощи преподавателей. В ходе творческих проектов, они осуществляют разработку систем управления двигателями малой мощности и для наглядности, демонстрируют результаты.
Если Вы используете эту среду, как Вы оцениваете ее перспективу? Стоит ли изучать подобные среды и разрабатывать курс лабораторных работ?

Re: MexBIOS

Добавлено: 01 дек 2015, 16:38
AleckseyAnuchin
Нет, среду MexBIOS мы не используем, и не советуем использовать разработчикам электроприводов.
Это не наши методы. Почему? Спросите доцента Вашей кафедры Александра Сергеевича Каракулова, он является разработчиком данной системы и всё Вам подробно расскажет.
Юрию Николаевичу передайте привет.

Re: MexBIOS

Добавлено: 02 дек 2015, 07:22
lyapunov@tpu.ru
Большое спасибо за ответ! С Александром Сергеевичем мы разговаривали неоднократно, так как мы соседи через стенку. Встал вопрос о том, убирать ли из учебного процесса старые "музейные" стенды, которые безотказно работают и нам очень нравятся, заменив их на новенькие с MexBIOS.

Re: MexBIOS

Добавлено: 02 дек 2015, 16:10
AleckseyAnuchin
Это зависит от того, что за "музейные" стенды и по каким учебным планам и программам Вы учите студентов.

Re: MexBIOS

Добавлено: 03 дек 2015, 00:12
motorcontrol
Добрый день. Я бы ответил так. Для задач обучения все современные визуальные среды создания систем управления хороши - будь то Vissim, Matlab или MexBIOS. Они позволяют студентам быстро из готовых блоков нарисовать структуру управления, ровно в том виде, как это нарисовано в книге по приводу и тут же запустить её на реальном оборудовании или виртуальной модели. Наверное, во всех технических ВУЗах применяются подобные курсы обучения - в основном, конечно, на Matlab и без реального "железа". Однако все эти среды позволяют и сгенерировать рабочий код для микроконтроллеров. Если ВУЗ располагает средствами для приобретения нужного количества стендов на базе современного цифрового электропривода, доступного для открытого программирования, то, конечно же, переход от виртуального моделирования к работающему "железу" безусловный плюс. На основе какой среды разработки создать такой курс - это уже зависит от предпочтений преподавателей и владения ими той или иной средой. Важно понимать, что курс должен быть ориентирован в первую очередь на изучение электропривода, а не самой среды - т.е. на синтез той или иной структуры управления и проверки её "в действии". Соответственно, чем прозрачнее и проще будет процесс переноса нарисованной в учебнике структуры управления в работающий преобразователь, тем среда для обучающего процесса удобнее.
Однако применительно к настоящим задачам электропривода всё по-другому. Давайте вспомним, например, структуру векторного управления (датчикового или бездатчикового - не важно), например возьмем такую с википедии: Изображение
Работает ли такая структура, если нарисовать её ровно в таком виде в визуальной среде? Безусловно. Однако для реальной задачи управления электродвигателем в ней кое-чего не хватает. Например, если мы хотим сделать в модуле ШИМ коррекцию искажений мёртвого времени, нам в него нужно завести токи фаз (мысленно рисуем стрелочку от датчиков токов фаз в модуль ШИМ). Потом нам нужно сделать ограничение регуляторов тока в зависимости от текущего напряжения на Udc, чтобы каждый из них не выдал больше положенного. Рисуем стрелочку в них от датчика Udc. Потом вспоминаем, что если мы хотим произвести включение системы управления при вращающемся двигателе, то нам нужно предварительно проинициализировать интегральные части регуляторов тока напряжением, которое сейчас на фазах двигателя. Его можно взять с соответствующих датчиков напряжения или вычислить из положения и частоты вращения вала (если двигатель синхронный) - рисуем еще четыре стрелочки. Затем мы хотим сделать оптимальное управление потоком машины в зависимости от нехватки напряжения на выходе инвертора и скорости двигателя - рисуем еще две стрелочки в блок расчета ослабления поля - из модуля ШИМ и из модуля определения скорости двигателя. Затем вспоминаем, что параметры двигателя при ослаблении поля меняются, а значит надо перестроить регулятор скорости в зависимости от степени ослабления поля. Еще стрелочка. Потом мы хотим сделать изменяющуюся частоту ШИМ в зависимости от нагрузки на привод - стрелочку от задания тока в ШИМ. Но коэффициенты регуляторов тока же надо соответственно перестраивать. Рисуем еще две стрелочки из модуля ШИМ в регуляторы. Потом мы понимаем, что если модуль ослабления поля не справляется со своей задачей в динамике, то нужно более умное ограничение выходов регуляторов тока - при нехватке напряжения в двигательном режиме выход регулятора оси q должен быть приоритетнее и давить выход регулятора оси d. Т.е. выходы регуляторов взаимно влияют друг на друга - еще две стрелочки. Потом мы понимаем, что привод может попадать в генераторный режим, а значит нужно ограничивать задание тока оси q (выход регулятора скорости) в зависимости от напряжения Udc (при превышении запрещать рекуперацию) - еще одна стрелочка. И так можно продолжать еще долго - добавятся фильтры токов, компенсация задержек этих фильтров, влияние модуля ШИМ на АЦП, фильтр датчика положения и наблюдатели бездатчиковой системы, в которые вообще нужно будет завести всё что есть. И это не излишества - это все должно быть и есть в любой настоящей системе управления. Но во что превращается исходная, первоначально понятная, визуальная структура системы управления? В кашу. В полную кашу. Где каждый блок буквально связан с каждым. А то и по нескольку раз - то связь с фильтром, то без фильтра, то с какой-нибудь коррекцией. Структура перестает быть наглядной совершенно - но это правда жизни, именно такие структуры и работают в реальном оборудовании. При этом реализация на языке Си такой структуры, по сравнению с визуальным структурным представлением, уже сильно выигрывает - код такой структуры выглядит, как ни странно, понятнее! Формулы языка Си с именами переменных, говорящими своим названием, откуда они и что содержат, становятся более красноречивыми, чем рисунок. Реализация на Си, конечно же, имеется ввиду "в виде цельной программы", а не когда каждый отдельный модуль написан на Си, и соединен визуально стрелочками с другими (в этом примере и так пришлось бы переписать каждый модуль на Си самим - очевидно, в стандартной реализации блоков "из коробки" нет и не может быть всех описанных наворотов ни в одной среде).
Это мы рассмотрели лишь сторону визуализации. Но есть еще и техническая сторона вопроса. Если вы создаете аналогичную сложную структуру управления электродвигателем, то неизбежно сталкиваетесь с нехваткой производительности микроконтроллера. Даже оптимально написанные программные модули на Си начинают просто не укладываться в желаемый цикл расчета. Приходится жертвовать или качеством работы ПО микроконтроллера, замедляя цикл расчета, что приводит к более худшему быстродействию привода, или удалять из привода какие-то функции совсем (например - не хватает ресурсов фильтровать помехи датчика положения - "ставьте мне" качественный датчик!) или... оптимизировать структуру ПО. Как оптимизировать? Конечно же, все простые пути уже испробованы - оптимизация компилятора максимальная, явно избыточных вычислений с виду нет. Что делать дальше?
Если вы пишете программу на Си, вы можете:
*Выкинуть все долгие операции деления (все программисты контролеров знают - деление дороже золота), подготовив заранее обратные величины и заменить все деления умножениями
*Закешировать все вычисления синуса и косинуса для текущего положения ротора и использовать их в координатных преобразованиях, наблюдателях, коррекциях и т.п.
*Разнести разные блоки одной структуры управления по разным циклам расчета (установить разную частоту тактирования). Например, в самом быстром цикле расчета оставить только регуляторы токов и координатные и фазные преобразования, а всю логику и медленные регуляторы - скорости, потока, положения и т.п. - вынести в более медленный цикл расчета. При этом остро встает вопрос синхронизации данных между такими потоками - нельзя "забрать" задание на регулятор тока Iq из более медленного цикла расчета, если оно там еще не успело посчитаться - необходимо использовать "теневые" или "буферные" переменные.
*Переписать особо критические места кода на ассемблере
*Поиграть с разрядностью вычислений и форматом переменных - заменить float на int32, а int32 на int16 где это возможно.
*Многое другое, что совсем уже уходит в дебри низкоуровневого программирования.

Нужно ли все это в действительности? Или производительности современных МК давно "за глаза" и можно ничего не оптимизировать? Ответ - абсолютно точно нужно для любой серьезной задачи. Производительности контроллера не хватает всегда. Хоть это 150, хоть 300МГц. Всегда хочется оцифровывать данные быстрее, фильтровать качественнее, рассчитывать задание чаще и иметь отклик меньше.
Что может сделать пользователь визуальной среды, если он не знает Си? Нажать кнопку "сделать хорошо" и надеяться, что нарисованная структура влезет в желаемый цикл расчета. Больше ничего. Что он может сделать, если он знает Си? Оптимизировать каждый блок по отдельности, но никак не все вместе - операции деления уже не закешировать, синусы тоже. Можно ли разнести по разным циклам расчета? Не уверен, что любая визуальная среда это сделает корректно. Работа с одними данными в разных потоках - та еще задача. Поэтому самое надежное, что может сделать программист на Си, когда он работает с визуальной средой разработки - это нарисовать один большой блок и реализовать внутри него всю свою структуру на Си, имея полный контроль над всем происходящим. Но стойте... Зачем ему тогда визуальная среда разработки?

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

С уважением, Лашкевич Максим, программист ООО "НПФ Вектор".

Re: MexBIOS

Добавлено: 03 дек 2015, 08:33
mexbiosdeveloper
Уважаемые коллеги!

Если тема названа так, то почему среди дискутантов нет ни единого человека который скачал эту систему и поставил на свой компьютер? (я посмотрел это по базе данных клиентов и лиц скачавших систему Мексбиос).

Так как эта система стоит на моем компьютере, я позволю дать себе несколько комментариев.

Цитата предыдущего сообщения: ….Соответственно, чем прозрачнее и проще будет процесс переноса нарисованной в учебнике структуры управления в работающий преобразователь, тем среда для обучающего процесса удобнее…

В Мексбиосе переход от режима редактирования/моделирования «квадратиков» к наблюдению за тем как это работает на реальном железе осуществляется за 4 (четыре!) секунды (все откомпилированные процедуры уже лежат в микроконтроллере, требуется загрузка только динамических связей). + Любая переменная объявленная в проекте Мексбиос автоматически попадает в стек протокола, поэтому о том как организовать коммуникации по Ethernet или RS485 можно особо не задумываться. + Прикладываются готовые примеры. Соответственно, для учебного процесса подходит идеально.

Про тонкости реализации векторной системы управления и производительность вычислений – согласен со всем написанным.
Но Мексбиос нацелен на решение другой задачи. Он снижает «порог» входа в тему проектирования систем управления, и позволяет закрыть 90% потребностей (исходя из прошедших через наши руки Технических заданий) не предъявляя особых требований к квалификации проектировщика и существованию предыдущих решений (все таки, не каждый день 6 кВ преобразователь приходится проектировать). А вот когда пользователь осознает все тонкости «на собственной шкуре» и у него есть на то время (а главное – требует ли это заказчик?), то тогда может и переходить на язык Си (для чего можно воспользоваться в Мексбиосе генератором кода Си и дальше его уже на свое усмотрение корректировать).

В Мексбиосе собраны готовые проекты, работающие на уровне импортных аналогов ведущих производителей (тренд «Импортозамещение» помог) – приезжайте в Томск – покажем на испытательных стендах: вот японская техника как управляет, а вот тоже самое наше с открытым ПО в Мексбиосе. Пользователю остается лишь привязать проект к своей схемотехнике и логике технологического процесса (та самая функция ПЛК).

Еще цитата «…все блоки связаны со всеми…». Программирование блоками - это всего лишь один из 6 языков которые можно одновременно использовать в Мексбиосе. Можно отрисовать и алгоритм, или прописать его в тексте и т.д.. Вобщем, сложно рассказывать как выглядит портрет Мона Лизы…

Мексбиос – это средство адаптации стандартных решений под собственные нужды, с прогнозируемым завершением проекта в срок и отсутствием специальных требований к квалификации программиста и наличию собственной базы готовых решений.

PS
Что меня лично радует в Мексбиосе – у тех наших заказчиков, где мы внедрили систему, объемы последующих заказов к нам выросли (как отечественных, так и импортных). Не могу рационально это объяснить (тем более в условиях кризиса), но статистика/бухгалтерская отчетность – вещь упрямая.

alexandr.karakulov@mechatronica-pro.com

Re: MexBIOS

Добавлено: 03 дек 2015, 10:33
motorcontrol
Про тонкости реализации векторной системы управления и производительность вычислений – согласен со всем написанным.
Но Мексбиос нацелен на решение другой задачи.
Мне кажется, у нас с Вами нет разногласий. Для простых задач автоматизации - подходит визуальная среда. Для сложных систем управления электродвигателями - голое низкоуровневое программирование. Все зависит от технических заданий и решаемых задач. Мы обязательно попробуем именно Вашу среду разработки, когда будет немного свободного времени, и сравним с известными нам аналогами.

С уважением, Лашкевич Максим, программист ООО "НПФ Вектор".

Re: MexBIOS

Добавлено: 04 дек 2015, 06:50
lyapunov@tpu.ru
Уважаемые коллеги!
Спасибо, просвятили.
В связи с переоборудованием нашей лаборатории часть наших старых стендов придется убрать.
Отладочные комплекты с программной платформой MexBIOS будут установлены для обучения студентов и коллег.
Со средой MexBIOS будем знакомиться в ближайшее время.
Хотя моделирование в matlab очень комфортно для учебы, хочется, чтобы обучающиеся в ходе занятий видели работу реального железа.
Работать с готовеньким железом и ПО - это была наша мечта, когда обучались в магистратуре и делали все в matlab. Мы испытывали дискомфорт, когда приходилось писать отчеты о несуществующих в железе электроприводах, скачивая всю информацию из интернета.
Особенно интересно было узнать такие ньюансы, как "формат переменных", "разрядность вычислений", "генератор кода Си".
Еще раз спасибо и удачи в нашем нелегком деле - делать так чтобы электроприводы работали правильно!

Re: MexBIOS

Добавлено: 15 апр 2016, 22:50
detoxxxic
Поставили "для посмотреть", да помыслы разработчиков интересны, но соглашусь с Лашкевич Максим, как надо что хитрое покрутить, так пляши вокруг этих кубиков.
Мое первое впечатление что очень сыро, сама среда подглючивает интерфейсом, где то что то не обновляется, что-то не показывается, даже банальный блок add с первого и со второго раза не заработал, пока не перезапустили несколько раз.