+3 8(066) 185-39-18
fу тому числі і всередині вікна синхронного обміну даними. Дані повідомлення мають високий пріоритет (вище, ніж повідомлень, складових пакети даних), а колізії вирішуються на рівні фізичного рівня протоколу 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. Моделювання системи у середовищі tracemode6
Рисунок 1 – Схематичний вигляд САУ, спроектований у інтегрованому середовищі tracemod6
3. Моделювання системи у середовищі twidosuite
Рисунок 2 – Схематичний вигляд мікропроцесора
Код програми:
Рисунок 3 – Вигляд програми у середовищі TwidoSuite, виконаний графічною мовою програмування Ladder Diagram (LD)
Рисунок 4 – Вигляд програми у середовищі TwidoSuite, виконаний мовою програмування Instructional List (IL)
Рисунок 5 – Список використаних параметрів у програмі
Висновок
Під час виконання курсового проекту було створено програмне забезпечення (ПЗ) управління текстильним виробництвом. Задачею системи автоматичного управління (САУ) є вчасне ввімкнення різних приладів виробництва: вентилятори, нагрівачі, транспортери, та їх вимкнення по закінченню роботи.
Схематичний вигляд виробництва був спроектований у інтегрованому середовищі розробки TraceMode6 за допомогою стандартних блоків програми.
Саме ж ПЗ було організовано у середовищі TwidoSuite з використанням програмованого логічного контролера (ПЛК), серійний номер якого TWDLMDA40DTK. САУ була розроблена на графічній мові, стандарту IEC 61 131-3, Ladder Diagram, з використанням стандартних інструкцій, типу Set/Reset, та таймерів затримки.
Список використаних джерел
Промислова мережа 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_ca...