Для включения и выключения часто используется этот полезный логический элемент RS-триггер. На нем можно собирать сложные цепочки регуляторов с различной логикой.
Сейчас я стал редко его применять, так как код в основном пишу на ST. Зачастую этот элемент там не нужен. А для языка программирование CFC и FBD самое то.
RS-триггер
У этого элемента сброс является приоритетом. Одним словом, если он срабатывает, то другие сигналы не работают.
Нужно измерять температуру с термодатчика r385_500 на ПЛК PLC-150i в диапазоне от 100 до 200 градусов. При превышении температуры выше чем уставка 1 срабатывает сигнализация/лампа, которая отключается только после того как температура уменьшится до уровня уставки 2. Уставка 1 – 200 градусов, уставка 2 – 100 гр.С.
Создание проекта на ПЛК
Создаем новый проект, в качестве целевой платформы выбираем PLC-150i, затем в организаторе объектов выбираем «Конфигурация ПЛК» и в ней выбираем тип датчика.
Реализация регулятора температуры
Пишем простейшую программу на языке ST.
На окне визуализации расположены следующие элементы: 1 ползунок, 6 квадратов и 1 эллипс. Ползунок связан с переменной «temp» и служит для моделирования изменения температуры, измеряемой датчиком. Два квадрата справа от ползунка связаны с переменными деформации по вертикали: для 1-го кубика это (-PLC_PRG.ustavka1), для второго (-PLC_PRG.ustavka2). Графический элемент эллипс служит для визуализации срабатывания физического дискретного выхода ПЛК «lampa». Три прямоугольника под лампой показывают текущую температуры, уставку 1 и уставку 2. В них нужно настроить переменные на вывод текста: «temp», «PLC_PRG.ustavka1» и «PLC_PRG.ustavka2».
Осуществил в прошлом году автоматизацию термовакуумного станка для производства кассет для рассады.
Как работает станок?
Станок конвейерного типа. в начале закладывается лист пластика. Материал проезжает мимо инфракрасных нагревателей, размягчая пластик. После этого ложится на форму, прижимается и откачивается воздух, создавая вакуум. Конвейер работает по энкодеру, отмеряя нужную длину, которую задаст оператор в панели.
Для нагрева использовали обычный ПИД-регулятор Овен ТРМ-500. А для конвейера и цилиндров ставили ПЛК Optimus Drive и панель оператора VI20.
Фотографий к сожалению не осталось. Есть только сам шкаф и панель оператора.
На экране панели можно примерно представить как выглядит станок, я примерно изображал его так, как есть.
Я люблю ставить панели оператора фирмы Weintek. За 10 лет работы никогда не подводили. Быстрая и красивая графика, продуманная логика рецептуры и т.д.
Главная фишка панелей - это макросы. Можно сделать полноценный ПЛК с экраном, но обязательно нужно учитывать некоторые нюансы.
Макрос - последовательность команд, алгоритм действий панели оператора, который можно использовать для выполнения задач не предусмотренных основным функционалом EasyBuilder.
Примерный список задач, для которых может понадобиться использование макроса:
Таймер обратного отсчета для запуска/остановки технологических и других процессов.
Преобразование данных из одних единиц измерения в другие: напряжение в температуру, ток в давление, Фаренгейты в Цельсии и т.д.
Управление пользовательским интерфейсом: рисовать графики, открывать/закрывать окна, скрывать/отображать объекты, управлять анимацией.
Собственный протокол передачи данных, которого еще нет в библиотеке из более чем 300 драйверов EasyBuilder. Например, можно подключить GSM-модем и управлять приемом/отправкой СМС-сообщений.
Взаимодействие с внутренней базой данных рецептов SQLite: загрузка и сохранение данных в настраиваемом формате, выборка данных по SQL-запросу. Это может быть, например, база данных рецептов приготовления блюд в кухонной печи.
Взаимодействие с внешней базой данных MySQL, или MS SQL Server: загрузка и сохранение данных в настраиваемом формате, выборка/выгрузка данных с помощью SQL. Это может быть, например, база данных предприятия, или склада. Панель может считывать штрих-коды, QR-коды, RFID-метки и загружать их в базу данных, или делать выборку данных по считанным кодам.
Список макросов
Каждый проект EasyBuilder содержит собственный набор макросов. Вызвать список можно из меню на вкладке “Проект”:
Здесь можно создавать, удалять и редактировать макросы проекта. Если есть макросы, которые вы хотите использовать в нескольких проектах, функциями Импорт/Экспорт их можно сохранять/загружать через отдельные файлы.
В списке, кроме имени объекта-макроса, отображается его идентификатор [ID] и атрибуты {I,P,S}. Атрибуты макроса имеют следующее значение:
“I” - будет вызываться каждый раз при загрузке панели.
“P” - задействует таймер для периодического вызова.
“S” - может блокироваться битом адресного пространства.
Чтобы создать новый макрос, или изменить имеющийся, нажмите соответствующую кнопку - “Создать”, или ”Редактировать”, откроется редактор макросов.
В редакторе макросов можно изменить всё что касается конкретного объекта-макроса: его имя, атрибуты запуска и непосредственно код. Здесь же происходит проверка кода на наличие синтаксических ошибок, после внесения изменений следует нажать кнопку “Сохранить и скомпилировать”.
Существует много способов вызова макросов.
Способы вызова макросов
1 - Однократный вызов при старте панели.
Это один из атрибутов объекта-макроса, выбирается в редакторе.
Полезный вариант для макросов инициализации, если нужно что-то загрузить в ПЛК, или выгрузить из энергонезависимой памяти. Еще один пример использования - макрос с вечным циклом. Макрос, который никогда не завершается, достаточно запустить один раз.
2 - Автоматический периодический вызов.
Это один из атрибутов объекта-макроса.
Макрос будет вызываться по таймеру с заданной периодичностью. Важно учитывать, что вызываемая функция должна завершаться до ее повторного вызова, иначе вызов будет блокироваться. Удобный вариант для процессов, требующих непрерывной обработки данных.
Используя блокировку макроса, можно запускать и приостанавливать вызовы в нужный момент. Блокировка — это еще один атрибут объекта-макроса.
3 - Функциональная кнопка.
Одной из функций объекта “Функциональная кнопка” может быть вызов макроса. Вызов будет происходить каждый раз при нажатии кнопки пользователем. В атрибутах выбираем “Выполнить макрос” и имя макроса из выпадающего списка.
4 - Комбинированная кнопка.
Может выполнять последовательность действий, в том числе вызов макросов.
5 - Битовая кнопка.
Эта кнопка используется для изменения состояния бита, но также она может вызвать макрос при срабатывании.
Срабатывать кнопка может не только от нажатия пользователем, она может быть скрытым элементом и срабатывать от других условий.
6 - Битовый переключатель.
Этот объект реагирует только на нажатие. Вызов макроса можно привязать к конкретному изменению состояния бита.
7 - Вызов по триггеру.
Часто бывает необходимо управлять вызовом макроса через адресное пространство панели. Используйте ПЛК-триггеры для вызова макроса битом регистра панели, или ПЛК.
Режим триггера “Всегда активно если ON” будет запускать макрос каждые 500 миллисекунд при высоком уровне бита.
8 - Вызов из активного экрана.
В атрибутах окна на панелях всех серий, за исключением iP-серии, можно выбрать варианты запуска макросов на случай открытия, или закрытия окна, а также для циклического запуска. Период циклического запуска макроса фиксированный - 500 миллисекунд.
На панелях iP-серии этот функционал также может быть реализован, но другим способом. Для циклического вызова можно использовать собственный таймер объекта-макроса, а для вызова при открытии/закрытии окна можно использовать битовую кнопку с соответствующим атрибутом.
9 - Вызов из другого макроса.
Существует два способа вызова макроса из другого макроса: синхронный и асинхронный. Разница в том, что при синхронном вызове вызывающий макрос будет ждать завершения вызываемого макроса, прежде чем продолжить выполнение алгоритма. При асинхронном вызове вызывающий макрос продолжит выполнение алгоритма параллельно с вызываемым. Используйте функции SYNC_TRIG_MACRO и ASYNC_TRIG_MACRO соответственно для синхронного и асинхронного вызова.
Пример: Связь с регулятором ОВЕН ТРМ138
Для заказчика нужно было удаленно отслеживать за 8 канальным регулятором температуры. Хотелось именно панель оператора, без ПК. Вот там как раз делал простую логику для срабатываний аварий и т.п. и т.д.
Сейчас на многих станках, линиях и агрегатах стоят панели оператора, либо сенсорные панельные контроллеры. Вы сами понимаете, что это очень удобно. На экране можно вывести множество функций: графики физических величин, архивация данных, рецепты, настройки оповещений по смс, рецепты вкусных булочек. Да и просто удобная и красивая индикация: лампочки, кнопочки и переключатели. На чём это всё пишется? Среди разнообразия ПО, я остановился на CoDeSyS 3.5. В CoDeSyS 3.5 визуализация обладает рядом преимуществ, которые будут рассматриваться в этой статье.
Привет, друзья! Это одна из основных сред разработки, которую я использую при внедрении и наладке автоматизации оборудования. Сегодня мы с вами поговорим во всех подробностях.
О программном продукте CoDeSyS 3.5
Среда разработки является продуктом 3S-Smart Software. CoDeSyS-это аппаратно-независимая система для программирования ПЛК. Она поддерживает все языки стандарта МЭК. Сочетает в себе объектно-ориентированное программирование(то есть с помощью визуальных функциональных блоков). Возможна работа с несколькими устройствами и приложениями.
В этой среде можно писать программы стандарта МЭК FBD, IL, LD, CFC, ST.
В чём же принципиальное отличие от версии CoDeSyS 2.3? Принципы программирования и построения языков остаются теми же. Давайте рассмотрим преимущества данной системы:
Добавилось очень много полезных функций (в основном, касающиеся визуализации);
Рабочее окно среды разработки стало гораздо удобнее;
Существуют готовые библиотеки модулей ввода-вывода;
Возможность Веб-визуализации;
Ну и конечно самый главный козырь, это сама визуализация;
Мне, честно говоря, нравится работать в двух версиях, и в CoDeSyS 2.3, и в 3.5. Каждая по-своему удобна. Единственный недостаток новой среды заключается в том, что она в постоянной разработке, то есть всё время обновляется. И периодически при компиляции возникает куча ошибок, с которыми иногда невозможно разобраться.
Какое оборудование поддерживает CoDeSyS 3.5? Из отечественных контроллеров я знаю СПК сотой и двухсотой серии, ПЛК 323 и ПЛК304. Из «Буржуйских» мне известно о WAGO и Berghof.
На самом деле, работать в этой среде разработки сложно. Очень много нюансов. Каждый новый проект у меня начинается с самого начала. Для изучения требуется перелопатить кучу инструкций и помучить ребят из тех. поддержки компании ОВЕН. В следующих своих статьях я ознакомлю вас со многими фишками, если будет кому интересно.
Визуализация CoDeSyS 3.5
Отдельно бы хотелось поговорить о визуализации в среде разработки. Это шикарный инструмент для реализации большинства задач в производстве. Весь технологический процесс можно отобразить на экранах, сделать красивые графики, архивацию, анимацию и т.п. Ниже приведу видео для наглядной демонстрации возможностей визуализации.
Особенности визуализации в Codesys 3.5
1. Графический редактор
Одной из ключевых особенностей Codesys 3.5 является графический редактор, который позволяет создавать визуальные элементы интерфейса для взаимодействия с операторами. Этот инструмент предоставляет широкий набор графических объектов, таких как кнопки, индикаторы, графики и т.д., которые могут быть легко настроены и анимированы.
2. Поддержка множества форматов
Codesys 3.5 поддерживает множество форматов визуальных элементов, включая векторные и растровые изображения, SVG, а также веб-компоненты. Это обеспечивает более высокое качество и гибкость визуализации, что особенно важно при работе с современными мультимедийными элементами.
3. Анимация и визуальные эффекты
Визуализация в Codesys 3.5 предоставляет возможности для создания анимаций и визуальных эффектов, которые помогают операторам быстрее и точнее интерпретировать данные. Это включает в себя анимированные графики, изменение цвета и формы объектов в зависимости от состояния системы, а также создание плавных переходов между различными экранами и состояниями.
4. Мультиязычность
Для многих проектов промышленной автоматизации важно иметь мультиязычный интерфейс для операторов. Codesys 3.5 позволяет легко локализовать визуальные элементы и тексты, обеспечивая комфортное использование системы на разных языках.
5. Интеграция с внешними источниками данных
Часто визуализация должна отображать данные, получаемые из внешних источников, таких как базы данных, датчики или веб-сервисы. Codesys 3.5 обладает мощными средствами интеграции, что позволяет легко получать и обновлять данные из различных источников и отображать их на визуальных элементах.
Простейший пример проекта
Мы с вами сейчас создадим простой проект в среде разработки CoDeSyS 3.5. Давайте сделаем так, чтобы от кнопки включалась и выключалась лампочка. Дистрибутив можно скачать с официального сайта компании ОВЕН. Стандартная установка. Всё, как обычно. Запускаем программу и создаём проект.
Так как у меня под рукой нет сенсорной панели, я задам устройство-эмулятор, которое загружается с компьютера. Работать будем на наиболее наглядном языке CFC.
Для начала в правом нижнем углу нам нужно запустить эмулятор контроллера. Затем нажимаем Scan Network, и система должна обнаружить ваш компьютер.
Давайте создадим простейшую программу.
Добавляем визуализацию в наш проект. Правой кнопкой мыши вызываем контекстное меню и жмем Добавить объект.
Рисуем визуализацию под наш алгоритм. Выбираем элементы во вкладке панели инструментов.
Присваиваем переменные элементам во вкладке свойства. Для кнопки:
Для лампочки:
Из настроек на этом у нас всё. Теперь нажимаем на кнопку Логин. И в результате у вас должна получиться вот такая картинка:
Я реализовывал несколько проектов в этой программе. Но наиболее удачный и «красивый» проект у меня получился на автоматизации холодильных камер. Задача заключалась в том, чтобы охлаждать камеры до определённой температуры.
В первой камере охлаждается воздух с помощью заслонки в приточной системе. Во второй и третьей камере охлаждается воздух каскадным включением компрессоров в зависимости от времени наработки. Все эти физические данные архивируются. В случае аварии контроллер отправляет сообщение смс на указанный номер. Писал программу я на сенсорном панельном контроллере СПК207.03.CS.WEB.
Давайте покажу вам несколько иллюстраций моей работы. Главное меню панельного контроллера:
Аварии компрессоров:
Компрессорная
И наконец, WEB-визуализация:
Выкладываю видео, где вся эта система работает:
На этом я заканчиваю, напишите в комментариях, в каких средах вы пишите и что вы программируете?
Если интересна статья, подписывайтесь, ставьте рейтинг, дальше будет интереснее.
Многие процессы в автоматизации (например порошковая покраска, изготовление выпечки, поддержание давления в трубопроводе) требуют точного регулирования физического параметра. С такими задачами хорошо справляется библиотека CoDeSyS ПИД регулятор. Эта тема довольно сложная, многогранная. Целые институты занимаются разработкой таких сложных и многоуровневых алгоритмов.
Приветствую посетителей моего блога! В сегодняшней статье я отвечу на вопрос — как работает ПИД-регулирование, для чего это нужно и как его использовать на практике…
Как работает ПИД-регулятор?
Начнём с теории. Пропорционально-интегрально-дифференциальный (ПИД) регулятор — прибор в управляющем контуре с обратной связью. Устройство, формирующий сигнал с целью достижения высокого качества и точности переходного процесса в системе. Наиболее эффективный вид регулятора для обеспечения высокой точности параметра(температуры, длины, давления).
Существует специальная формула для формирования сигнала…
Ниже приведена таблица составляющих формулы:
Давайте поговорим о параметрах, которые непосредственно участвуют в процессе работы регулятора:
Хр — полоса пропорциональности. В общих чертах, чем шире Хр, тем меньше величина Y при одном и том же E. То есть чем больше Хр, тем короче импульсы.
Ти — интегральная составляющая. Эта величина позволяет выдавать сигнал в зависимости от накопленной ошибки ( или от накопленного отклонения Е). Чем выше параметр, тем он реже и меньше выдаёт сигнал при рассогласовании Е. Это для того, чтобы сигнал не раскачивал систему и не совершал перерегулирование.
Тд — дифференциальная составляющая. Эта величина позволяет выдавать сигнал Y, при дополнительных резких возмущениях в системе. по — русски говоря, этот параметр срабатывает, когда нужно быстро среагировать на возмущающие воздействия. Естественно, чем он больше, тем длиннее импульс.
Я думаю с точки зрения теории все понятно. Тогда переходим непосредственно к практике. Для чего и как используется ПИД-регулятор?
Описание библиотеки для CoDeSyS
Я говорил об этом, скажу ещё раз, библиотеки обязательно скачивайте с официальных источников. С сайта ОВЕН или библиотеки OSCAT. Рекомендую не использовать библиотеки с форумов или с других источников. Пишите лучше сами. Только вы понимаете от начала до конца, как у вас всё работает.
Для задвижек я рекомендую использовать данный функциональный блок, он хорошо зарекомендовал себя, и за всё время работы на реальном объекте у меня не было к нему никаких вопросов. На изображении ниже приведён функциональный блок ПИД-регулятора.
Описание каждого входа и выхода:
Входные значения:
Выходные значения:
Хочу заметить, функциональный блок универсальный. То есть подходит и для дискретных задвижек, и для аналоговых.
Рабочая схема ПИД-регулятора
Возникает сразу же вопрос, а как же на самом деле правильно использовать данную библиотеку, чтобы она правильно функционировала и не глючила?
Предлагаю вам рабочую схему библиотеки ПИД-регулятора:
setAPID_otopl является вспомогательным блоком для ввода коэффициентов ПИД-регулятора. Хочу сказать, что на входах блока обязательно должны стоять какие-то переменные, пускай даже если будут стоять в положении FALSE.
А какие вы используете библиотеки в своих проектах? Пишите в комментариях. На этом я заканчиваю, хорошего вам настроения, всего наилучшего. Пока, пока.
В этой статье приведены настройки связи между ПЛК и Модулем ввода тензометрических датчиков. Такая комбинация автоматики удобна для конфигурации различных дозаторов с медленными процессами.
Эту систему не назовёшь сверхточной, так как обмен данных между контроллером и модулями порядка около 20 мс.
5 лет назад мы реализовывали проект дозатора сыпучих материалов, работает до сих пор. Система довольно надёжная.
Приветствую, на связи автор блога, Гридин Семен и я начинаю писать….
Технология программируемых логических контроллеров совершенно точно достигла зрелости – ей уже 60 лет. В связи с чем возникает вопрос: станут ли нынешние ПЛК «пенсионерами» и сойдут ли их будущие версии в могилу? Такое предположение кажется уместным, учитывая быстрое, а порой экспоненциальное развитие компьютерного оборудования, программного обеспечения, искусственного интеллекта, облачных сервисов и средств связи. Благодаря этим достижениям информационные технологии постепенно проникли в ранее изолированную сферу операционных технологий.
В свете этих событий приводим статью Джеффа Пейна, опубликованную в журнале Control Engineering о будущем контроллеров и приложений промышленной автоматизации на фоне происходящей в последние десятилетия эволюции ПЛК.
Оставаться верным своему делу
Основная задача ПЛК остается той же, что и всегда: обеспечение надежного управления и мониторинга физических полевых устройств даже в сложных условиях эксплуатации. Это было достигнуто благодаря использованию специализированных процессоров, операционных систем и сред программирования, встроенных в защищенные платформы. Тем не менее, эффект масштаба продолжает стимулировать внедрение основных потребительских и коммерческих технологий в ПЛК везде, где это осуществимо. Принцип «меньше, быстрее, лучше» сохранился и будет оставаться верным, но в основном в отношении более быстрых и лучших аспектов, поскольку тенденция к дальнейшей миниатюризации за последнее десятилетие выровнялась.
Многие преимущества развития электронных компонентов, процессоров и твердотельной памяти – снижение стоимости, уменьшение размера, минимизация энергопотребления и увеличение возможностей – уже реализованы в ПЛК и другой промышленной электронике. Однако несмотря на то, что незначительные улучшения в размерах, стоимости и производительности будут происходить и впредь, реальный прогресс будет заключаться в возможностях. На данный момент размер платформы в значительной степени ограничен необходимостью физической проводки для взаимодействия с модулями ввода-вывода ПЛК. Традиционный проводной ввод-вывод по-прежнему необходим, но во многих случаях связь с полевыми устройствами смещается в цифровые сети и распределяется удаленно с использованием таких технологий, как IO-Link и беспроводная связь.
Многоядерные процессоры, встроенные в конструкции ПЛК, теперь позволяют дополнять детерминированное управление обширными дополнительными вычислительными и коммуникационными функциями. На протяжении более 20 лет термин «программируемый контроллер автоматизации» (programmable automation controller – PAC) широко использовался для описания промышленного контроллера с более широкими возможностями, чем классический ПЛК.
Хотя поначалу ПАК (PAC) мог показаться отдельным продуктом по сравнению с ПЛК, время показало, что инженеры по автоматизации меньше озабочены названием и номенклатурой и гораздо больше интересуются производительностью и доступными функциями. В дальнейшем пользователи будут готовы рассматривать практически любой тип аппаратной части или операционной системы в качестве платформы автоматизации, которая может продолжать называться ПЛК, хотя на самом деле это будет нечто большее, если она сможет обеспечить управление в реальном режиме времени, обеспечивая при этом расширенные вычислительные возможности.
Сочетание гибкости и логики
Хотя системы на базе Windows доминируют в мире потребительских и коммерческих компьютеров и занимают видное место в сфере промышленной визуализации, это не относится к управлению в реальном времени. Платформы ПЛК/ПАК обычно работают под управлением специализированной операционной системы, хотя существуют некоторые варианты на базе Linux. В самых общих чертах пользователи должны сбалансировать свое стремление к открытости, которая обеспечивает большую гибкость и низкую стоимость продукта, с требованием надежности промышленного уровня, которое исторически обеспечивалось только проприетарными системами. Эти запатентованные системы также обеспечивают высокую степень кибербезопасности, хотя в первую очередь за счет некоторой неизвестности хакерам.
В течение многих лет наблюдалась тенденция или, по крайней мере, большой интерес к более открытым промышленным системам, как с точки зрения аппаратных платформ, так и с точки зрения языков программирования. Некоторые конечные пользователи применяют стандартное оборудование Raspberry Pi и Arduino для реализации проектов автоматизации и обработки данных. Другие избегали подобных экспериментов с продуктами потребительского уровня из-за опасений по поводу надежности. Но теперь несколько версий этих платформ превратились в устройства промышленного уровня (Рис. 1). Пользователи предъявляют большой спрос на возможность сочетания современной платформы программирования с проверенными промышленными устройствами ввода-вывода.
Рис. 1. Теперь, когда современные процессорные платформы с открытым исходным кодом доступны в форм-факторах промышленного уровня у конечных пользователей появилась возможность интеграции традиционных методов автоматизации с более современными языками, осно
При таком разнообразии аппаратных средств следующим препятствием на пути к открытости стала гомогенизация среды программирования. В классических ПЛК использовалось программное обеспечение, разработанное конкретным поставщиком, которое было трудно перенести на другие бренды. Стандарт IEC 61131-3 представил упорядоченные языки программирования ПЛК и типы данных, но реализации, специфичные для конкретного поставщика, по-прежнему препятствовали переносу кода между брендами. В конечном счете интегрированная среда разработки (integrated development environment – IDE) CODESYS предложила более согласованный способ создания кода с использованием стандартных языков для его кроссплатформенного развертывания на промышленных контроллерах.
Однако ни одна из этих инициатив не учитывала тот факт, что программисты, поступающие на работу, часто предпочитали писать код на более современных языках, основанных на ИТ, таких как C++ или Python.
Несмотря на все эти усилия, направленные на открытость и современные языки программирования, можно с уверенностью сказать, что классическая релейная (лестничная) логика сохранится в обозримом будущем. Релейная логика имеет обширную базу инсталляций и остается простой методологией кодирования, предпочитаемой многими электриками, техническими специалистами АСУ ТП и даже разработчиками. Ее графический стиль позволяет выполнять основные функции поиска и устранения неисправностей, а также выполнять типичные функции промышленной автоматизации, а широкое распространение дает дополнительные преимущества.
Сегодня большинство аппаратных платформ поддерживают релейную логику – как собственную, так и реализованную через другие IDE, например, CODESYS, а многие из них также допускают другие методы кодирования, которые можно комбинировать по мере необходимости. Различные языки программирования имеют свои сильные и слабые стороны для конкретных задач, а большинству пользователей нравится разрабатывать собственный вариант лучшего инструмента для решения проблемы, балансируя при между гибкостью и сложностью. Дополнительным бонусом для пользователей является то, что выход за пределы проприетарных языков позволяет им создавать библиотеку кода, которую можно развернуть на любом типе целевого оборудования, сводя к минимуму доработку.
Главным моментом сегодня и в будущем является то, что пользователям нужны платформы автоматизации, предлагаемые и поддерживаемые проверенными и опытными промышленными поставщиками, с возможностью поддержки любого типа предпочтительного языка программирования.
Коммуникации
Некоторые из достижений промышленной автоматизации в последнее время связаны с улучшением коммуникаций, что привело к полной взаимосвязи всех систем предприятия. Как и в случае с аппаратным обеспечением и программированием контроллеров, здесь наблюдается переход от проприетарных реализаций к более открытым предложениям.
Традиционные промышленные шины, такие как DeviceNet давно предлагаются пользователям в виде проверенных и надежных устройств. Но сейчас преобладают проводные и даже беспроводные варианты Ethernet, при этом доступны несколько ведущих протоколов промышленной связи. Улучшения физического форм-фактора, в том числе во влагозащитном корпусе со стандартными разъемами и питанием по PoE, теперь позволяют Ethernet-устройствам подходить и для промышленных сред.
Некоторые протоколы, такие как EtherNet/IP, PROFINET и Modbus-TCP, связаны с марками и моделями конечных устройств, тогда как другие оптимизированы для типов задач автоматизации (например, EtherCAT для управления движением). Хотя EtherCAT не нов, включение этого протокола в более функциональные ПЛК теперь означает, что приложения управления движением низкой и средней сложности могут быть интегрированы в платформу автоматизации без необходимости использования отдельных контроллеров движения.
Ethernet-APL – это среда, оптимизированная для операционных технологий (OT), которая упрощает развертывание проводного Ethernet на полевых устройствах. IO-Link развивается как оптимизированная полевая шина для базовых дискретных устройств автоматизации с соответствующими коммуникационными возможностями и интеллектом.
Соединение ОТ с ИТ для безопасного включения приложений Промышленного интернета вещей (IIoT) и передачи данных для поддержки удаленной визуализации и аналитики требует другого класса протоколов связи. OPC UA и MQTT доминируют в этой роли. Хотя некоторые из их возможностей частично совпадают, для обоих протоколов существуют оптимальные варианты применения, и пользователи могут реализовать их одновременно. Другие вспомогательные инструменты, такие как Node-RED, стали предпочтительными в качестве графического метода обработки и передачи данных в облако для использования другими приложениями.
От датчика до контроллера, от локального сервера, до облачных ресурсов и браузера – что все это означает? В «старые времена» контроллеры меньшего размера имели ограниченный набор функций, поэтому для достижения полной возможности подключения требовались более крупные устройства или несколько уровней интеграции. Сегодня и в будущем пользователи захотят, чтобы эти опции были доступны даже на самых простых и недорогих платформах автоматизации (Рис. 2).
Рис. 2. Сегодня даже недорогая платформа автоматизации ПЛК оснащена расширенными логическими возможностями, управлением движением, проводным/беспроводным подключением, протоколами связи ИТ/ОТ и многим другим
Роль интегрированной робототехники
На протяжении многих лет робототехника в основном существовала как специализированная разновидность автоматизации, требующая индивидуальной интеграции в вышестоящие и последующие системы. Ситуация меняется по мере того, как робототехника в целом и коллаборативные роботы (коботы) в частности, похоже, станут одной из крупнейших областей роста во всей промышленной автоматизации в течение следующих 5–10 лет (Рис. 3). Что касается сопутствующих разработок, системы машинного зрения значительно продвинулись за последнее десятилетие, и многие из них стали совместимы с роботами, что позволяет легко интегрировать их во множество приложений.
Рис. 3. Робототехника представляет собой быстрорастущую область промышленного дизайна – спрос на функциональные платформы автоматизации и связанные с ними сенсорные технологии будут расти, поскольку пользователи стремятся повсеместно интегрировать робототе
Современные платформы автоматизации должны быть готовы идти в ногу со временем, предоставляя необходимую вычислительную мощность, инструкции по программированию и технологии плавной интеграции с робототехникой и машинным зрением. Современный ПЛК с такими возможностями, размещенный рядом с робототехникой в качестве платформы автоматизации будет обладать явным преимуществом.
Роль искусственного интеллекта в будущем ПЛК
Ни одна перспективная статья о промышленной автоматизации, написанная в 2024 году, не может упустить из виду потенциальное влияние искусственного интеллекта (AI) и машинного обучения (ML) для анализа ситуации и реагирования на нее режиме реального времени. Однако с этой темой связано много шума, поскольку в настоящее время в качестве платформы автоматизации программируемые логические контроллеры для этой задачи подходят не идеально. Хотя в будущем некоторые продвинутые версии ПЛК смогут запускать в реальном времени алгоритмы AI/ML.
Вместо этого ПЛК имеют хорошие возможности выступить в качестве полевого интерфейса для ресурсов искусственного интеллекта и машинного обучения более высокого уровня, предоставляя пользователям оперативные, всеобъемлющие и связанные с конкретной обстановкой данные.
С другой стороны, генеративный искусственный интеллект (Gen-AI) в ближайшие годы будет играть более важную роль в ПЛК с точки зрения создания кода. Среды разработки с интегрированными инструментами поддержки искусственного интеллекта могут помочь пользователям, возможно, даже специалистам начального уровня, разрабатывать логику автоматизации на основе библиотек и проверенного кода. ИИ, используемый в качестве инструмента разработки, может помочь ускорить разработку, повысить надежность кода и свести к минимуму ненужный и рутинный труд.
Будущий ПЛК – это часть платформы автоматизации
В течение следующего десятилетия программируемые логические контроллеры, какими мы их знаем, определенно не прекратят свое существование, даже если их будут называть ПАК, периферийными контроллерами, платформами автоматизации или чем-то еще. Но и не будет единой технологии контроллера, которая могла бы выполнять все функции во всех ценовых категориях.
Вместо этого ПЛК будут продолжать развиваться в зависимости от доступных технологий и потребностей пользователей, как они делали это на протяжении последних пяти десятилетий. Приоритетом будет обеспечение контроля в реальном времени и надежного мониторинга, но они добавят еще более совершенные функции программирования и подключения для улучшения пользовательского опыта и скорости реализации проектов.
Итак, ПЛК в ближайшее время не исчезнут, а новые технологии, подкрепленные требованиями пользователей, помогут им эволюционировать в качестве базовой платформы автоматизации.
Материал подготовлен Московским заводом тепловой автоматики (МЗТА)
