Українська   English
ДонНТУ   Портал магистров

Реферат по теме выпускной работы

Содержание

Введение

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

1. Цели и задачи исследования

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

2. Основные вопросы, которые должны быть разрешены в данной работе:

3. Структура стенда для исследования

Исследуемый комплектный электропривод предназначен для векторного управления синхронным двигателем с постоянными магнитами (СДПМ). Схематическое изображение лабораторного комплекса представлено на рис. 1.

Рис. 1 – Лабораторный комплекс для исследования системы векторного управления СДПМ

В его состав входят две электрические машины: СДПМ Dutymax DS типа R95DCS300AAA и двигатель постоянного тока (ДПТ) независимого возбуждения 112L-4MGV, установленные на одном валу и жестко соединенные между собой. ДПТ используется в качестве нагрузочной машины для синхронного электродвигателя. Для управления СДПМ используется частотный преобразователь Unidrive SP1404, а для управления ДПТ – тиристорный преобразователь MENTOR II. Неотъемлемой частью преобразователей являются встроенные контроллеры, которые предназначены для реализации базовых алгоритмов управления, предусмотренных разработчиками. Преобразователь частоты укомплектован также сопроцессорным модулем SM-Application, а тиристорный преобразователь – модулем MD29. Оба этих дополнительных модуля предназначены для реализации приложений пользователя. Модуль SM-Application построен на основе высокопроизводительного специализированного процессора, оснащен Flash-памятью емкостью 384кБ, оперативной памятью емкостью 80кБ. Модуль MD29, реализованный на 32-х битовом RISC-процессоре INTEL 960; имеет 96 кбайт флэш-памяти и 8 кбайт оперативной памяти. В корпусе синхронной машины установлен датчик положения типа резольвер. Связь датчика положения с преобразователем частоты осуществляется через дополнительный модуль SM-Resolver. С помощью высокоскоростной шины CT-Net обеспечивается обмен данными между преобразователями и компьютером, также входящим в состав стенда и предназначенным для программирования дополнительных модулей в среде SyPT-Pro и обеспечения работы виртуального осциллографа ST-Scope в режиме реального времени [1].

4. Операционные системы управления реального времени

Управление электромеханическими системами значительно отличается от обычной обработки данных на компьютере. Здесь обработка данных следует за событиями в объекте управления. Цифровая система управления должна достаточно быстро реагировать на внешние события и постоянно обрабатывать поток входных данных, чаще всего не имея возможности изменить скорость их поступления. Одновременно система должна обеспечивать и выполнение других, вспомогательных функций – обмен информацией, обработка, сохранение и архивирование данных, их вывод на экран, адекватная реакция на определенные сигналы и т.д. Для такого режима работы вычислительных устройств, называемым режимом реального времени, применяют специальные методы программирования из-за особенностей, присущих этому режиму. К таким особенностям можно отнести и то, что система реального времени содержит не одну, а несколько программ, каждая из которых отвечает за решение определенной задачи, причем связь между этими программами может быть весьма сложной. Кроме того, порядок выполнения команд программы реального времени не может быть определен заранее, поскольку он зависит от внешних событий и может быть изменен прерываниями. Поэтому и время, затрачиваемое на вычисления в каждом цикле работы, может существенно меняться [3].

Стандарт POSIX IЕЕЕ 1003.1 даёт следующее определение: реальное время в операционных системах – это способность операционной системы обеспечить требуемый уровень сервиса в определённый промежуток времени. Следовательно, операционная система реального времени отличаются своим поведением, а не внутренним принципом построения. Поэтому если вероятность появления недопустимо больших задержек достаточно низка для достижения требуемого уровня сервиса, то такая операционная система в конкретном применении может рассматриваться как операционная система реального времени.

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

Базовыми требованиями для обеспечения режима реального времени являются следующие:

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

Для обеспечения режима реального времени в операционных системах могут быть реализованы следующие требования [4, 5]:

Наиболее распространенными в программируемых логических контроллерах и компьютерах для решения задач автоматизации являются операционные систем Windows CE, QNX и ОS-9.

