Промислова мережа CANopen
Зміст
Вступ
. Промислова мережа CANopen
. Моделювання системи у середовищі Tracemode6
Висновок
Список використаних джерел
Вступ
Для просочення текстильних виробів рулони текстилю розкочуються, простягаються через просочувальну ванну, висушуються та нагріваються на стрічкових транспортерах. При цьому необхідно управляти стрічковими транспортерами для просочення і сушіння.
Процес просочення запускається автоматично через вбудоване реле часу. Кожен робочий день о третій годині ранку, в першу чергу, запускаються вентилятори на Q1 для провітрювання. Через 15 хвилин запускається перший стрічковий нагрівач на Q2. Через кожні 5 хвилин - решта на Q3, Q4 і Q5. Так як стрічкові нагрівачі вимагають дуже багато часу для розігріву, то спочатку запускають їх, і тільки через 3,5 години вмикається перший транспортер для просочувальної ванни на Q6. Другий і третій на Q7 і Q8 - через кожні 5 хвилин. Коли всі транспортери працюють, текстильні матеріали за допомогою стрічкових транспортерів пропускаються через просочувальну ванну, а потім висушуються на стрічкових нагрівачах. Якщо цей процес закінчений, то транспортери для нагріву і просочення можуть бути негайно зупинені за допомогою кнопки на I1. Вентилятори ще працюють додатково протягом 1 години.
Використовувані компоненти - Кнопка виключення (замикає контакт). - Вентилятор. - Стрічковий нагрівач 1. - Стрічковий нагрівач 2. - Стрічковий нагрівач 3.- Стрічковий нагрівач 4. - Стрічковий транспортер 1 для просочення. - Стрічковий транспортер 2 для просочення. - Стрічковий транспортер 3 для просочення.
1. Промислова мережа CANopen
- відкритий мережевий протокол верхнього рівня для підключення вбудованих пристроїв в бортових транспортних і промислових мережах. В якості мережевого і транспортного рівня використовує протокол реального часу CAN. Використовується для зв'язку датчиків, виконавчих механізмів і програмованих логічних контролерів між собою. Відкритий стандарт.
Типові області застосування
В основному, застосовується в системах управління переміщенням, в складальних, зварювальних та транспортувальних агрегатах. Використовується, також, для однокабельного з'єднання багатовхідних блоків датчиків, інтелектуальних датчиків, пневматичних вентилів, зчитувачів штрих-кодів, приводів і операторських пультів.
Достоїнство: у порівнянні з іншими мережами на базі шини CAN, мережа CANopen більшою мірою придатна для швидкодіючих систем управління переміщенням і контурів регулювання із зворотним зв'язком. Висока надійність, раціональне використання пропускної здатності, подача напруги живлення з мережевого кабелю.
Недолік: мала поширеність за межами Європи.
Структура стандартів
В основі протоколу прикладного рівня лежить документ DS.301, який у свою чергу є практичним розвитком ідей декларованих в документах CiA DS-201-207. Він визначає протоколи конфігурування та функціонування мережі.мережа орієнтована на застосування мікроконтролерів, в тому числі і найдешевших, тому розбивається на ряд необов'язкових підсистем, що дозволяє використовувати тільки лише необхідні функції.
Функціонування мережі - це обмін даними. Для розуміння функціонування мережі CANopen розділимо всі дані на функціональні та технологічні.
Функціональні дані - ті дані, які описують цільове функціонування системи (температура, величини керуючих впливів виконавчих механізмів), ті дані, які передавалися б між блоками, навіть якби як сполучної ланки використовувалася лінія зв'язку відмінна від CAN, наприклад, LIN або USB, або Ethernet, або I2C.
. Обмін функціональними даними в реальному часі ключове слово PDO, CMS (основна підсистема, в принципі необов'язкова, але якщо не буде жодної з інших підсистем то дане порожня множина може називатися CANopen лише потенційно).
. Синхронізація обміну даними ключове слово SYNC (необов'язкова, але така ж доцільна підсистема, як і підсистема 1). При використанні даної підсистеми в мережі існує генератор сінхроповідомлень, який періодично передаває високопріоритетні повідомлення SYNC. Після появи в мережі такого повідомлення всі синхронізовані пристрої проводять обмін даними протягом заданого тимчасового інтервалу (вікно синхронного обміну даними). Колізії (одночасна передача даних двома і більше пристроями) дозволяються на рівні фізичного рівня протоколу CAN. Словник об'єктів містить перехресні посилання звідки які дані взяти, і які куди покласти. Таким чином додатки не займаються самостійно збором даних, просто в певних змінних (з точки зору програми) періодично виявляються свіжі дані. Аналогічно з керуючими впливами. При цьому режимі обмін може відбуватися не тільки між датчиками і основним блоком, а й між датчиками минаючи основний блок.
Асинхронний обмін даними. Включає обмін повідомленнями мережевого управління (керування вузлами мережі) Network Management, NMT Services, повідомленнями підсистеми контролю роботи мережі (варіант Виявлення помилок роботи мережі) Error Control, строковими повідомленнями - авральними об'єктами (виявлення помилок роботи вузлів) Emergency Object, EMCY. Повідомлення цього класу можуть з'явитися в будь-який момент часу, у тому числі і всередині вікна синхронного обміну даними. Дані повідомлення мають високий пріоритет (вище, ніж повідомлень, складових пакети даних), а колізії вирішуються на рівні фізичного рівня протоколу CAN. Для реалізації даних підсистем в мережі призначається (на етапі проектування мережі) пристрій відповідальна за роботу конкретної підсистеми. Крім цього є механізми динамічного призначення подібних пристроїв. Тепер докладно.
. Управління вузлами мережі Network Management, NMT Services (необов'язкова підсистема). Мережа може бути спроектована таким чином що після включення кожен прилад, завершивши ініціалізацію, перейде в стан готовності, але при цьому не буде брати участь в обміні функціональними даними до тих пір, поки майстер управління роботою мережі (NMT master) не дозволить його роботу. У стані готовності пристрій не приймає участь в обміні функціональними даними але може обмінюватися технологічними даними. У стані готовності пристрій може бути налаштоване (див далі Підсистема управління словником об'єктів). За допомогою даної підсистеми майстер мережі може виконати скидання і перезапуск будь-якого з вузлів, для якого буде потрібно така процедура. Майстер отримує від приладу повідомлення, в яких вказано реальний стан приладу, якщо реальний стан не відповідає очікуваному, то це розцінюється як помилка. Реакції на помилки розглянуті нижче по тексту.
. Контроль роботи мережі (виявлення помилок роботи мережі) NMT Error Control Protocols, Node Guarding, Heartbeat Protocol (необов'язкова підсистема). Деякі системи (особливо пов'язані з безпекою) повинні контролювати наявність і справність всіх штатних датчиків.
Виявлення помилок роботи мережі проводиться двома подібними способами:. Караул вузлів Node Guarding. Майстер періодично опитує вузли, які відповідають. Як тільки вузол перестає відповідати, відзначається помилка для цього датчика, і майстер відповідно до логіки роботи може зупинити потенційно небезпечні процеси. Вузол, який не буде опитаний протягом певного часу (обірвалася лінія), також відзначає для себе помилку.. Контрольне тактирование. Heartbeat Protocol. У мережі є пристрій зване генератор контрольних повідомлень, всі інші прилади - учасники мережі знають про його наявність і періоді тактирования і очікують приходу контрольних повідомлень протягом заданого часу. Якщо протягом цього часу повідомлення не прийшло, кожен з приладів, до якого повідомлення не дійшло, відзначає для себе помилку.
Для кожної конкретної мережі допускається використання тільки одного способу контролю або Node Guarding або Heartbeat Protocol.
. Зміна об'єктного словника. ключові слова PDO, SDO, PDO-mapping Об'єктний словник містить дані якими проводиться обмін за принципом PDO, описує склад і структуру цих даних. Використовуючи обмін даними за запитом (SDO) можна змінити набір даних якими буде проводитися обмін за принципом PDO. Обмін SDO даними можливий як в стані готовності, так і в стані роботи. Таким чином є можливість після включення живлення, але до запуску функціонування мережі, налаштувати всі прилади мережі на обмін потрібними даними, а потім запустити мережу. Під час зміни структури словника під час роботи слід враховувати наступні моменти:обмін має більш низький пріоритет ніж обмін PDO, тому може виникнути момент часу, коли частина словника вже буде змінена у відповідності з новими вимогами, частина ще не зміниться і в цей момент відбудеться обмін PDO.
Оскільки пристрої передають і приймають PDO повинні розуміти один одного, то може виникнути ситуація коли один пристрій буде працювати з новою структурою, а інше зі старою.
Ці два приклади показують доцільність зміни структури словника тільки коли мережа зупинена, на жаль це буває не завжди можливо.
. Зміна даних за запитом. Крім зміни словника додаток одного пристрою може завантажити дані в інший пристрій. Відмінність PDO і SDO обміну даними з точки зору програми. При обміні PDO все відбувається автоматично за певними правилами і додаток не звертаючи до мережевим примітивам отримує дані з змінних, як нібито дані виходять всередині е того самого приладу. Для отримання даних за принципом SDO додаток повинен за допомогою мережевих сервісів запросити дані в іншого пристрою, і тільки потім отримавши відповідь використовувати дані для роботи. Тому основу-хребет обміну даними слід будувати на PDO-обміні. На жаль є обмеження на розмір даних (8 байт для PDO, але можна використовувати кілька таких штук). І тільки при особливої необхідності використовувати SDO. При SDO обміні даними, пристрій до якого звернулися із запитом на отримання або запис (dowload / upload) даних називається SDO сервером, а пристрій яке ініціювало обмін називається клієнтом. Залежно від обсягу переданих даних, обмін здійснюється за різними алгоритмами, і може бути не менш ефективний ніж PDO обмін. SDO обмін допускає виробляти контроль безпомилковості даних, що дозволяє навіть завантаження шматків виконуваного коду.
. Авральні об'єкти, термінові сообщенія. Emergency Object, EMCY. У процесі роботи прилад може виявити помилки в роботі своєї програми, або в роботі електроніки. У такому випадку чим скоріше про це будуть оповіщені всі інші частини системи, тим буде краще і робота такої системи буде безпечніше. Для цієї мети використовуються високо пріоритетні термінові повідомлення. Такі повідомлення надсилаються в момент виявлення несправності, і в момент зникнення цієї несправності. Стандарт описує класи помилок, такими параметрами можуть бути Струм, напруга, температура. Якщо в мережі задіяний механізм термінових повідомлень, то пристрої зобов'язані розуміти по край мірі два повідомлення - Загальна помилка (без уточнення категорій), скидання помилки. Кожен тип помилки може бути уточнений ще цілим байтом, який може кодувати наприклад номер контрольованої ланцюжка.
Обробка помилок. Базовий стандарт описує тільки способи оповіщення про помилки і задає категорії помилок. Подальші уточнення, і реакція на помилку визначається розробником системи.
Наведені вище пункти описуються в документах CiA DS-201-207 і CiA DS-301 Розробник системи «з нуля» може самостійно визначити функціональні вимоги до сітки, контрольовані параметри і сценарії поведінки при появі несправностей. Але оскільки CANopen мережі використовує велику кількість виробників, які вже розробили системи, що охоплюють безліч сфер промисловості, то з'явилися рекомендації того, якими параметрами, як мінімум, повинна оперувати та чи інша система, і які типи реакцій на ті чи інші конкретні помилки, які властиві конкретного класу пристроїв. Дані рекомендації оформлені у вигляді стандартів серій CiA DS-4. Це дозволяє проводити не системи в цілому, а частини систем, і ці нові прилади будуть прекрасно інтегруватися з системами розробленими іменитими виробниками. Частина цих стандартів вже відкриті (усталені), частина залишаються надбанням невеликих груп виробників (нові, схильні змінам). Основна причина того що існує так багато закритих документів та, що це не просто рекомендації, але стандарти при недотриманні яких порушується працездатність системи. При внесенні змін до документів, нові версії розсилаються всім учасникам даної групи «за інтересами». Групи за інтересами не є замкнутою кастою, всі бажаючі можуть вступити в ту чи іншу групу. Обов'язковою умовою є грошовий внесок. Стягуються суми залежать від розміру фірми, і є демократичними за відношенню до малого бізнесу.
. Моделювання системи у середовищі Twidosuite
Рисунок 1 - Схематичний вигляд мікропроцесора
Код програми:
Рисунок 2
Рисунок 3
Рисунок 4
Рисунок 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
.Програмування у TraceMode6 [Електронний ресурс] - Режим доступу: http://eknigi.org/programmirovanie/123875-bystryj-start-trace-mode-6.html
.Посібник з програмування у TwidoSuite [Електронний ресурс] - Режим доступу: http://www.electrocentr.com.ua/files/documentation/SE/plc/twido/Twido_cat_2011_ru.pdf