Промислова мережа CANopen

Створення програмного забезпечення управління сучасним текстильним виробництвом. Застосування промислової мережи CANopen. Моделювання системи у середовищі Tracemode6 та Twidosuite. Застосування на підприємстві мікроконтролерів. Асинхронний обмін даними.

Рубрика Программирование, компьютеры и кибернетика
Вид контрольная работа
Язык украинский
Дата добавления 23.01.2016
Размер файла 268,3 K

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

Размещено на http://www.allbest.ru/

Зміст

Вступ

1. Промислова мережа CANopen

2. Моделювання системи у середовищі Tracemode6

Висновок

Список використаних джерел

Вступ

Для просочення текстильних виробів рулони текстилю розкочуються, простягаються через просочувальну ванну, висушуються та нагріваються на стрічкових транспортерах. При цьому необхідно управляти стрічковими транспортерами для просочення і сушіння.

Процес просочення запускається автоматично через вбудоване реле часу. Кожен робочий день о третій годині ранку, в першу чергу, запускаються вентилятори на Q1 для провітрювання. Через 15 хвилин запускається перший стрічковий нагрівач на Q2. Через кожні 5 хвилин - решта на Q3, Q4 і Q5. Так як стрічкові нагрівачі вимагають дуже багато часу для розігріву, то спочатку запускають їх, і тільки через 3,5 години вмикається перший транспортер для просочувальної ванни на Q6. Другий і третій на Q7 і Q8 - через кожні 5 хвилин. Коли всі транспортери працюють, текстильні матеріали за допомогою стрічкових транспортерів пропускаються через просочувальну ванну, а потім висушуються на стрічкових нагрівачах. Якщо цей процес закінчений, то транспортери для нагріву і просочення можуть бути негайно зупинені за допомогою кнопки на I1. Вентилятори ще працюють додатково протягом 1 години.

Використовувані компоненти

I1 - Кнопка виключення (замикає контакт).

Q1 - Вентилятор.

Q2 - Стрічковий нагрівач 1.

Q3 - Стрічковий нагрівач 2.

Q4 - Стрічковий нагрівач 3.

Q5 - Стрічковий нагрівач 4.

Q6 - Стрічковий транспортер 1 для просочення.

Q7 - Стрічковий транспортер 2 для просочення.

Q8 - Стрічковий транспортер 3 для просочення.

1. Промислова мережа CANopen

CANopen - відкритий мережевий протокол верхнього рівня для підключення вбудованих пристроїв в бортових транспортних і промислових мережах. В якості мережевого і транспортного рівня використовує протокол реального часу CAN. Використовується для зв'язку датчиків, виконавчих механізмів і програмованих логічних контролерів між собою. Відкритий стандарт.

Типові області застосування

В основному, застосовується в системах управління переміщенням, в складальних, зварювальних та транспортувальних агрегатах. Використовується, також, для однокабельного з'єднання багатовхідних блоків датчиків, інтелектуальних датчиків, пневматичних вентилів, зчитувачів штрих-кодів, приводів і операторських пультів.

Достоїнство: у порівнянні з іншими мережами на базі шини CAN, мережа CANopen більшою мірою придатна для швидкодіючих систем управління переміщенням і контурів регулювання із зворотним зв'язком. Висока надійність, раціональне використання пропускної здатності, подача напруги живлення з мережевого кабелю.

Недолік: мала поширеність за межами Європи.

Структура стандартів

В основі протоколу прикладного рівня лежить документ DS.301, який у свою чергу є практичним розвитком ідей декларованих в документах CiA DS-201-207. Він визначає протоколи конфігурування та функціонування мережі.

CANopen мережа орієнтована на застосування мікроконтролерів, в тому числі і найдешевших, тому розбивається на ряд необов'язкових підсистем, що дозволяє використовувати тільки лише необхідні функції.

Функціонування мережі - це обмін даними. Для розуміння функціонування мережі CANopen розділимо всі дані на функціональні та технологічні.

Функціональні дані - ті дані, які описують цільове функціонування системи (температура, величини керуючих впливів виконавчих механізмів), ті дані, які передавалися б між блоками, навіть якби як сполучної ланки використовувалася лінія зв'язку відмінна від CAN, наприклад, LIN або USB, або Ethernet, або I2C.

Технологічні дані - ті, які забезпечують функціонування мережі в цілому, контроль коректної роботи всіх вузлів, конфігурування частин системи - ті дані, поява яких пов'язана з використанням мережі CANopen і не залежить безпосередньо від завдань, що вирішуються системою.

CMS - передача повідомлень. Сюди відносяться: обмін функціональними даними, обмін терміновими повідомленнями, обмін даними за запитом, управління об'єктним словником;

