Блог

FBD, LD или ST: Какой язык ПЛК выбрать под конкретную задачу

2026-04-07 08:38
Спор «какой язык IEC 61131-3 главный» обычно бессмыслен. LD удобен электрику, ST нравится программисту, FBD нравится тому, кто любит блоки. На объекте важен другой вопрос: кто будет сопровождать код через три года и какой тип задачи вы решаете - дискретная логика, непрерывное регулирование, математика, последовательности, обмен с верхним уровнем.
Ниже - практическая матрица выбора без «религии», плюс типовые ошибки, когда язык выбирают по привычке, а не по задаче.

Короткий ответ

LD (Ladder) - когда важна читаемость дискретной логики «как схема». FBD - когда удобнее думать потоками сигналов между блоками (регуляторы, фильтры, типовые FB). ST (Structured Text) - когда нужна сложная логика, циклы, строки, структуры и нормальная работа с массивами. В одном проекте нормально сочетать языки: главное - договориться о правилах команды, а не писать всё на том, что «взял первый инженер».

Зачем вообще три «больших» языка в одном стандарте

Стандарт IEC 61131-3 не придумали, чтобы усложнить жизнь. Он отражает разные способы мышления инженеров. Кто-то мыслит контактами и цепями, кто-то - передачей значений между блоками, кто-то - текстом программы как в обычном коде. Если игнорировать это и тащить всё в один язык, вы платите временем отладки и обучением новых людей.

LD: когда оправдан

Хорошо подходит для: - пусковых цепей, блокировок, разрешений; - логики «если условие - включи выход», особенно когда ее должны быстро прочитать и электрик, и автоматчик; - типовых шаблонов, которые визуально похожи на старые релейные схемы.
Слабые стороны: - сложная математика и большие ветвления превращаются в «ковер»; - работа со строками и структурами обычно неудобна; - масштабирование большого проекта на чистом LD без библиотек FB тяжелое.
Типовая ошибка: писать на LD весь технологический алгоритм на сотни рung только потому что «так привык цех». Через год этот код сложно сопровождать.

FBD: когда оправдан

Хорошо подходит для: - непрерывных процессов, где много аналоговых цепочек; - каскадов регуляторов, фильтров, масштабирования сигналов; - повторяющихся узлов «одинаковый блок - разные экземпляры».
Слабые стороны: - без дисциплины блоки разъезжаются по экрану и превращаются в паутину; - сложные state-machine на FBD возможны, но часто менее читаемы, чем на ST или SFC.
Типовая ошибка: соединять всё «проводами» без группировки по функциям. Диаграмма выглядит красиво на презентации и нечитаема на пуске.

ST: когда оправдан

Хорошо подходит для: - сложных расчетов, массивов, циклов; - интеграции с текстовыми протоколами и разбором строк; - больших алгоритмов с ветвлениями и обработкой исключений; - кода, который нужно версионировать и ревьюить как нормальный софт.
Слабые стороны: - для человека без опыта чтения ST вход в проект дольше, чем в LD для простой логики; - при плохом стиле ST превращается в «спагетти» так же, как LD.
Типовая ошибка: писать на ST простейшую логику из пяти контактов «потому что так модно». Выигрыша нет, а читаемость для электрика падает.

Матрица выбора по типу задачи

Тип задачи
Чаще всего удобнее
Почему
Блокировки, разрешения, цепочки пуск/стоп
LD
Визуально совпадает с привычной схемой
PID и аналоговые цепочки
FBD
Естественно ложится на блоки и связи
Расчет, фильтрация, масштаб, единицы
ST или FBD
ST гибче для формул; FBD - если любите блоки библиотеки
Последовательности, фазы, рецепты
SFC (если доступен) или ST
Для фаз SFC часто лучше; если нет - структурированный ST
Обмен данными, парсинг, очереди
ST
Текстовая логика и циклы
Повторяющиеся узлы одного типа
FBD + свои FB или ST с функциями
Переиспользование важнее синтаксиса
Матрица не закон. Если команда сильна в ST и держит стиль, она может закрыть дискретную логику и на ST - но тогда нужны соглашения об именах и структуре.

Читаемость и скорость отладки

На пуске выигрывает не «красивый язык», а предсказуемость. Практические правила:
  • один функциональный узел - один POU или один четко названный FB;
  • избегать смешения в одном файле десятка несвязанных задач;
  • для LD - ограничивать ширину схемы, дробить на подпрограммы;
  • для FBD - выравнивать поток слева направо, группировать питание/общие входы;
  • для ST - структурировать по функциям, не копировать код, а выносить в функции.
Отладка быстрее там, где меньше скрытой связности. Если каждый блок имеет понятные входы-выходы и ограниченный контекст, вы находите ошибку за один проход. Если «все переменные глобальные и правятся отовсюду», язык уже не спасает.

Поддержка команды: что спросить на старте проекта

  1. Сколько людей будут вести проект и какой у них фон - электрики, автоматчики, программисты?
  2. Есть ли внутренние библиотеки FB и стандарты имен?
  3. Как устроен code review, если ST большой?
  4. Кто принимает решение о языке для нового модуля - тимлид или каждый сам?
Если ответ «как получится», вы получите зоопарк. Лучше одна страница стандарта: для дискретики - LD, для аналогов - FBD, для алгоритмов - ST, исключения - по согласованию.

Типовые ошибки выбора языка

«Весь проект на одном языке». Стандарт допускает микс - используйте это.
«ST потому что модно». Для простой логики вы теряете скорость чтения для смежников.
«LD потому что так просит заказчик», хотя алгоритм - чистая математика. Заказчик смотрит на HMI, а не на рung в ПЛК. Дайте ему понятные экраны, а код пишите инженерно.
Отсутствие библиотек. Повторяющиеся куски копипастятся в трех языках одинаково плохо.
Нет версионирования комментариев. Через год комментарий «потом поправим» становится правдой жизни.

Связь с железом и средой

Выбор языка не отменяет выбора платформы. Если команда уже ведет проекты в CODESYS или MasterSCADA на оборудовании одной линейки, проще держать единые библиотеки FB и стиль. Для российских площадок с импортозамещением это часто упирается в линейку СТАБУР: те же среды, предсказуемые таргеты, меньше сюрпризов при переносе типовых решений между объектами - не как единственный вариант, а как практичный путь, если чек-лист по ПЛК уже отфильтровал кандидатов.

Заключение

FBD, LD и ST - это не конкуренты, а инструменты одной команды. Выбор делается по задаче, по составу людей и по правилам сопровождения. Хороший проект почти всегда смешанный: дискретика на LD, аналоговые цепочки на FBD, «мозги» и обмен на ST. Главное - чтобы через год следующий инженер не материл предшественника, а понимал структуру.

FAQ

Можно ли смешивать языки в одном ПЛК?

Да, так и задумано стандартом. Важно разграничить границы ответственности POU.

Что выбрать, если в команде только электрики?

Больше LD и готовых FB, ST - для ограниченного круга задач с четким шаблоном.

ST сложнее для новичка?

Часто да для простой логики, но проще для больших алгоритмов после обучения.

Нужен ли SFC?

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

Как убедить заказчика не требовать «всё в LD»?

Объяснить риск сопровождения и стоимость часа отладки против часа на структурированный ST.