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