Русский   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.