Модульные программируемые контроллеры серии «К15». Новый взгляд на привычные вещи

Материал опубликован в СТА 1/2023

Введение

Сегодня рынок автоматизации предлагает обширный перечень модульных и моноблочных программируемых контроллеров для решения широкого спектра задач, отличающихся как по сложности, так и по ценовому порядку. И каждый для себя выделяет более приоритетные изделия, отвечающие требуемым характеристикам, бюджету проекта либо же просто давно знакомые и проверенные, подтвердившие свою надёжность за год эксплуатации. И очень часто предпочтение отдаётся иностранному производителю. В этой статье мы покажем, что такие решения далеко не всегда обоснованы.  

Знакомство с «К15»

Модульные контроллеры этой линейки реализуют классическую концепцию ПЛК: центральное процессорное устройство (ЦПУ) плюс «корзина» модулей ввода-вывода. Такой подход, в отличие от моноблочных вариаций либо смешанных решений, даёт возможность создать гибкую, масштабируемую локальную систему управления ровно под те задачи, которые необходимо решить в данный момент. Это позволяет не переплачивать за лишнее «железо», но в то же время иметь возможность практически бесшовно, просто докупив необходимые модули, расширить и усложнить систему при необходимости. Ещё один несомненный плюс такого решения – простота и дешевизна эксплуатации. Не нужно менять дорогостоящий ПЛК ради пары каналов ввода-вывода, вышедших из строя. Всего лишь меняем неисправный модуль – и система снова в работе. Серия «К15» отличается от других подобных решений неплохой эргономичностью: классическое крепление на DIN-рейку вкупе с малой шириной модулей. Все модули, включая ЦПУ, имеют один форм-фактор, что существенно упрощает компоновку при проектировании шкафного оборудования. Также следует отметить удобное расположение интерфейсной шины, соединяющей модули с ЦПУ: она уложена непосредственно в DIN-рейку и фиксируется в ней от выпадения. Это даёт возможность менять модули, не разбирая «корзину» и даже не отключая питания. Но об этом далее. 

Центральные процессорные устройства: от мала до велика

Сердцем и ключевым компонентом системы «К15», конечно же, является центральное процессорное устройство. Их в семействе на данный момент 3 модели: F1, F4 и H7. Эти ЦПУ призваны покрыть достаточно широкий спектр потребностей автоматизации. Для интеграции с системами верхнего уровня, а также для построения распределённых систем все ЦПУ реализуют широко распространённый протокол обмена Mod-bus, доступный через все имеющиеся интерфейсы. Приятным дополнением к этому имеется возможность реализации нестандартных протоколов обмена.

F1 (рис. 1) имеет достаточно скромные характеристики и подойдёт для небольших задач, где требуется изящное недорогое решение с сохранением всех преимуществ модульной схемы. Технические характеристики модуля F1 приведены в табл. 1.



F4 (рис. 2) – более мощный собрат F1, имеющий на борту Ethernet-интерфейс. Помимо увеличенных тактовой частоты процессора, RAM и Flash, данное ЦПУ имеет встроенный веб-интерфейс. Он позволяет, в свою очередь, следить за состоянием корзины, её составом, производить её мониторинг и диагностику в реальном времени. Также веб-интерфейс даёт возможность производить загрузку проекта в ЦПУ без применения программатора и обновлять программное обеспечение подключённых модулей ввода-вывода. 

Технические характеристики модуля F4 приведены в табл. 2.

H7 (рис. 3) – это наиболее производительное ЦПУ из представленных. Имея неплохие характеристики процессора, а также возможность применения внешнего Flash-накопителя в виде SD- карты, он способен «проворачивать» достаточно сложные алгоритмы с хорошим быстродействием. Также стоит отметить применение FRAM вместо EEPROM в качестве энергонезависимой памяти. Веб-интерфейс, конечно, также присутствует. 

Технические характеристики модуля H7 приведены в табл. 3.

Все ЦПУ работают под управлением ОСРВ, что повышает надёжность системы, её быстродействие и позволяет использовать аппаратные возможности процессоров на все сто процентов. 

