Нет ни одного языкового руководства IEC 61131-3 для всех применений. На самом деле, лучший способ программирования на языках стандарта IEC 61131-3 — это совместное использование нескольких языков. Это учитывает (среди прочего) то, что у каждого инженера своя методология программирования.
Диаграмма последовательных функций (SFC): Напомним, что SFC является стандартом кода самого высокого уровня в IEC 61131. Технически это не язык, а скорее средство разбиения кода на разделы и визуального отображения состояния машины или режима, в котором машина запущена в данный момент. Состояниями могут быть состояния инициализации… или переход из состояния инициализации в состояние ожидания… или переход из этого состояния в автоматический или даже ручной режим… и так далее.
SFC в основном состоит из диаграмм, показывающих, как должна работать машина, — служащих уровнем оператора, который позволяет любому подойти и изучить диаграммы последовательных функций и сразу понять, как должна работать машина, — а также процессы, связанные с деталью или материалом, поступающими в машину … и каким будет конечный результат и как он будет выглядеть. нравится. Наличие этих отдельных режимов означает, что инженеры и операторы могут легко перейти к каждому из них и перейти к уровню “технического обслуживания”.
Лестничная логика: Многие инженеры опасаются, что стандарт IEC 61131-3 направлен на отмену лестничной логики, хотя это просто неправда. Многие специалисты по техническому обслуживанию в США имеют давний опыт работы с ним. Это знакомый и наглядный язык, который четко отображает наборы входных данных, ответные действия в определенных режимах и ожидаемый результат. Это идеальный уровень обслуживания, поскольку он четко показывает причинно—следственные связи — позволяет персоналу устранять неполадки и писать код для правильного аспекта машины в пределах этого узла, вызывающего проблемы.
Проблема в том, что ladder ограничивает другие виды машинного программирования. Традиционные разработчики программируют лестничную логику в таких программах, как C# и C++, а также в Python — визуальных языках, которые значительно усложняют (или не способны к этому) продвинутую математику, обработку данных и межкомпонентные коммуникационные драйверы. Для таких операций программисту потребовалось бы чрезмерное количество времени, чтобы щелкнуть, перетащить и создать катушки. Результирующее программирование также было бы довольно громоздким — с множеством ступеней визуального кода, невероятно трудных для отладки.
Лучшим выбором для более сложных процессов являются функциональные блоки. Код позволяет программистам задавать действие и выводить результат, заключенный в функциональный блок, поскольку обслуживающему персоналу не обязательно видеть внутренний код разработчика. Программисты могут поместить свой структурированный текст в этот функциональный блок, который, в свою очередь, может быть заблокирован в библиотеке. Такой код может быть скомпилирован и даже защищен как часть интеллектуальной собственности производителя — IP в виде внутреннего структурированного текста, к которому конечные пользователи не могут получить доступ.
Такое наслоение кода в соответствии с IEC 61131-3 и продуманность всех способов взаимодействия различных сотрудников с проектом делают сборку машин более надежной. Вопрос о том, кто в конечном итоге будет читать код (и какой язык был бы им наиболее полезен для интерпретации того, что пытается сделать программа), также делает дизайн более доступным. Существует множество фреймворков, таких как Packaging Machine Language (PackML), и руководств, облегчающих написание такого многоуровневого кода.
Как уже упоминалось, одним из ключевых преимуществ программирования с использованием стандарта IEC 61131-3 является то, что он позволяет создавать многоуровневый код на нескольких языках. Это удовлетворяет разнообразные потребности всех типов персонала, которому в конечном счете потребуется управлять машиной и получать доступ к ее коду. Это также позволяет инженерам отказаться от использования одного языка для всего. В конце концов, некоторые языки лучше подходят для задач, ориентированных на процесс, чем, например, дискретное управление движением. Среда IEC 61131-3 позволяет инженерам объединять даже такие разрозненные программы. Функциональные блоки управления движением PLCopen (PLCopen является еще одним отраслевым стандартом, создающим равные условия для производителей устройств управления движением) оснащены функциями движения, такими как MC_Power для питания приводов и MC_Jog для перемещения двигателей, например.
• Одним из распространенных подходов является создание кода управления движением в структурированном тексте (ST). Убежденные приверженцы структурированного текста считают, что ST превосходит их практически в любой ситуации. Однако недостатком может быть меньшая доступность для технических специалистов.
• Другой распространенный подход заключается в создании функциональных блоков управления движением на уровне лестницы (особенно там, где обслуживающему персоналу может потребоваться понимать и отслеживать функции машины) или последовательных функциональных диаграмм для более высокого уровня понимания процессов в целом.
Современные программируемые контроллеры автоматизации (PACS) и способы управления движением, эволюционировавшие за последние пять лет, означают, что теперь стало больше гибкости в том, какие языки и где используются. Аппаратное обеспечение контроллера в виде PACs представляет собой значительный отход от устаревших систем с различными устройствами, выполняющими разные задачи, — с автономным контроллером движения, отделенным от ПЛК машины и отделенным от ее HMI. Итак, раньше все это оборудование было связано с различными процессами и программным обеспечением. Теперь унификация аппаратного обеспечения в соответствии с IEC 61131-3 существенно изменила способ программирования промышленными программистами — и даже то, как промышленность концептуализирует дискретное управление в сравнении с управлением технологическим процессом … поскольку теперь они часто выполняются на одном устройстве с гибко подобранным сочетанием языков.
Информация из этого FAQ почерпнута из недавней беседы с Мариссой Такер, менеджером по продуктам управления и автоматизации Parker Hannifin, о том, как определять элементы управления на основе стандартов, а не брендов. Для получения дополнительной информации от Parker о PACs, а также бесплатного программного обеспечения для моделирования, позволяющего опробовать IEC 61131-3, посетите parker.com/emn/pac .
Вам также может понравиться:
Теперь это не просто Аллен Брэдли: новых контроллеров предостаточно
Цифровая печать сочетается с машиной, способной обрабатывать свои…
Дебютирует новая версия Parker Automation Manager
Выставка Pack Expo 2017: Что мы видим на выходе из Вегаса
Интервью: Мнение Ленце о современном программном обеспечении для автоматизации
Свежие комментарии