ST vs LD в CODESYS (IEC 61131-3): как выбрать язык программирования ПЛК в АСУ ТП

Введение: зачем выбирать между ST и LD

В CODESYS и большинстве ПЛК-платформ программирование строится вокруг стандарта IEC 61131-3: он задаёт набор языков и общий подход к построению программ для контроллеров. В реальности спор чаще всего идёт про два языка:

• графический LD (Ladder Diagram) — «лестница», визуальная релейная логика
• текстовый ST (Structured Text) — текстовый алгоритмический код, «структурированный текст»

Быстрый ответ (если нет времени читать всё)

Обычно лучший результат даёт не «или‑или», а разумное разделение ответственности:

• LD — дискретная логика, цепи «Пуск/Стоп», блокировки и разрешения, аварийные цепи, простые реле/таймеры, быстрое чтение электриком.
• ST — алгоритмы, математика, обработки массивов/структур, расчёт уставок, диагностика и обработка ошибок, маршрутизация состояний (statemachine).
• FBD (FunctionBlockDiagram) — аналоговые цепи и типовые регуляторы (в т.ч. ПИД) там, где удобнее «соединять блоки», чем писать выражения.

Почему вообще есть несколько языков: кратко про IEC 61131‑3

IEC 61131‑3 описывает набор языков программирования для программируемых логических контроллеров (ПЛК): графические (LD, FBD, SFC) и текстовые (ST; в старых редакциях также IL). Задача стандарта — унифицировать синтаксис и базовую модель программирования между вендорами, чтобы инженеры могли переносить подходы и читать чужие проекты.

Как думать о выборе языка: 6 критериев, которые реально влияют на проект

1) Тип логики: Дискретная (контакты/катушки/блокировки) или вычислительная (формулы/условия/циклы/структуры данных).

2) Кто будет сопровождать: Электрик‑наладчик на площадке, инженер АСУ ТП, или команда разработчиков (в т.ч. «айтишники»).

3) Масштаб и повторяемость: 10 цепей или 200 однотипных агрегатов/каналов? Чем больше повторяемость — тем выгоднее ST и функциональные блоки.

4) Отладка и диагностика: Нужны ли «прозрачные» rung‑схемы для быстрого поиска причины остановки? Тогда LD выигрывает в критичных дискретных цепях.

5) Интеграция с HMI/SCADA: Важны понятные теги и «разрешения/блокировки» — это хорошо ложится на LD; сложные вычисления для трендов/предиктивной логики — на ST.

6) Ограничения по времени цикла (scan time): Циклы и сложные расчёты в ST могут «съесть» время цикла. Их нужно проектировать и профилировать.

LD (Ladder Diagram): где он сильнее всего

LD исторически вырос из релейных схем: «контакты» и «катушки» в виде лесенки. Поэтому его сила — в наглядной дискретной логике и в том, что схему легко читать людям с электротехническим бэкграундом.

Типовые задачи для LD

• Пуск/Стоп двигателя, самоподхват (latch), блокировки по конечникам, датчикам, авариям.
• Логика межблокировок: «разрешение работы» от соседних узлов, защита от неверной последовательности.
• Безопасные остановы (в рамках ПО‑логики; аппаратная безопасность решается отдельными цепями и Safety‑контроллерами).
• Простые таймеры TON/TOF/TP, счётчики, триггеры, простые последовательности.

Минусы LD, о которых часто забывают

• Плохо масштабируется на сложные алгоритмы и повторяемые конструкции: много рунгов → «визуальный шум».
• Сложнее выражать математику, работу с массивами/структурами и обработку ошибок.
• При «склеивании» большого проекта в LD возрастает риск скрытых зависимостей (катушка управляется из нескольких мест).

ST (Structured Text): где он сильнее всего

ST — текстовый язык высокого уровня из IEC 61131‑3, по стилю близок к Pascal/ADA. Он удобен там, где нужен алгоритм: выражения, условия, циклы, структуры данных, функциональные блоки и переиспользование.

Типовые задачи для ST

• Расчёт уставок и ограничений (clamp), линейная/нелинейная коррекция сигналов, фильтрация.
• Диагностика: коды ошибок, приоритизация аварий, журналирование событий, обработка таймаутов.
• Работа с массивами/структурами: десятки одинаковых каналов, агрегаты, маршрутизация состояний (state machine).
• Генерация «масок» разрешений, обработка рецептов, параметров, конфигураций.

Минусы ST (и как их компенсировать)

• Для части инженеров сложнее читать «с листа», чем LD. Компенсация: стандарты именования, комментарии, UML/схемы состояний, тест‑стенды.
• Неправильные циклы и тяжёлые вычисления могут ухудшить scan time. Компенсация: профилирование, ограничение циклов, распределение задач по времени.
• Есть риск написать «как в IT» и потерять прозрачность для наладки. Компенсация: держать критичные межблокировки в LD и делать хорошие диагностические теги.

Сравнение LD и ST: таблица решений

Практический пример №1: Пуск/Стоп двигателя и блокировки

Это классический кейс АСУ ТП: пуск по кнопке, останов по кнопке/аварии, самоподхват, разрешение работы и индикация.

Как это часто выглядит в LD (смысловой разбор):

• Контакт «ПУСК» (NO) запускает цепь, но только если есть «Разрешение работы» и нет аварий.
• Контакт «СТОП» (NC) и «Авария» (NC) разрывают цепь.
• Катушка MotorRun подхватывается своим же контактом (latch) — двигатель продолжает работать после отпускания кнопки «ПУСК».
• Отдельно формируются теги для HMI: MotorCmd, MotorFb, MotorFault, MotorReady.