NMT - управління мережею, контроль роботи пристроїв мережі;

DBT - динамічний розподіл ідентифікаторів;

LMT - управління конфігуруванням пристроїв;

1. Обмін функціональними даними в реальному часі ключове слово PDO, CMS (основна підсистема, в принципі необов'язкова, але якщо не буде жодної з інших підсистем то дане порожня множина може називатися CANopen лише потенційно).

2. Синхронізація обміну даними ключове слово SYNC (необов'язкова, але така ж доцільна підсистема, як і підсистема 1). При використанні даної підсистеми в мережі існує генератор сінхроповідомлень, який періодично передаває високопріоритетні повідомлення SYNC. Після появи в мережі такого повідомлення всі синхронізовані пристрої проводять обмін даними протягом заданого тимчасового інтервалу (вікно синхронного обміну даними). Колізії (одночасна передача даних двома і більше пристроями) дозволяються на рівні фізичного рівня протоколу CAN. Словник об'єктів містить перехресні посилання звідки які дані взяти, і які куди покласти. Таким чином додатки не займаються самостійно збором даних, просто в певних змінних (з точки зору програми) періодично виявляються свіжі дані. Аналогічно з керуючими впливами. При цьому режимі обмін може відбуватися не тільки між датчиками і основним блоком, а й між датчиками минаючи основний блок.

Асинхронний обмін даними. Включає обмін повідомленнями мережевого управління (керування вузлами мережі) Network Management, NMT Services, повідомленнями підсистеми контролю роботи мережі (варіант Виявлення помилок роботи мережі) Error Control, строковими повідомленнями - авральними об'єктами (виявлення помилок роботи вузлів) Emergency Object, EMCY. Повідомлення цього класу можуть з'явитися в будь-який момент часу, у тому числі і всередині вікна синхронного обміну даними. Дані повідомлення мають високий пріоритет (вище, ніж повідомлень, складових пакети даних), а колізії вирішуються на рівні фізичного рівня протоколу CAN. Для реалізації даних підсистем в мережі призначається (на етапі проектування мережі) пристрій відповідальна за роботу конкретної підсистеми. Крім цього є механізми динамічного призначення подібних пристроїв. Тепер докладно.

3. Управління вузлами мережі Network Management, NMT Services (необов'язкова підсистема). Мережа може бути спроектована таким чином що після включення кожен прилад, завершивши ініціалізацію, перейде в стан готовності, але при цьому не буде брати участь в обміні функціональними даними до тих пір, поки майстер управління роботою мережі (NMT master) не дозволить його роботу. У стані готовності пристрій не приймає участь в обміні функціональними даними але може обмінюватися технологічними даними. У стані готовності пристрій може бути налаштоване (див далі Підсистема управління словником об'єктів). За допомогою даної підсистеми майстер мережі може виконати скидання і перезапуск будь-якого з вузлів, для якого буде потрібно така процедура. Майстер отримує від приладу повідомлення, в яких вказано реальний стан приладу, якщо реальний стан не відповідає очікуваному, то це розцінюється як помилка. Реакції на помилки розглянуті нижче по тексту.

4. Контроль роботи мережі (виявлення помилок роботи мережі) NMT Error Control Protocols, Node Guarding, Heartbeat Protocol (необов'язкова підсистема). Деякі системи (особливо пов'язані з безпекою) повинні контролювати наявність і справність всіх штатних датчиків.

Виявлення помилок роботи мережі проводиться двома подібними способами:

I. Караул вузлів Node Guarding. Майстер періодично опитує вузли, які відповідають. Як тільки вузол перестає відповідати, відзначається помилка для цього датчика, і майстер відповідно до логіки роботи може зупинити потенційно небезпечні процеси. Вузол, який не буде опитаний протягом певного часу (обірвалася лінія), також відзначає для себе помилку.

II. Контрольне тактирование. Heartbeat Protocol. У мережі є пристрій зване генератор контрольних повідомлень, всі інші прилади - учасники мережі знають про його наявність і періоді тактирования і очікують приходу контрольних повідомлень протягом заданого часу. Якщо протягом цього часу повідомлення не прийшло, кожен з приладів, до якого повідомлення не дійшло, відзначає для себе помилку.

Для кожної конкретної мережі допускається використання тільки одного способу контролю або Node Guarding або Heartbeat Protocol.

5. Зміна об'єктного словника. ключові слова PDO, SDO, PDO-mapping Об'єктний словник містить дані якими проводиться обмін за принципом PDO, описує склад і структуру цих даних. Використовуючи обмін даними за запитом (SDO) можна змінити набір даних якими буде проводитися обмін за принципом PDO. Обмін SDO даними можливий як в стані готовності, так і в стані роботи. Таким чином є можливість після включення живлення, але до запуску функціонування мережі, налаштувати всі прилади мережі на обмін потрібними даними, а потім запустити мережу. Під час зміни структури словника під час роботи слід враховувати наступні моменти:

SDO обмін має більш низький пріоритет ніж обмін PDO, тому може виникнути момент часу, коли частина словника вже буде змінена у відповідності з новими вимогами, частина ще не зміниться і в цей момент відбудеться обмін PDO.

Оскільки пристрої передають і приймають PDO повинні розуміти один одного, то може виникнути ситуація коли один пристрій буде працювати з новою структурою, а інше зі старою.

Ці два приклади показують доцільність зміни структури словника тільки коли мережа зупинена, на жаль це буває не завжди можливо.

6. Зміна даних за запитом. Крім зміни словника додаток одного пристрою може завантажити дані в інший пристрій. Відмінність PDO і SDO обміну даними з точки зору програми. При обміні PDO все відбувається автоматично за певними правилами і додаток не звертаючи до мережевим примітивам отримує дані з змінних, як нібито дані виходять всередині е того самого приладу. Для отримання даних за принципом SDO додаток повинен за допомогою мережевих сервісів запросити дані в іншого пристрою, і тільки потім отримавши відповідь використовувати дані для роботи. Тому основу-хребет обміну даними слід будувати на PDO-обміні. На жаль є обмеження на розмір даних (8 байт для PDO, але можна використовувати кілька таких штук). І тільки при особливої необхідності використовувати SDO. При SDO обміні даними, пристрій до якого звернулися із запитом на отримання або запис (dowload / upload) даних називається SDO сервером, а пристрій яке ініціювало обмін називається клієнтом. Залежно від обсягу переданих даних, обмін здійснюється за різними алгоритмами, і може бути не менш ефективний ніж PDO обмін. SDO обмін допускає виробляти контроль безпомилковості даних, що дозволяє навіть завантаження шматків виконуваного коду.

7. Авральні об'єкти, термінові сообщенія. Emergency Object, EMCY. У процесі роботи прилад може виявити помилки в роботі своєї програми, або в роботі електроніки. У такому випадку чим скоріше про це будуть оповіщені всі інші частини системи, тим буде краще і робота такої системи буде безпечніше. Для цієї мети використовуються високо пріоритетні термінові повідомлення. Такі повідомлення надсилаються в момент виявлення несправності, і в момент зникнення цієї несправності. Стандарт описує класи помилок, такими параметрами можуть бути Струм, напруга, температура. Якщо в мережі задіяний механізм термінових повідомлень, то пристрої зобов'язані розуміти по край мірі два повідомлення - Загальна помилка (без уточнення категорій), скидання помилки. Кожен тип помилки може бути уточнений ще цілим байтом, який може кодувати наприклад номер контрольованої ланцюжка.

Обробка помилок. Базовий стандарт описує тільки способи оповіщення про помилки і задає категорії помилок. Подальші уточнення, і реакція на помилку визначається розробником системи.

Наведені вище пункти описуються в документах CiA DS-201-207 і CiA DS-301 Розробник системи «з нуля» може самостійно визначити функціональні вимоги до сітки, контрольовані параметри і сценарії поведінки при появі несправностей. Але оскільки CANopen мережі використовує велику кількість виробників, які вже розробили системи, що охоплюють безліч сфер промисловості, то з'явилися рекомендації того, якими параметрами, як мінімум, повинна оперувати та чи інша система, і які типи реакцій на ті чи інші конкретні помилки, які властиві конкретного класу пристроїв. Дані рекомендації оформлені у вигляді стандартів серій CiA DS-4. Це дозволяє проводити не системи в цілому, а частини систем, і ці нові прилади будуть прекрасно інтегруватися з системами розробленими іменитими виробниками. Частина цих стандартів вже відкриті (усталені), частина залишаються надбанням невеликих груп виробників (нові, схильні змінам). Основна причина того що існує так багато закритих документів та, що це не просто рекомендації, але стандарти при недотриманні яких порушується працездатність системи. При внесенні змін до документів, нові версії розсилаються всім учасникам даної групи «за інтересами». Групи за інтересами не є замкнутою кастою, всі бажаючі можуть вступити в ту чи іншу групу. Обов'язковою умовою є грошовий внесок. Стягуються суми залежать від розміру фірми, і є демократичними за відношенню до малого бізнесу.

2. Моделювання системи у середовищі Twidosuite

Рисунок 1 - Схематичний вигляд мікропроцесора

Код програми:

Рисунок 2

Рисунок 3

Рисунок 4

Рисунок 5

Рисунок 6

Рисунок 7 - Вигляд програми у середовищі TwidoSuite, виконаний графічною мовою програмування Ladder Diagram (LD)

Рисунок 8

програмний управління текстильний мікроконтролер

Рисунок 9

Рисунок 10 - Вигляд програми у середовищі TwidoSuite, виконаний мовою програмування Instructional List (IL)

Рисунок 11 - Список використаних параметрів у програмі

Висновок

Під час виконання проекту було створено програмне забезпечення (ПЗ) управління текстильним виробництвом. Задачею системи автоматичного управління (САУ) є вчасне ввімкнення різних приладів виробництва: вентилятори, нагрівачі, транспортери, та їх вимкнення по закінченню роботи.

Схематичний вигляд виробництва був спроектований у інтегрованому середовищі розробки TraceMode6 за допомогою стандартних блоків програми.

Саме ж ПЗ було організовано у середовищі TwidoSuite з використанням програмованого логічного контролера (ПЛК), серійний номер якого TWDLMDA40DTK. САУ була розроблена на графічній мові, стандарту IEC 61131-3, Ladder Diagram, з використанням стандартних інструкцій, типу Set/Reset, та таймерів затримки.

Список використаних джерел

1. Промислова мережа CANopen [Електронний ресурс] - Режим доступу: https://ru.wikipedia.org/wiki/CANopen

2. Програмування у TraceMode6 [Електронний ресурс] - Режим доступу: http://eknigi.org/programmirovanie/123875-bystryj-start-trace-mode-6.html

3. Посібник з програмування у TwidoSuite [Електронний ресурс] - Режим доступу: http://www.electrocentr.com.ua/files/documentation/SE/plc/twido/Twido_cat_2011_ru.pdf

Размещено на Allbest.ru


Подобные документы

  • Підстава для створення, найменування та область застосування програмного забезпечення. Дослідження теоретичних аспектів процесу проектування систем автоматизації розробки конструкторської документації. Інструкція по інсталяції програмного продукту.

    дипломная работа [2,5 M], добавлен 26.10.2012

  • Опис основних етапів розробки архітектури програмної системи: структурування системи, моделювання управління, декомпозиція підсистем. Ознайомлення із кроками створення інтерфейсу користувачів як однієї із фаз проектування програмного забезпечення.

    реферат [20,7 K], добавлен 24.11.2010

  • Впровадження інформаційно-комунікаційних технологій в освітню практику. Комп'ютерне використання моделювання при вивченні хімії за програмою "Органічна хімія. Транспортні системи". Застосування моделі NetLogo для вивчення теми "Реакції йонного обміну".

    курсовая работа [11,0 M], добавлен 15.03.2014

  • Огляд засобів створення програмного забезпечення сучасних мікроконтролерів. Аналіз методів та налаштувань контролерів. Засоби генерації коду налаштувань. Детальний опис розробки програми генератора налаштувань ядра Cortex M4 та методики її тестування.

    курсовая работа [1,3 M], добавлен 20.05.2015

  • Створення програмного забезпечення для управління продажем та орендою нерухомості. Аналіз роботи підприємства з продажу нерухомості; проектування системи взаємодії клієнта з продавцем; визначення вимог до програмного комплексу, який необхідно розробити.

    курсовая работа [3,1 M], добавлен 08.07.2012

  • Аналіз систем відеоспостереження, їх характеристики та область застосування. Структура керування системою. Аналогові та цифрові системи відеоспостереження. Послідовність дій по реалізації, розробка програмної системи. Тестування програмного забезпечення.

    курсовая работа [1,9 M], добавлен 24.11.2012

  • Аналіз технічного забезпечення, вибір інструментального програмного забезпечення та середовища розробки програм. Створення класів для реалізації необхідних функцій для роботи програмного засобу. Розробка інтерфейсу для користувача та лістинг програми.

    курсовая работа [343,9 K], добавлен 24.08.2012

  • Розробка програмного забезпечення для управління транспортними платформами на базі програмованого логічного контролера S7-300 в Simatic STEP-7. Аналіз програмного забезпечення, розрахунок показників його надійності. Опис алгоритму функціонування системи.

    дипломная работа [2,1 M], добавлен 17.05.2012

  • Підстава для створення системи Компас-3D. Характеристика розробленого програмного забезпечення. Призначення і характеристики систем автоматизації конструкторської документації. Дослідження методів створення динамічних бібліотек в середовищі Delphi.

    дипломная работа [3,3 M], добавлен 22.10.2012

  • Аналіз задач, які вирішуються з використанням інформаційної системи. Вибір серверного вирішення, клієнтської частини, мережного вирішення, системного програмного забезпечення. Розробка підсистеми діагностики, керування, забезпечення безпеки даних.

    курсовая работа [1,5 M], добавлен 22.04.2011

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.