Обзор

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

Среда моделирования используется для моделирования и проверки работы системы управления двигателем с замкнутым контуром. Как только поведение системы управления окажется в пределах спецификации, вы создадите код C из модели контроллера. После проверки кода вы оцените его функциональное поведение и время выполнения с помощью тестирования процессора в цикле (PIL).

Для упрощения тестирования PIL необходимо выбрать тестовые сигналы для выполнения модели контроллера и установки опорных выходов. Рассмотрим пример реализации PIL для процессора Texas Instruments™ F28335, который взаимодействует с Simulink ® на хост-компьютере по последовательному соединению. Этот пример можно использовать в качестве отправной точки для создания реализации PIL для собственного процессора. Модель контроллера будет запущена в режиме PIL для измерения времени выполнения и проверки выполнения кода, выполняемого на встроенном процессоре, по ссылочным выводам моделирования.

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

Примечания

Проверка поведения с помощью моделирования системы

В этом разделе выполняется проверка контроллера при моделировании системы с замкнутым контуром.

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

open_system('rtwdemo_pmsmfoc_system')
out_system = sim('rtwdemo_pmsmfoc_system')
rtwdemo_pmsmfoc_plotsignals(out_system.logsout)

out_system = 

  Simulink.SimulationOutput:
                logsout: [1x1 Simulink.SimulationData.Dataset] 

     SimulationMetadata: [1x1 Simulink.SimulationMetadata] 
           ErrorMessage: [0x0 char] 

Графики показывают, что двигатель неподвижен до motor_on сигнал истинен. Затем двигатель вращается в разомкнутом контуре до тех пор, пока не будет обнаружено известное положение, которое указывается индексным импульсом кодера. Затем контроллер переходит к работе по замкнутому контуру, и двигатель достигает скорости установившегося состояния.

Обзор архитектуры модели

В этом разделе рассматривается архитектура модели, включая порядок указания данных, порядок разделения контроллера с тестового стенда и порядок планирования контроллера. Эта архитектура облегчает моделирование системы, генерацию алгоритмического кода и тестирование PIL.

Файл определения данных создает данные MATLAB ®, необходимые для моделирования и генерации кода. Этот файл данных автоматически запускается в пределах PreLoadFcn обратный вызов модели испытательного стенда системы.

edit('rtwdemo_pmsmfoc_data.m')

В модели стенда для тестирования системы встроенный процессор моделируется как комбинация периферийных устройств и программного обеспечения контроллера.

open_system('rtwdemo_pmsmfoc_system/Embedded Processor')

Программное обеспечение контроллера указывается в отдельной модели. В рамках этой модели подсистема Mode_Scheduler использует Stateflow ® для планирования различных режимов работы алгоритма Motor_Control.

open_system('rtwdemo_pmsmfoc')

В подсистеме Motor_Control сигналы датчиков преобразуются в технические блоки и передаются в алгоритм контроллера активной зоны. Алгоритм контроллера вычисляет напряжения. Затем напряжения преобразуются в сигнал возбуждения.

open_system('rtwdemo_pmsmfoc/Motor_Control')

Основным законом управления является полевой контроллер. Контроллер имеет низкоскоростной внешний контур, который управляет скоростью, и более скоростной внутренний контур, который управляет током.

open_system('rtwdemo_pmsmfoc/Motor_Control/Field_Oriented_Controller')

Внешний контур контроллера скорости выполняется как кратный времени цикла управления током. Можно просмотреть переменные MATLAB ®, которые определяют следующие примеры времени:

fprintf('High rate sample time = %f seconds\n', ctrlConst.TsHi)
fprintf('Low rate sample time  = %f seconds\n', ctrlConst.TsLo)

High rate sample time = 0.000040 seconds
Low rate sample time  = 0.005000 seconds

Обратите внимание, что наибольшая частота в алгоритме контроллера составляет 25 кГц.

fprintf('High rate frequency = %5.0f Hz\n', 1/ctrlConst.TsHi)

High rate frequency = 25000 Hz

Создание кода контроллера C для интеграции во встраиваемые приложения

В этом разделе рассматривается создание и визуальный контроль функции кода C для контроллера.

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

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

mdlFcn = RTW.getFunctionSpecification('rtwdemo_pmsmfoc');
disp(mdlFcn.getPreview('init'))
disp(mdlFcn.getPreview('step'))

Controller_Init ( )
error = Controller ( motor_on, command_type, current_request, * sensors, * pwm_compare )

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

