Постановка задачи была такой: конвейер розлива бытовой химии перестал работать по неизвестной причине. Контроллер S7-1200 Siemens встал в стоп-режим и отказывался работать. Перезапуск контроллера по питанию не помогал. Конвейер простаивал, что вело к серьезным убыткам. Владельцам срочно требовалось восстановление работоспособности линии.
Позднее удалось понять, почему старые системы на подобных ПЛК Siemens встают. Если со временем возникают дефекты питания контрольных цепей датчиков 24VDC, и они начинают «коротить» о корпуса, то контроллер воспринимает это как критическое нарушение и останавливает работу, переходя в режим «Стоп». При этом не умел или не понимал как его сбросить без загрузки кода. На тот момент загрузил исходник после конвертации с 11й версии до 17й.

Так выглядят шкафы после 10 лет эксплуатации

В проекте использовался модуль OMRON, трансформировавший дискретные импульсы в аналоговый сигнал 0-10В, которые далее по схеме управляли частотным преобразователем, изменяя скорость движения конвейера.
Договорились на выезд по диагностике.
По приезду выяснилось, что сбросить режим «Стоп» из имеющейся у меня на компьютере версии TIA-Portal 17 без загрузки ПО не выйдет. Контроллер предлагал загрузить программу заново, заменив старое ПО.
Исходники (программа ПЛК) у владельцев действительно были, но от TIA-Portal 11. Разумеется, такой на моём компьютере не было, а ставить новый образ для единичного случая выглядело нецелесообразным. Зато были версии TIA-Portal 13 и 17, что позволило при последовательной конвертации сделать исходный проект с относительно свежей версией TIA-Portal. После конвертации загрузил ПО в контроллер. Программа заработала, но не так, как раньше.
Первый предательский симптом в работе программы проявился сразу после загрузки, - перестал запускаться основной двигатель конвейера. Со слов персонала, в старой стертой версии ПЛК привод работал, и лента конвейера ехала. Принцип работы конвейера (его движущей части) был основан на работе частотного привода, через модуль преобразования ШИМ выхода (импульсы) в аналоговый сигнал. Почему перестала работать данная функция и по какой-то причине, сейчас уже и не выяснить. Именно после нескольких конвертаций и загрузки перестало работать, при этом других ошибок не было и остальные части кода вроде как работали.


Так выглядел проект, все переменные выполнены на чешском языке. До понимания назначения переменных пришлось догадываться. С учетом вложенности и множества перекрестных вызовов переменных, понять, что от чего зависит, удавалось с трудом.
Что же делать? Конвейер по-прежнему стоит, а работать нужно. Соединились с чешскими авторами кода (благо, несмотря на санкции, отвечают и пытаются помочь). Чехи подключились по удаленному доступу в онлайн и начали вести удаленный ПНР, общались со мной на английском (забыл, как сказать «поршень» и сильно переживал из-за этого). Они нашли какой то свой исходник (программу), загрузили, и конвейер заработал (поехал). Всё бы хорошо, да только логика работы системы не устраивала заказчика. Не работало, как требуется по технологии, закусывало планку подвода ёмкостей, не меняло корректно скорость ленты.
Следует сказать, что конвейер розлива бытовой химии механически устроен довольно сложно. Часть движущихся осей могут вступить в конфликт с другими, при этом вероятны механические повреждения элементов из нержавеющей стали. Также необходимо отметить, что помимо программной логики, присутствовала гидравлическая и пневматическая логика. Поэтому программа должна работать идеально, учитывая все возможные конфликты и совместные блокировки.

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

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


Здесь наглядно видно, из какого количества мест программного кода сопровождалась запись в одну и ту же переменную. Это сильно затрудняло понимание и поиск причин, почему то или иное устройство оказывается под действием питания.
С чешским программистом возились мы не менее 5-6 часов до тех пор, пока последний не развел руками и не сказал, что проще этот код написать заново, что в данный момент этот код не удаётся восстановить, так как под действием времени что-то утрачено. Либо они не могут понять, почему это не работает сейчас. Что этот разбор требует времени и запросили сумму в несколько сотен € за час работы по восстановлению работоспособности данного конвейера.
Заказчику такой запрос показался чрезмерным и он поинтересовался, могу ли я переписать данное ПО, чтобы конвейер начал бесконфликтное движение по наполнению бутылок. Я ответил, что постараюсь за ночь написать.
Эта ситуация немножко позабавила, поскольку к этому моменту я уже был морально готов переписать всю программу с нуля, так как достаточно долго сидел и изучал, как все работает. Посадил заказчика за общий стол (благо, заказчик владел хорошо технологией), и стали вместе составлять описания алгоритмов. Состав сигналов контроллера был небольшим, и мы достаточно быстро составили таблицу ввода-вывода.
Был составлен перечень состояний конвейера. Оказалось, что может быть 12 уникальных состояний. Расписали состояние дискретных выходов в каждом из них.

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

Потом было еще несколько выездов на объект, так как учесть все динамические особенности переходов нам не удалось. Пришлось еще отдельно прописывать схему блокировок, без которых мы чуть пару раз не сломали конвейер.
В конце работ потребовалось продумать и написать код подсчёта количества заполненных бутылок. Сходу у меня никак не выходило создать корректный алгоритм подсчёта количества заполненной тары с учетом скорости ленты, так как бутылки идут неоднородно: то часто, то очень редко. При остановке конвейера скорость выхода продукта должна начать падать пропорционально количеству ранее выпущенной продукции. Прогноз по выходу продукции в час заказчику важен, так как на основании этого количества он рассчитывает число рабочих, которых необходимо задействовать в смене.
В целом конвейер заработал, и в дальнейшем код расчета его производительности я всё-таки доделал. Отладку программы вел в Codesys 3.5, поскольку там средства отладки более знакомые и удобные, чем в TIA-Portal. Создавал отдельную программу для имитации полевых сигналов и отлаживал алгоритм на имитаторе.
В конце работы прям замечательно зашла пицца.


UPD: знатоки, посмеявшись над статьей, подсказали, где был не прав. Возможен доступ к диагностическому буферу без загрузки кода. Также, в TIA portal в свойствах ПЛК S7-1200 можно выставить поведенческие признаки после подачи питания (но для этого уже потребуется загрузка)