Одна голова – хорошо. А как обстоят дела с периферией?

Один в поле не воин. Модули ввода-вывода 

Вот тут открывается простор для фантазии – линейка «К15» может похвастаться обширной номенклатурой модулей ввода-вывода. От банальных и простых дискретных модулей ввода и вывода до гальванически развязанных аналоговых модулей вывода, счётных модулей, PWM-модулей и т.д. Комбинируя их в «корзине», можно создавать абсолютно произвольные системы. Причём это могут быть системы как совсем без модулей, с одним модулем либо сложные вариации до 8 модулей с одним ЦПУ.

Ключевая особенность всех этих модулей – механизм взаимодействия с ЦПУ. Тут стоит остановиться немного подробнее. Как было сказано выше, между ЦПУ и модулями предусмотрена интерфейсная системная шина. Она выполнена на базе CAN интерфейса и физически представляет собой 5-контактную шину T-Bus, на которую устанавливаются ЦПУ и модули в процессе монтажа на DIN-рейку. Так как шина расположена в задней части корпуса модулей со стороны рейки, появляется возможность без труда снимать и устанавливать модули без демонтажа всей «корзины». 

Но главное состоит в том, что модули ввода-вывода можно заменять даже на работающей системе, не отключая питания (так называемая «горячая замена»). Это бывает весьма критично там, где отключение и перезапуск локальной системы управления связаны с нарушением технологического процесса или серьёзными производственными издержками. 

В ближайшей перспективе планируется выпуск специальной серии модулей ввода-вывода «К15», оснащённых интерфейсом RS485, на котором будет реализован всё тот же популярный протокол Modbus. Это позволит произвести буквально помодульное дооснащение имеющихся ЛСУ и РСУ без применения ЦПУ «К15» в тех проектах, где уже имеются ЦПУ, но не хватает каналов ввода-вывода.

Ключевые особенности программирования

Ну и, конечно же, нельзя не поговорить о том, как «оживить» контроллеры «К15». В отличие от классических языков МЭК, которые позволяют без глубоких знаний программирования создавать управляющие проекты для таких систем, «К15» предлагает создание проектов на широко распространённых языках высокого уровня С/С++. Стоит согласиться, что это не совсем популярный метод работы с модульными системами в сфере автоматизации. Хотя тут можно вспомнить, что в качестве скриптовых языков С, С++, С#, VBA используются в контроллерах Siemens, B&R, Allen Bradley, Schneider и других изделиях. Какие же преимущества даёт создание проектов таким способом? 

Во-первых, не стоит пугаться формулировки «язык высокого уровня». В конце концов упомянутые С и С++ очень похожи на один из языков МЭК – ST (Structured Text). По сути, это всё те же переменные, циклы, условия, переходы. Но если ST позволяет реализовать лишь то, что заложено в Runtime-оболочке контроллера, которая является как бы исполняемой средой для нашего проекта, то язык С позволяет заглянуть за рамки этой среды. Нам доступен весь синтаксический инструментарий этого мощного орудия программирования. К тому же многие алгоритмические приёмы на С/С++ реализуются проще и понятнее, а создание структур, приведение типов, callback функции, перегруженные функции и прочие приёмы программирования – приятный бонус использования языка.

Во-вторых, немаловажное значение играет инструментарий разработки. Далеко не все среды разработки проектов под те или иные модульные системы легки и понятны в освоении. Например, описание работы со средой TIA Portal занимает более 1000 страниц руководства программиста. Не менее сложна в освоении и Studio 5000 для контроллеров Allen Bradley серий Control и CompactLogix. А чтобы уверенно работать в CodeSys, нужен не один месяц освоения среды. 

Семейство «К15» программируется в среде разработки CubeIDE (рис. 4, 5) – это официальная свободно распространяемая IDE от компании STMicroelectronics, чьи процессоры и являются главным элементом контроллеров на данный момент. В комплекте с контроллерами идёт стартовый проект и подробная инструкция с описанием работы. Просто открываем проект в CubeIDE, компилируем его и «отправляем» в контроллер. Система уже будет работать, отображать веб-интерфейс, опрашивать модули. Ну а затем, используя описанные структуры и функции, можно реализовать задуманное. 