disp(ctrlParams.Value)
disp(ctrlParams.CoderInfo)

                            Current_P: 10
                            Current_I: 10000
                           Velocity_P: 0.0050
                           Velocity_I: 0.0150
                           Position_P: 0.1000
                           Position_I: 0.6000
                  StartupAcceleration: 1
                       StartupCurrent: 0.2000
                   RampToStopVelocity: 20
             AdcZeroOffsetDriverUnits: 2.2523e+03
                 AdcDriverUnitsToAmps: 0.0049
    EncoderToMechanicalZeroOffsetRads: 0
                        PmsmPolePairs: 4

Simulink.CoderInfo
    StorageClass: 'ExportedGlobal'
      Identifier: ''
       Alignment: -1

Код C генерируется из модели следующим образом.

slbuild('rtwdemo_pmsmfoc')

### Starting build procedure for: rtwdemo_pmsmfoc
### Successful completion of build procedure for: rtwdemo_pmsmfoc

Build Summary

Top model targets built:

Model            Action                       Rebuild Reason                                    
================================================================================================
rtwdemo_pmsmfoc  Code generated and compiled  Code generation information file does not exist.  

1 of 1 models built (0 models already up to date)
Build duration: 0h 0m 59.217s

Используйте созданный отчет для проверки созданного файла кода C и проверки того, что были созданы правильные функции шага и инициализации. Также убедитесь, что структура параметров создана как глобальная переменная.

Установка эталонного поведения для модели контроллера

В этом разделе устанавливаются контрольные входные и ссылочные выходные данные для проверки поведения и времени выполнения профиля во время тестирования PIL. Вы создадите локальную копию модели контроллера, а затем загрузите набор тестовых входных сигналов, которые используют различные режимы в контроллере. Затем необходимо сконфигурировать модель контроллера для подключения этих зарегистрированных сигналов к входным портам, выполнить модель контроллера и зарегистрировать выходной сигнал порта в рабочей области.

Параметры конфигурации модели контроллера, используемой для установления эталонного поведения и тестовой среды, будут изменены, как описано ниже. Блоки и параметры, используемые для задания конструкции модели контроллера и генерации производственного кода, не изменятся. Однако во избежание изменения любой части установленной модели контроллера сохраните модель и измените ее имя на rtwdemo_pmsmfoc_local.slx.

save_system('rtwdemo_pmsmfoc','rtwdemo_pmsmfoc_local.slx')
close_system('rtwdemo_pmsmfoc_system',0);
close_system('rtwdemo_pmsmfoc',0);

omCallMethod failed on slmsgviewer.renameTab

Для профилирования времени выполнения выберите набор тестовых входов, которые будут выполнять интересующие пути в контроллере. Один из способов получения этих тестовых входных и ссылочных выходных данных состоит в регистрации их из модели моделирования системы.

in.motor_on      = out_system.logsout.getElement('motor_on').Values;
in.command_type  = out_system.logsout.getElement('command_type').Values;
in.command_value = out_system.logsout.getElement('command_value').Values;
in.sensors       = out_system.logsout.getElement('sensors').Values;
display(in)

in = 

  struct with fields:

         motor_on: [1×1 timeseries]
     command_type: [1×1 timeseries]
    command_value: [1×1 timeseries]
          sensors: [1×1 struct]

Эти сигналы теперь могут быть подключены к входным портам и импортированы в модель контроллера, так что они могут выполняться непосредственно и независимо от модели системы. Преимущество этого подхода заключается в том, что модель контроллера может быть протестирована и проверена как автономный компонент, что облегчает повторное использование и интеграцию с другими системными моделями или испытательными стендами с замкнутым контуром. Для разработки или подготовки модели контроллера к тестированию измените его параметры конфигурации для подключения входных сигналов и сигналов регистрации в рабочей области MATLAB ®. Эти изменения можно внести графически в диалоговом окне «Параметры конфигурации» модели или программно, как показано ниже.

set_param('rtwdemo_pmsmfoc_local',...
    'LoadExternalInput', 'on',...
    'ExternalInput', 'in.motor_on, in.command_type, in.command_value, in.sensors',...
    'StopTime','0.06',...
    'ZeroInternalMemoryAtStartup','on',...
    'SimulationMode', 'normal')
save_system('rtwdemo_pmsmfoc_local.slx')

Теперь можно выполнить модель контроллера и построить график сигнала, связанного с выходным портом сравнения PWM.

out = sim('rtwdemo_pmsmfoc_local')
controller_mode = out.logsout.getElement('controller_mode').Values;
pwm_compare_ref = out.logsout.getElement('pwm_compare').Values;
rtwdemo_pmsmfoc_plotpwmcompare(controller_mode, pwm_compare_ref)

out = 

  Simulink.SimulationOutput:
                logsout: [1x1 Simulink.SimulationData.Dataset] 

     SimulationMetadata: [1x1 Simulink.SimulationMetadata] 
           ErrorMessage: [0x0 char] 