В ST это удобно оформить как «защёлку» с понятными тегами (пример IEC 61131‑3 ST):

(* Пример: логика управления двигателем (упрощено) *)
VAR
StartBtn     : BOOL;   (* кнопка Пуск (NO) *)
StopBtnNC    : BOOL;   (* кнопка Стоп (NC) = TRUE, когда НЕ нажата *)
Permit       : BOOL;   (* разрешение работы от межблокировок *)
Fault        : BOOL;   (* авария/защита *)
MotorRun     : BOOL;   (* команда на двигатель (защёлка) *)
rStart       : R_TRIG; (* фронт по Пуску *)
END_VAR

rStart(CLK := StartBtn);

(* Сброс защёлки при стопе/аварии/снятии разрешения *)
IF (NOT StopBtnNC) OR Fault OR (NOT Permit) THEN
MotorRun := FALSE;
END_IF;

(* Установка защёлки по фронту Пуска *)
IF rStart.Q AND StopBtnNC AND Permit AND (NOT Fault) THEN
MotorRun := TRUE;
END_IF;

Почему такой вариант хорош: на входы выведены понятные сигналы (StopBtnNC, Permit, Fault), есть явные условия сброса/установки, а для наладки можно легко добавить диагностику (почему не пускается) отдельными BOOL‑флагами.

Практический пример №2: где ST выигрывает у LD — CASE и «масштаб»

Если логика ветвится по состояниям/режимам или по счётчику, LD быстро разрастается. В ST такие ветвления читаются компактно и однозначно.

Пример: включить одну из трёх ламп в зависимости от значения счётчика:

(* Пример: выбор лампы по счётчику *)
VAR
iCounter : INT;
Lamp1, Lamp2, Lamp3 : BOOL;
END_VAR

(* По умолчанию всё выключено *)
Lamp1 := FALSE; Lamp2 := FALSE; Lamp3 := FALSE;

CASE iCounter OF
1: Lamp1 := TRUE;
2: Lamp2 := TRUE;
3: Lamp3 := TRUE;
ELSE
(* вне диапазона — всё выключено *)
END_CASE;

Про ПИД‑регуляторы и аналоговые сигналы: где уместен ST, а где FBD

ПИД‑регулирование, фильтрация, пересчёты инженерных единиц (mA→°C, Hz→RPM) — это «алгоритмическая зона». Часто её делают либо в ST (если много математики/условий), либо в FBD (если удобно работать блоками).

Важно: конкретные имена ПИД‑блоков зависят от библиотек и платформы (в CODESYS и у разных вендоров они могут отличаться). Но принцип одинаков: подаём уставку и измерение, получаем управляющее воздействие, вводим ограничения и анти‑windup.

Комбинирование языков в одном проекте — это норма (и признак зрелой архитектуры)

В реальных проектах АСУ ТП обычно комбинируют языки: LD — для межблокировок и «быстрой правды» на площадке, ST — для алгоритмов и повторяемых компонентов, FBD — для типовых регуляторов. В CODESYS это поддерживается как часть IEC 61131‑3‑подхода.

Чек‑лист качества (то, что повышает ContentEffort и реально помогает в эксплуатации)

• Единый стандарт именования тегов: Cmd/Fb/Ready/Fault/Perm/Mode, единые префиксы по агрегатам.
• Разделение на уровни: IO‑слой (сигналы), логика агрегатов (FB), логика установки/линии (sequencing), HMI/SCADA‑слой (представление).
• Диагностика «почему не пускается»: отдельные флаги причин запрета + строка/код ошибки для HMI.
• Правило «одна катушка — одно место управления» (или строгое управление через FB), чтобы не было скрытых конфликтов.
• Контроль времени цикла: избегать бесконечных циклов, ограничивать переборы массивов, выносить тяжёлое в задачи с меньшей частотой.
• Короткие примеры и тест‑кейсы: проверка аварий, таймаутов, восстановления после перезапуска.

Как связать статью с практикой АСУ ТП

Если вы изучаете АСУ ТП системно, важно уметь не только «написать код», но и выстроить архитектуру: ПЛК + HMI (панели оператора) + SCADA, подключение частотных преобразователей/устройств плавного пуска, диагностика, межблокировки и безопасные режимы.

На курсах «АСУ ТП» на kvalifik.ru эти вопросы разбираются на практике: от сигналов и схем до программирования и наладки.

СПК1хх базовый курс (программирование в среде CODESYS V3.5)
ПЛК1хх продвинутый курс (программирование в среде CODESYS V2.3)
СПК1хх продвинутый курс (программирование в среде CODESYS V3.5)

Источники (для проверки фактологии)

1. PLCopen: IEC 61131‑3 overview (языки LD, FBD, ST и др.)
2. com Automation Textbook: разделы по PLC и Ladder Diagram (LD)
3. DEIF: заметка про языки IEC 61131‑3 в CODESYS и комбинирование языков
4. IEC 61131‑3 (общая справка; редакции стандарта)

Короткое заключение

• LD — лучший для «железной» дискретной логики, межблокировок и быстрого чтения на площадке.
• ST — лучший для алгоритмов, математики, структур данных и масштабируемых проектов.
• Комбинация LD + ST (+ при необходимости FBD) чаще всего даёт оптимальное качество и скорость разработки в АСУ ТП.