Стандарт МЭК 61131-3 описывает не «один язык», а семейство языков программирования контроллеров: лестничные диаграммы (LD), функциональные блоковые диаграммы (FBD), структурный текст (ST), последовательные функциональные схемы (SFC) и список инструкций (IL). Исторически IL считался устаревшим уже в третьей редакции стандарта, и на практике его используют редко. Выбор языка — не вопрос вкуса, а вопрос задачи, квалификации персонала и стоимости поддержки через пять лет.
Почему языков несколько
ПЛК решают разные классы задач. Дискретная логика («если датчик сработал — включить клапан») читается как схема реле. Регулирование и вычисления удобнее описывать формулами. Последовательности шагов («разогрев → подача → выдержка → сброс») естественно выглядят как граф состояний. Один язык не может быть оптимален для всего, поэтому стандарт закрепил семейство.
| Язык | Что это | Сильная сторона | Слабая сторона |
|---|---|---|---|
| LD | лестничная логика | наглядна для электриков, легко читать | плохо масштабируется на сложные вычисления |
| FBD | блок-схемы функций | удобна для обработки сигналов | «паутина» при большом числе связей |
| ST | текстовый язык, похож на Pascal | компактность, циклы, массивы, структуры | требует навыка программирования |
| SFC | граф шагов и переходов | явная последовательность процесса | не для непрерывной логики |
| IL | список инструкций | близость к ассемблеру | устарел, плохо читается |
Лестничная логика (LD)
LD — самый распространённый язык в промышленности, и это не случайность: его читают электрики, которые не программисты. Контакт, катушка, таймер, счётчик — все эти образы знакомы человеку, работавшему с релейными схемами.
Сильные стороны:
- читаемость для обслуживающего персонала;
- наглядность при отладке: видно, какой контакт «не проходит»;
- быстрый вход для новых сотрудников с электрическим образованием.
Слабые стороны:
- математика и обработка массивов выглядят громоздко;
- сложные ветвления превращаются в «лестницу» на несколько экранов;
- перенос кода между средами затруднён.
LD уместен для дискретной логики, блокировок, простых последовательностей и там, где код будет обслуживать электрик.
Функциональные блоковые диаграммы (FBD)
FBD представляет программу как сеть блоков с входами и выходами. Это удобно для обработки аналоговых сигналов: масштабирование, фильтрация, ПИД-регулирование, сравнение с уставками.
Плюсы: визуальная трассировка сигнала, удобство для инженеров КИПиА, естественное представление формул. Минусы: при большом числе блоков схема превращается в «паутину», а порядок выполнения приходится держать в голове.
FBD хорошо работает в связке с LD: логика — лестницей, обработка сигналов — блоками.
Структурный текст (ST)
ST — текстовый язык с синтаксисом, близким к Pascal: IF … THEN … END_IF, FOR … DO, массивы, структуры, функции. Он компактен и позволяет реализовать алгоритмы, которые в LD выглядят нечитаемо: расчёты, обработку рецептов, разбор протоколов.
| Что делаем | LD | ST |
|---|---|---|
| Блокировки и пуск/стоп | отлично | приемлемо |
| ПИД и фильтры | громоздко | хорошо |
| Расчёт расхода по массиву точек | плохо | отлично |
| Разбор строки/протокола | очень плохо | хорошо |
Минус ST — порог входа: электрик без опыта программирования читает его хуже. Плюс — компактность и удобство версионирования: текстовый файл диффится, LD-схема — нет.
SFC и последовательности
SFC описывает процесс как набор шагов и условий переходов. Это лучший инструмент для явных последовательностей: промывка, дозирование, цикл станка. Он дисциплинирует: нельзя «перескочить» шаг, переходы явные.
Ограничение: для непрерывной логики и быстрых реакций SFC неудобен, а часть сред реализует его ограниченно.
Критерии выбора
- Кто будет поддерживать код. Если электрик на объекте — LD предпочтительнее.
- Что за задача. Дискретная логика — LD; регулирование — FBD; алгоритмы — ST; последовательности — SFC.
- Кто пишет. Программист с опытом быстрее сделает ST; инженер-электрик — LD.
- Требования заказчика. Иногда язык прямо указан в техническом задании.
- Возможности среды. Не все пакеты одинаково хорошо поддерживают все языки.
- Срок жизни системы. Чем дольше, тем важнее читаемость и документированность.
Смешивание языков
Стандарт допускает использование разных языков в одном проекте, и это разумная практика: LD для блокировок, FBD для аналоговых цепей, ST для расчётов, SFC для последовательностей. Главное — единые соглашения: имена переменных, структура программных модулей, комментарии.
Проблема смешивания — рост сложности. Каждый переход между языками требует понимания, где искать логику.
Документирование и поддержка
Независимо от языка:
- имена переменных должны быть осмысленными, а не
M1,T7; - комментарии — к блокам, а не к каждой строке;
- структура проекта — по функциям, а не по «страницам»;
- версия и резервная копия — перед каждым изменением;
- описание алгоритма на бумаге — для сложных участков.
Практика показывает: код, который нельзя прочитать через год, обходится дороже, чем написать заново.
Распространённые ошибки
- писать всё на ST «потому что удобно», а потом искать электрика, который это прочитает;
- лепить LD на 20 экранов вместо выделения функции;
- дублировать логику в нескольких местах;
- использовать глобальные переменные без структуры;
- игнорировать обработку ошибок и начальное состояние;
- не фиксировать версии проекта.
Безопасность
Функции безопасности (аварийный останов, защитные двери, блокировки) реализуются не «обычной логикой ПЛК», а средствами, соответствующими требованиям безопасности машин. Путать управляющую логику и функции безопасности недопустимо: отказ общей программы не должен приводить к потере защиты.
Частые вопросы
Какой язык учить первым?
LD — для понимания промышленной логики; ST — для алгоритмов. Обычно нужны оба.
Можно ли всё сделать на ST?
Технически да. Практически это ухудшает поддержку, если код обслуживают электрики.
IL ещё используется?
В старых проектах встречается, но стандарт его не развивает. Новых проектов на IL лучше не начинать.
Насколько важен стандарт, если среда своя?
Среда может расширять стандарт, но общие принципы (типы данных, области видимости, функции) переносимы и помогают читать чужой код.
Что важнее — язык или структура проекта?
Структура. Плохо структурированный проект на «правильном» языке всё равно нечитаем.
Как переходить между языками
Переписывать проект «с нуля на ST» почти всегда ошибка. Разумный путь — постепенная замена: выделить функцию, покрыть её тестом, переписать, проверить, только потом удалить старую реализацию. Такой подход требует времени, зато не оставляет объект без работающей логики.
Полезно договориться о границах: например, логика блокировок остаётся на LD, расчёты — на ST. Тогда каждый, кто открывает проект, знает, где что искать.
Тестирование и отладка
- Проверяйте логику в симуляторе, а не сразу на объекте.
- Используйте принудительное задание значений только в отладке и снимайте его после.
- Логируйте переходы состояний — это помогает разбирать инциденты.
- Тестируйте не только нормальный ход, но и отказы: обрыв датчика, потеря связи, останов питания.
- Фиксируйте версии и результаты проверок.
Источники## Что писать в документации проекта
Даже идеально написанный код нуждается в описании: назначение программы, список входов и выходов, логика режимов, аварийные ситуации, порядок восстановления после отказа. Документация хранится вместе с проектом, а не в голове разработчика.
Для небольших проектов достаточно нескольких страниц: схемы алгоритма, таблицы тегов и перечня изменений. Этого хватит, чтобы человек со стороны смог разобраться, не переписывая всё заново.
Нужно ли знать все языки стандарта?
Нет. Достаточно уверенно владеть двумя-тремя и понимать остальные, чтобы читать чужой код.
Что делать, если среда не поддерживает нужный язык?
Реализовать задачу доступными средствами и описать логику в документации — либо выбрать другую среду на этапе проектирования.
Отдельный критерий — найм. Если в регионе проще найти электрика, чем программиста, проект на LD будет поддерживаться дольше, чем элегантный ST, который некому править. Это не технический аргумент, но он часто оказывается решающим.
Итог
Выбор языка определяется не модой, а тем, кто будет читать код через пять лет и какие задачи решает установка. LD остаётся языком обслуживания, ST — языком алгоритмов, FBD — языком сигналов, SFC — языком последовательностей. Смешивать их можно и нужно, если границы понятны и задокументированы.
Как проверять читаемость кода
Простой приём: дайте проект инженеру, который его не писал, и попросите объяснить работу одного узла за десять минут. Если он не справляется, проблема не в его квалификации, а в структуре и именах. Такой тест полезнее любой метрики сложности и напрямую показывает, сколько будет стоить поддержка.
Чего ждать от новых редакций стандарта
Стандарт развивается: добавляются объектно-ориентированные возможности, уточняются типы данных и правила областей видимости. Для практики это означает, что часть приёмов, привычных по старым средам, постепенно становится нормой, а часть — устаревает.
Не стоит гнаться за всеми новшествами: если объект работает и поддерживается, менять архитектуру ради «современности» бессмысленно. Но при новом проекте полезно посмотреть, что из возможностей поддерживает ваша среда, — иногда это заметно упрощает структуру.