В-третьих, доступность среды разработки и ценовой аспект. Если кто-то приобретал лицензии для работы с контроллерами Emerson, Siemens, B&R, Yokogawa и многих других, – знает, что это порой немалая сумма. Да, возможно, читатель возразит: а как же CodeSys, Beremiz, OwenLogic и прочие системы? Да, они не требуют приобретения лицензий, но и далеко не все модульные системы ими поддерживаются. Как правило, каждый производитель старается разработать свой инструментарий как платформозависимый программный продукт либо как свою экосистему. Это, например, DeltaV, TIA Portal, FactoryTalk и прочие. И если до недавнего времени все эти программные продукты можно было хотя бы свободно приобрести, то, учитывая повальный уход с рынка зарубежных игроков, это уже будет сделать весьма затруднительно. В противовес этому тем более привлекательно решение «К15» – использовать доступную среду CubeIDE, не требующую лишних затрат на приобретение лицензий.

Ну и, наконец, процесс отладки проекта. Это то, что непосредственно влияет на скорость разработки. В чём одна из ключевых особенностей языков МЭК – механизм онлайн-трассировки и отладки проекта. «К15» также может похвастать этим функционалом, который изначально заложен в самой IDE. Но отладка здесь, как и подобает любому языку высокого уровня, гораздо более многосторонняя и глубокая. Тут и классический вывод текущих переменных, и точки останова, и принудительная запись значений, и пошаговое исполнение кода. Также есть возможность вернуться на шаг назад либо выполнить остановку исполнения кода по условию. Дополнительным удобством для разработчика можно считать контекстную подсветку значений переменных при наведении курсора.

Одним словом, вся мощь языков С/С++ к вашим услугам. Это делает разработку быстрее и качественнее, а дальнейшее сопровождение и рефакторинг проекта – дешевле для конечного потребителя. Если вы – убеждённый сторонник МЭК, то, конечно, переход на такой способ разработки нельзя назвать совсем простым. Но некоторые усилия, потраченные на изучение языков С, по крайней мере, в рамках поставленных задач, с лихвой окупятся в дальнейшем. 

От слов – к делу. Пример реализации задачи

Теперь рассмотрим, как решаются прикладные задачи средствами разработки «К15». Возьмём вполне конкретный пример. Допустим, у нас есть факельная установка с электроискровым розжигом дежурной горелки и фотодатчиком наличия пламени.  Наша задача: реализовать режим автоматического розжига дежурной горелки. 

При подаче сигнала пуска должен открываться клапан топливного газа, а розжиг должен происходить циклично до тех пор, пока либо не загорится пламя, либо не будет сделано 3 попытки розжига. Также алгоритм должен обеспечивать автоматический перерозжиг горелки в случае погасания пламени. Что ж, перейдём к реализации.

Сначала попытаемся реализовать задуманное средствами Codesys. Пускай это будет всеми любимый язык МЭК – FBD. Создадим необходимые переменные и функциональные блоки (рис. 6):

• start_DI – сигнал пуска системы (например, кнопка);
• stop_DI – сигнал остановки системы;
• foto_DI – фотодатчик наличия пламени;
• iskra_DO – управление подачей искры;
• valve_DO – управление клапаном.

Затем создаём функциональную схему, реализующую алгоритм (рис. 7).

Рассмотрим её по порядку. При подаче сигнала пуска через детектор переднего фронта срабатывает триггер rs1, принимая логическое состояние 1. Открывается клапан, далее сигнал следует на блок AND. Так как флаг совершения попытки розжига try и сигнал с фотодатчика имеют логический 0, то инверсивный сигнал на входе блока имеет 1, и происходит подача искры через таймер импульсного сигнала tp1 во второй строке схемы. Одновременно с этим запускается таймер ожидания пламени ton1. По завершении его счёта спустя 10 секунд выставляется флаг совершения попытки. Вместе с этим счётчик ctu1 производит инкрементирование числа попыток на 1, сравнивая полученное число с уставкой, равной трём. 

