Вакансия Инженер-программист АСУ ТП в Хабаровске, работа в компании ТЕХНОНИКОЛЬ (проспект 60-летия Октября, 8), полный рабочий день, опубликована 22.06.2022 03

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

Любые дополнительные условия, например требование контроля последовательности нажатий кнопок поставит нас в затруднительную ситуацию — мы будем вынуждены изменить схему, введя дополнительные реле. Это не является сложной проблемой при условии, что такая необходимость возникает крайне редко.

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

Дополнительной проблемой является увеличение сложности системы управления по мере развития производства и появления дополнительных функций (усложнения алгоритма работы).

Любой специалист по автоматизации сталкивался также с проблемой построения системы управления для оборудования в той предметной области, которая ему недостаточно знакома: отсутствие четкой постановки задачи, появление новых условий по мере внедрения оборудования может сделать невозможной успешную реализацию проекта.

Необходимо было создать управляющее устройство, алгоритм работы которого можно было бы менять, не переделывая монтажную схему системы управления, и в результате возникла логичная идея заменить системы управления с «жесткой» логикой работы (совокупность реле, регуляторов, таймеров и т. ) на автоматы с программно заданной логикой работы. Так родились программируемые логические контроллеры (ПЛК). Впервые ПЛК были применены в США для автоматизации конвейерного сборочного производства в автомобильной промышленности (1969 г.

Поскольку в определении «программируемый логический контроллер» главным являлось «программируемый», то практически сразу возник вопрос, как программировать ПЛК?

Алгоритмические языки программирования компьютеров того времени были ориентированы на решение вычислительных задач. Профессия программиста считалась исключительно редкой и трудной, таких специалистов не было ни на одном производстве. Идеальным вариантом могла бы стать автоматическая трансляция принципиальных схем релейных автоматов в программы для ПЛК.

Почему бы и нет? Так в ПЛК появился язык релейно-контактных схем (РКС или LD в английских источниках Ladder Diagram). Специалист-технолог мог “перерисовать” схему управления на дисплее программирующей станции ПЛК. Естественно схема изображалась не графически а посредством условных символов.

Например, описанная выше задача могла бы быть запрограммирована так:

Слева и справа в такой программе мы видим вертикальные шины питания, соединенные горизонтальными цепями. Цепи могут состоять их контактов и некоторых дополнительных элементов (например, таймер) соединенных параллельно или последовательно. Справа каждая цепь заканчивается обмоткой реле. Контакты этого реле могут в свою очередь присутствовать в других цепях. Таким образом, можно составить достаточно сложную схему аналогичную по функциональности реальной релейной схеме.

Первые программирующие станции представляли собой весьма громоздкие устройства, транспортируемые силами нескольких человек. Тем не менее, ПЛК активно начали заменять еще более громоздкие и главное обладающие “жесткой” логикой шкафы релейной автоматики.

Физически ПЛК представляет собой один или несколько блоков, имеющих определенный набор выходов и входов, для подключения датчиков и исполнительных механизмов (см. рис.

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

Рис. Принцип работы ПЛК

Развитие электроники привело к потрясающей миниатюризации ПЛК. Сегодня существуют миниатюрные программируемые контроллеры, оснащенные небольшим дисплеем и встроенными возможностями программирования, подобные контроллеры получили название программируемых реле. Типовые задачи программируемых реле — очень простые локальные системы, имеющие до десятка входов и несколько силовых релейных выходов.

Написать более сложную программу с помощью встроенного пульта непросто. Аналогично мы легко можем набрать текст SMS на клавиатуре сотового телефона, но даже ввод нескольких страниц текста, не говоря уже о больших объемах, представляется проблематичным. Для этого существуют персональные компьютеры (PC), предоставляющие гораздо более комфортабельные условия работы человека.

Один современный ПЛК способен заменить десятки регуляторов, сотни таймеров и тысячи реле. Используя PC запрограммировать такую систему совсем не сложно. Применение PC в качестве программирующей станции ПЛК является сегодня доминирующим решением. Это не только упрощает программирование, но и решает задачи архивирования проектов, подготовки документации, визуализации и моделирования. Компьютер дает удобный универсальный инструмент как для программирования простейших локальных задач на ПЛК, так и для АСУ ТП.

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

К сожалению, это не так. Необходимость изменения программы в ПЛК возникает регулярно иногда и непредвиденно. Поэтому, написана она должна быть так, чтобы любой человек, а не только ее автор мог в ней быстро разобраться и оперативно внести необходимые доработки. Говорить о том, что программы написаны для ПЛК, не вполне корректно.

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

Упомянутый выше язык LD был изобретен в США в период релейной автоматизации. В Европу мода на ПЛК пришла несколько позднее, когда релейные шкафы были уже успешно заменены на шкафы с логическими микросхемами. Поэтому возникла необходимость изобретения других языков программирования понятных новому поколению инженеров.

Так в Германии появились языки простых текстовых инструкций напоминающих ассемблер (IL). Во Франции возникли графические языки функциональных блоковых диаграмм (FBD) и высокоуровневые диаграммы описания этапов и условий переходов (Графсет, современный SFC). Применялись также языки, используемые для программирования компьютеров (Pascal, Basic). В конце семидесятых годов сложилась крайне сложная ситуация.

Каждый изготовитель ПЛК (в том числе и в СССР) разрабатывал собственный язык программирования, поэтому ПЛК разных производителей были программно несовместимы, кроме того существовала проблема аппаратной несовместимости. Замена ПЛК на продукт другого изготовителя превратилась в огромную проблему. Покупатель ПЛК был вынужден использовать изделия только одной фирмы либо тратить силы на изучение разных языков и средства на приобретение соответствующих инструментов.

В итоге в 1979 году в рамках Международной Электротехнической Комиссии (МЭК) была создана специальная группа технических экспертов по проблемам ПЛК. Ей была поставлена задача выработать стандартные требования к аппаратным средствам, программному обеспечению, правилам монтажа, тестирования, документирования и средствам связи ПЛК.

В 1982 году был опубликован первый черновой вариант стандарта, который получил наименование МЭК 1131. Ввиду сложности получившегося документа, было решено разбить его на несколько частей, вопросам программирования посвящена третья часть стандарта “Языки программирования ПЛК”.

Поскольку с 1997 года МЭК перешел на 5 цифровые обозначения, в настоящее время правильное наименование международной версии части стандарта посвященной языкам программирования ПЛК – МЭК 61131-3. Рабочей группой МЭК было принято достаточно оригинальное решение. Из всего многообразия существовавших на момент разработки стандарта языков программирования ПЛК были выделены 5 языков, получивших наибольшее распространение.

Спецификации языков были доработаны, так что стало возможным использовать в программах написанных на любом из этих языков стандартизованный набор элементов и типов данных. Такой подход МЭК не раз подвергался критике, но время доказало правильность этого решения.

Реализация подобного подхода позволила привлечь к программированию одного и того же ПЛК специалистов различных областей знаний (и что особенно важно – различной квалификации): специалистов по релейной автоматике (и даже электриков), программирующих в LD, специалистов в области полупроводниковой схемотехники и автоматического регулирования для которых привычен язык FBD, программистов, имеющих опыт написания программ для компьютеров на языке ассемблера (ему соответствует язык IL для ПЛК), на языках высокого уровня (язык ST), даже далекие от программирования специалисты-технологи получили свой инструмент программирования – язык SFC.

Представляем книгу по Structured Text (ST) МЭК 61131-3. Автор — Сергей Романов

Книга «Изучаем Structured Text МЭК 61131-3»: Ссылка на книгу

Хотя внедрение МЭК систем программирования и не позволило полностью отказаться от услуг профессиональных программистов (впрочем такая цель и не ставилась), но зато позволило снизить требования к квалификации и соответственно затраты на оплату труда программистов ПЛК. Стандартизация языков позволила (по крайней мере, частично) решить проблему зависимости пользователя ПЛК от конкретного изготовителя.

Все современные ПЛК оснащаются средствами МЭК 61131-3 программирования, что упрощает работу пользователям контроллеров (можно использовать ПЛК различных фирм без затрат на переучивание) и одновременно снимает ряд проблем для изготовителей ПЛК (можно использовать компоненты ПЛК других изготовителей).

Стандарт существенно расширил возможности на рынке труда специалиста, занимающегося программированием ПЛК. Подобно тому как автомеханик, имеющий стандартный набор инструментов, может браться за ремонт любого узла (кроме нестандартных) машины любой фирмы, так и специалист, изучивший языки МЭК 61131-3 сможет разобраться с программой любого современного ПЛК. Это позволило уменьшить как зависимость фирмы от специалиста по программированию ПЛК, так и специалиста от фирмы.

На сегодняшний день лидирующие позиции на рынке МЭК систем программирования занимает комплекс CoDeSys немецкой компании 3S-Smart Software Solutions GmbH. Его применяют 190 компаний во всем мире, большинство из этих компаний — ведущие изготовители оборудования и/или систем промышленной автоматизации.

В России ПЛК с CoDeSys хорошо известны специалистам, диапазон продукции, выпускаемой под управлением этих ПЛК огромен CoDeSys включает 5 специализированных редакторов для каждого из стандартных языков программирования:

  • Список Инструкций (IL),
  • Функциональные блоковые диаграммы (FBD),
  • Релейно-контактные схемы (LD),
  • Структурированный текст (ST),
  • Последовательные функциональные схемы (SFC).

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

В одном проекте можно совмещать программы, написанные на нескольких языках МЭК либо использовать один из них. Никаких особых требований по выбору языка нет. Он обусловлен исключительно личными предпочтениями.

В России наиболее популярен язык ST. Это текстовый язык, представляющий собой несколько адаптированный Паскаль. Второе место по популярности занимает графический язык FBD, далее следует язык LD. Помимо средств подготовки программ, CoDeSys включает встроенный отладчик, эмулятор, инструменты визуализации и управления проектом, конфигураторы ПЛК и сети.

Воплощением еще одной неожиданной идеи, коллективно сформированной пользователями CoDeSys, стало добровольное объединение изготовителей ПЛК, поддерживающих CoDeSys, в некоммерческую организацию CoDeSys Automation Alliance (САА). Суть идеи в том, чтобы превратить изготовителей средств промышленной автоматизации, поддерживающих CoDeSys, в партнеров (насколько это возможно на конкурентном рынке) и нейтрализовать последствия конкуренции между изготовителями для пользователей ПЛК.

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

Пользователь может быть уверен, что его прикладная CoDeSys-программа будет работать в любом контроллере любой компании являющейся членом САА. Пользователь может быть уверен, что используемые им инструменты (CoDeSys) проверены тысячами пользователей во всем мире. Пользователь всегда может обсудить свои затруднения и получить реальную помощь от широкого круга коллег, имевших опыт решения подобных задач.

Брокарев А. , Петров И. Компания «ПРОЛОГ»

Курс по программированию контроллеров:

Практический курс ПЛК Овен и разработка АСУ ТП в Codesys

Кто такой этот ваш ПЛК

ПЛК (программируемый логический контроллер) – компьютер с особенностями развития. Главные требования к ПЛК: надёжность, низкая стоимость, быстрая реакция на входные воздействия, простота программирования. Данные требования привели к тому, что большинство производителей для своих ПЛК выпускают нативные среды исполнения и разработки. Но нельзя не отметить CodeSys – общеизвестный разработчик ПО для программирования ПЛК.

  • Графические языки программирования:LD (Ladder diagram)
  • LD (Ladder diagram)
  • Текстовые языки программирования:IL (Instruction list)ST (Structured Text)
  • IL (Instruction list)
  • ST (Structured Text)

Реализации стандарта у разных производителей могут несущественно отличаться. Единый стандарт позволяет без особых проблем переносить код из одной среды программирования в другую.

Не как все

Самый «нормальный» язык из IEC 61131-3 – ST, который считается высокоуровневым языком программирования. Хочу обратить внимание, что под языком программирования подразумевается спецификация – правила написания кода. Время выполнения одного кода может меняться в зависимости от компилятора.

Самый важный момент, который стоит изучить, перед тем как писать код – это понимание принципов работы ПЛК. На рис. 1 изображена максимально упрощённая схема работы ПЛК.

Рисунок 1 — Принцип работы ПЛК

Из рис. 1 нужно понять, что ваш код будет выполняться каждый цикл. Время цикла — это время, которое нужно ПЛК для считывания входов, выполнения своих системных вызовов, выполнения вашей программы и формирования выходных значений. Обычно время цикла измеряется в микро- или миллисекундах.

Если в «классических» ЯП (языках программирования) первая программа выводит в консоль «Hello, world!», то в средах разработки программ для ПЛК вы консоли не увидите. Отладка происходит обычно во время выполнения программы, путём постановки точек останова, значения переменных в режиме отладки обычно накладываются на код, где они используются, причём значения можно изменять при отладке.

Прежде чем отлаживать проект – его нужно написать. И тут можно столкнуться со многими проблемами.

Сперва придётся ознакомиться со структурными единицами проекта: program organization units (POUs). POU может быть представлен как программа, функциональный блок или функция. У каждого элемента свои особенности. Типы данных такие же как и в других ЯП. Объявление переменных происходит в отдельной области перед кодом программы.

Следующая проблема – это подключение библиотек. Разные ПЛК используют разные ОС, устройства и протоколы. GitHub на моё удивление не знает про существование ST. В связи с этим остаётся надеяться на наличие нужных вам библиотек у производителя ПЛК. В случае наличия нужной библиотеки вам в редких случаях придётся ещё заплатить за её использование.

Использовать систему контроля версий в большинстве случаев бессмысленно так как ваш проект будет представлять один бинарный файл – проследить изменения будет сложно, не говоря уже про слияние проектов. Иногда производители предусматривают нативные инструменты для сливания(сравнивания проектов).

Все знают про самый используемый стек протоколов TCP/IP, но в промышленной автоматизации есть игроки поважнее, связано это с тем, что сетевые карты для Ethernet/IP/TCP стека довольно дорогие и требовательные к ресурсам устройства и устанавливать её в простенький блок питания или расходомер нерационально. На сцену выходят RS-232, RS-485, ModBus, CAN, ProfiBus, EtherCAT etc. Кроме знания протокола придётся «поковыряться» с мануалом, чтобы понять как формировать сообщения и какие ждать ответы.

Нормальные люди под frontend-ом понимают HTML, CSS, JS, у автоматизаторов это SCADA или HMI. Если кратко, то это ПО для разработки пользовательского интерфейса. Подавляющее число SCADA взаимодействуют с ПЛК посредством OPC-сервера.

При возникновении ошибок или если не знаете как реализовать ту или иную функцию, то Stack Overflow вам навряд ли поможет – скорее всего вам придётся «ковыряться» в документации производителя ПЛК.

Пора кончать

Получилось много текста, но это меньше капли в океане промышленной автоматизации. Каждой проблеме можно посвятить отдельную статью.

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

Для дальнейших дискусий и связи предлагаю telegram чат и канал.

Ну и не забываем оставлять свои мысли и замечания в комментах. Надеюсь устроить хоть небольшой движ в этой сфере.

Оцените статью
( Пока оценок нет )
Как Это Работает?
Добавить комментарий