Зарегистрированные выходные данные будут использоваться в качестве эталонного поведения для тестирования PIL.

Обратите внимание, что график аннотируется информацией о режиме контроллера на каждом шаге времени. Эта информация о режиме будет полезна при интерпретации информации о профилировании выполнения.

Создание внедрения PIL

В этом разделе рассматривается и используется пример реализации PIL. Для начала ознакомьтесь с необходимой справочной документацией Embedded Coder ®. Затем вы скопируете пример реализации PIL в свой локальный каталог и зарегистрируете его с помощью Simulink ®. Вы рассмотрим подход, используемый для разработки внедрения PIL, и можете изучить связанные файлы, чтобы получить дополнительную информацию. При использовании платы Spectrum Digital Inc. eZdsp F28335 с Code Composer v4 и последовательным соединением можно настроить эту реализацию PIL для непосредственной работы с моделью контроллера. При использовании другого процессора эту реализацию PIL можно использовать в качестве отправной точки для создания собственной реализации.

Основы создания пользовательской реализации PIL описаны в разделе Создание конфигурации целевого подключения PIL для Simulink. Необходимо ознакомиться с основной концепцией использования API rtiostream для упрощения обмена данными между Simulink ® (сторона хоста) и встроенным процессором (сторона назначения) во время тестирования PIL. Обратите внимание, что Embedded Coder ® предоставляет драйверы на стороне хоста для реализации TCP/IP по умолчанию (для всех платформ, поддерживаемых Simulink ®), а также только для Windows ®. Создание созданного кода выполняется с помощью make-файла, как описано в разделе Настройка Makefiles шаблонов. Для создания реализации PIL необходимо выполнить несколько задач во встроенной среде, включая запись драйвера связи на целевой стороне, запись make-файла для создания сгенерированного кода и автоматизацию загрузки и выполнения встроенного исполняемого файла.

С использованием вышеуказанного подхода была создана реализация PIL для F28335 платы Spectrum Digital Inc. eZdsp. Ниже приведена сводка целевых компонентов API подключения, используемых в этой реализации.

Реализация PIL была итеративно разработана в три этапа. Ниже приведено описание этих этапов и задач, выполняемых на этих этапах. При разработке собственной реализации PIL может оказаться полезным применять аналогичный подход.

Этап 1: Создание приложения для последовательной связи с CCSv4

Этап 2: Внедрение и тестирование встроенного последовательного rtiostream и автоматизация запуска с MATLAB ®

Этап 3: Реализация и тестирование конфигурации подключения с помощью Simulink ®

Файлы, связанные с этой реализацией PIL, включены в Embedded Coder ®, но не находятся в пути MATLAB ®. Чтобы просмотреть эти файлы, их можно скопировать в локальный каталог. Эту реализацию PIL можно зарегистрировать, добавив этот каталог к пути MATLAB ® и обновив настройки Simulink ®.

%copyfile(fullfile(matlabroot,'toolbox','rtw','rtwdemos','examplePilF28335'),'examplePilF28335','f')
addpath(genpath(fullfile(matlabroot,'toolbox','rtw','rtwdemos','examplePilF28335')))
sl_refresh_customizations

Параметры MATLAB ® используются для указания информации о тракте и номера последовательного COM-порта хоста. При непосредственном использовании этой реализации PIL необходимо указать эти настройки в соответствии с конфигурацией.

Обратите внимание, что TI_F28xxx_SysSWDir предпочтение указывает на справочник, предоставленный Техасом Instruments™ в их Прикладном программном обеспечении Экспериментатора C2000™ Кита (sprc675.zip). Эти файлы не включены в Embedded Coder ®.

setpref('examplePilF28335','examplePilF28335Dir', fullfile(matlabroot,'toolbox','rtw','rtwdemos','examplePilF28335'));
setpref('examplePilF28335','CCSRootDir',          'C:\Program Files\Texas Instruments\ccsv4');
setpref('examplePilF28335','TI_F28xxx_SysSWDir',  'C:\Program Files\Texas Instruments\TI_F28xxx_SysSW');
setpref('examplePilF28335','targetConfigFile',    fullfile(matlabroot,'toolbox','rtw','rtwdemos','examplePilF28335','f28335_ezdsp.ccxml'));
setpref('examplePilF28335','baudRate',            115200);
setpref('examplePilF28335','cpuClockRateMHz',     150);
setpref('examplePilF28335','boardConfigPLL',      10);
setpref('examplePilF28335','COMPort',             'COM4');

Реализация PIL теперь готова к использованию.

Подготовка модели контроллера к испытаниям PIL

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