При достижении трёх попыток взводится флаг try_out, который вызывает сброс триггера rs1. Также его сброс вызывает и подача сигнала остановки системы розжига.

При установке флага try происходит изменение значения флага iskra сначала на 0, затем вновь на 1. Тем самым запускается новый цикл розжига. Здесь следует иметь в виду, что переменная try должна быть объявлена как глобальная и не сбрасываться при каждом цикле скана используемого POU. 

В случае горения флаг foto_DI принимает логическое состояние 1. Благодаря этому через инверсию блок AND на выходе принимает логическое состояние 0, блокируя цикл розжига. Если пламя гаснет, блок AND снова принимает состояние 1, и цикл розжига начинается снова.

Таким образом, для реализации задуманного потребовалось создать, помимо простых переменных, ещё 8 функциональных блоков, что для такой простой задачи немало.

Теперь попробуем решить её в рамках программного функционала «K15». Весь код размещаем в файле UCL.c. Здесь также не обойтись без объявления переменных (рис. 8).

Для единообразия сигналы имеют схожее обозначение. Дополнительно добавились переменные state  (стадия работы системы), count (аккумулятор счётчика времени) и try_count (аккумулятор числа попыток розжига). Далее обратимся к самому коду (рис. 9).

Алгоритм выполняется в основном цикле файла. Работа системы разбита на стадии: СТОП, РОЗЖИГ и ГОРЕНИЕ. Код достаточно компактный и читаемый. Создание дополнительных функциональных блоков не требуется. Следует обратить внимание, что число стадий может быть легко увеличено, например, можно добавить стадию АВАРИЯ. 

В целом, конечно, проект небольшой, задачи весьма тривиальны, но даже тут читатель сможет заметить хороший потенциал использования «К15» в плане программной реализации, простоту сопровождения и масштабирования проекта.

Кто протянет руку помощи?

Любая современная разработка не может обходиться без постоянного совершенствования, а также без исправления неизбежно существующих текущих недостатков. Если продукт «живой», он нуждается в неусыпном надзоре его непосредственных создателей. «К15» полностью соответствует этому принципу. Более того, постоянно собирается обратная связь от клиентов, разрабатывающих свои проекты на «К15», а также конечных потребителей, эксплуатирующих эти изделия у себя на объектах. Затем путём коллективного анализа пожеланий наиболее критические из них сразу же идут «под карандаш» разработчиков. 

Менее важные перманентно внедряются в последующих релизах. Это касается как программной части, так и аппаратного оснащения. Например, увеличение скорости работы FRAM, асинхронное чтение регистров Modbus, реализация пользовательских протоколов и многое другое – это то, что хотели видеть потребители в наших контроллерах.

Как сказано выше, бывают и неполадки. Их нет лишь у того, кто ничего не делает. Тут важна оперативная реакция и своевременное их устранение. С этим тоже всё в порядке. Любая неполадка или возникший вопрос обрабатываются в течение 24 часов квалифицированными инженерами, которые без проблем проконсультируют клиента и предложат варианты решения проблемы. Ну и, разумеется, не останутся без внимания и те, кто столкнётся с трудностями создания проектов – программисты также вникнут в проблематику и поделятся своим опытом решения.

Заключение

Контроллеры «К15» на сегодняшний день нельзя назвать ПЛК в классическом, общепринятом понимании этого термина. Здесь мы видим несколько иной, альтернативный подход к реализации модульных систем. Перекрывая большинство задач, которые решают обычные модульные ПЛК, данная линейка даёт разработчику нечто большее, позволяет вывести свои проекты на качественно иной уровень. 

Линейка «К15» – неплохая отечественная альтернатива в сфере автоматизации как промышленного, так и других сегментов, требующих надёжных и эргономичных решений. Это постоянно развивающийся динамичный продукт, способный составить достойную конкуренцию лидерам российско-го и зарубежного рынка. ●

Литература

1. Сайт производителя // URL: https://a-t-tech.ru.
2. Сайт разработчиков CubeIDE // URL: www.st.com.
3. Ссылка на документацию и ПО // URL: www.custom-eng.ru/kontrollery.