5. Принцип реализации программного управления в реальном времени

Рассмотрим принцип реализации программного управления в реальном времени в сопроцессорном модуле SM-Application, который используется для управления преобразователем частоты (Control Techniques). Пользовательское приложение состоит из отдельных разделов (задач), которые выполняются в строго определенной последовательности. К таким разделам относятся (в порядке приоритета): Initial, Event, Pos, Clock и Background . При подаче питания первыми выполняются инструкции, записанные в разделе Initial, в котором задаются значения констант и начальные значения сигналов системы управления, а также определяется ее конфигурация. После этого начинают выполняться задачи реального времени разделов Pos (их может быть несколько, например Pos0 и Pos1) и Clock. Инструкции, помещенные в данные разделы, циклически повторяются через фиксированные интервалы времени (периоды дискретности). Период дискретности для задачи Clock (T∂1) может принимать целочисленные значения от 1 до 200 мс, а для задач Pos0 и Pos1 (T∂2) – строго фиксированные значения: 250 мкс, 500 мкс, 1 мс, 2 мс, 4 мс и 8 мс.

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

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

На рис. 3 представлена концепция взаимного прерывания задач.

Временная диаграмма выполнения разделов инструкций

Рисунок 3 – Временная диаграмма выполнения разделов инструкций

(анимация: 7 кадров, 7 циклов повторения, 20 килобайт)

Как видно из временной диаграммы, выполнение инструкций раздела Clock прерывается выполнением раздела Pos (он имеет более высокий приоритет, чем Clock, и меньший период дискретности). Поэтому разработчики рекомендуют в разделы Pos помещать инструкции, связанные с корректировкой контуров регулирования скорости и (или) положения, а в раздел Clock – инструкции, не требующие такого быстрого выполнения как задачи раздела Pos, например формирование задатчика положения.

Все инструкции программы должны располагаться только внутри определенной задачи. Инструкции разделов Pos и Clock, должны быть выполнены за время, меньшее, чем их периоды дискретности; иначе задачи с меньшими приоритетами (выполняемые в паузах этих задач) не получат времени для своего выполнения. Это может привести к отключению процессора по перегрузке [6] .

Выводы

При написании данного реферата магистерская работа еще не завершена. Окончательное завершение: декабрь 2015 года. Полный текст работы и материалы по теме могут быть получены у автора или его руководителя после указанной даты.

Список источников

  1. Расширенное руководство пользователя Unidrive SP. Редакция 7. Универсальный привод переменного тока для асинхронных двигателей и сервомоторов. – 2004.–381 с.
  2. Олссон Г., Пиани Д. Цифровые системы автоматизации и управления – СПб.: Невский диалект, 2001. – 557с.
  3. Ишматов З.Ш. Микропроцессорное управление электроприводами и технологическими объектами. Полиномиальные методы: монография / З.Ш. Ишматов. Екатеринбург: УГТУ-УПИ, 2007. – 278с.
  4. Денисенко В.В. Компьютерное управление технологическим процессом, экспериментом, оборудованием. – М.: Горячая линия – Телеком, 2009. – 608с.
  5. Сорокин С. Системы реального времени // Современные технологии автоматизации. №2, 1997, с. 22 – 29.
  6. Руководство пользователя SM-Applications. Дополнительный модуль для Unidrive SP. Редакция 4. – 2004. – 113 с.
  7. Толочко О.И. К вопросу об изменении типовых структур цифровых систем управления комплектными электроприводами / О.И. Толочко, П.И. Розкаряка, Н.М. Горобец // // Наукові праці ДонНТУ. Серія: Електротехніка і енергетика. – Вип. 10 (180). – Донецьк: ДонНТУ, 2011. – C.188-193.
  8. Толочко О.И., Коцегуб П.Х., Розкаряка П.И. Синтез задатчика положения с ограничением рывка при учете статического момента // Вісник Кременчуцького державного політехнічного університету: Наукові праці КДПУ. – Кременчук: КДПУ. – 2008. – №3 (50). – Ч.1. – С. 58-63.