При запуске моделирования в режиме PIL Simulink ® проверяет допустимость любой из зарегистрированных реализаций PIL. Файл настройки определяет, какие параметры конфигурации соответствуют допустимой реализации PIL. Файл адаптации для этой реализации можно просмотреть, выполнив следующую команду.

edit(fullfile(matlabroot,'toolbox','rtw','rtwdemos','examplePilF28335','sl_customization.m'));

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

set_param('rtwdemo_pmsmfoc_local',...
       'ProdHWDeviceType', 'Texas Instruments->C2000',...
       'TemplateMakefile', 'ec_target.tmf',...
       'GenCodeOnly', 'off',...
       'SimulationMode', 'processor-in-the-loop (pil)')

Можно указать сбор информации о профилировании выполнения во время тестирования PIL путем регистрации выходных значений моделирования в качестве переменной. pilOut и регистрируют информацию профилирования выполнения как переменную executionProfile. Эти изменения можно внести графически в диалоговом окне «Параметры конфигурации» модели или программно, как показано ниже.

set_param('rtwdemo_pmsmfoc_local',...
    'CodeExecutionProfiling', 'on',...
    'CodeExecutionProfileVariable','executionProfile',...
    'CodeProfilingSaveOptions','AllData');
save_system('rtwdemo_pmsmfoc_local.slx')

Модель контроллера готова к работе в режиме PIL.

Поведение теста и время выполнения сгенерированного кода

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

Можно запустить модель и распечатать результаты моделирования PIL. При первом запуске модели Embedded Coder ® генерирует код для алгоритма, связывает код алгоритма с кодом последовательного коммуникационного интерфейса, создает встроенное приложение, загружает приложение на плату и начинает моделирование на месте установки. Следует отметить, что во время последующего моделирования PIL код регенерируется только при изменении модели. Из-за служебных данных, связанных с последовательным интерфейсом связи, моделирование PIL может выполняться медленнее, чем модель в обычном режиме.

Команды MATLAB ®, приведенные ниже, намеренно комментируются, поскольку они требуют подключения к аппаратному обеспечению и использования встроенных средств разработки, описанных ранее. Если установлено аппаратное подключение и встроенные средства разработки, раскомментируйте и выполните эти строки для запуска модели, распечатайте результаты и убедитесь, что поведение численно эквивалентно моделированию, выполняемому в обычном режиме. В противном случае продолжите просмотр этого раздела, чтобы узнать о параметрах анализа выполнения PIL.

% UNCOMMENT THE BELOW LINES TO RUN THE SIMULATION AND PLOT THE RESULTS
% if exist('slprj','dir'), rmdir('slprj','s'); end
% out = sim('rtwdemo_pmsmfoc_local')
% pwm_compare_pil = out.logsout.getElement('pwm_compare').Values;
% rtwdemo_pmsmfoc_plotpwmcompare_pil(controller_mode, pwm_compare_pil, executionProfile)

Верхний график является выходом контроллера, PWM Compare. Следует отметить, что выходы в режиме PIL выглядят так же, как и выходы моделирования в обычном режиме, показанном в разделе «Установление эталонного поведения для модели контроллера». Выходные данные моделирования в нормальном режиме можно вычесть из выходных данных моделирования в режиме PIL, чтобы убедиться, что они численно эквивалентны:

% UNCOMMENT THE BELOW LINE TO VERIFY NUMERICAL EQUIVALENCE OF THE OUTPUTS
% pilErrorWithRespectToReference = sum(abs(pwm_compare_pil.Data - pwm_compare_pil.Data))

pilErrorWithRespectToReference =

   0     0     0

Нижний график представляет собой время, затраченное на выполнение модели контроллера на каждом этапе моделирования. Состояние «Stand By» требует наименьшего времени. Небольшие периодические всплески времени выполнения возникают, поскольку контроллер является многоскоростным и однозадачным. Периодические пики соответствуют времени, необходимому для выполнения кода базовой скорости и кода скорости 5 миллисекунд в одной задаче.

Поскольку контроллер должен выполняться на встроенном процессоре с частотой 25 кГц, алгоритм должен завершить его выполнение в течение 40 микросекунд (за вычетом дополнительных требований к запасу со стороны другого кода, который также может выполняться на конечном приложении). Результаты профилирования показывают, что алгоритм будет выполняться в течение времени, выделенного для этой конфигурации встроенной среды.

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

close_system('rtwdemo_pmsmfoc_local',0);
close_system('power_utile',0);

Настройки MATLAB ®, используемые в этой реализации PIL, являются постоянными между сеансами MATLAB ®. Чтобы удалить эти настройки, выполните следующие команды.

rmpref('examplePilF28335');
rmexamplePilF28335hooks();

Заключение

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