witalexxx, исключительно по моему мнению, нужно иначе организовывать структуру программы - изначальная проблема только в этом. Структура программы позволяет применить механистический (почти бездумный) подход к написанию почти половины программы - защиты и блокировки. А рабочие алгоритмы выполнить в конце холста. Тогда даже при неправильном алгоритме - блокировки защитят оборудование, пока программист будет судорожно исправлять и дополнять рабочую часть.

Пока готовлю статью в своём бложике. Остановился из-за того, что обновил Owen Logic до версии 2.11.368.0 (с багом в ST) - не могу откатить исходники в младшую версию, жду обновления.

Суть подхода в разделении всей системы на независимые подсистемы и их общую часть. В вашем случае будет 6 подсистем (5 насосов и общая часть). Далее, в Exel готовлю стандартные переменные (так быстрее, чем руками набирать в Owen Logic) - каждая система содержит наборы по 16 бит:
- состояние (включён, выключен, в аварии, готов к работе и пр.)
- состояние предупредительной сигнализации
- состояние защитной блокировки
- команды из вышестоящей системы (панели оператора, SCADA, OwenCloud).
Получается всего 6 подсистем х 4 набора х 16 бит = 384 переменных. Конечно же тут Exel - незаменим.
Также добавляются группы переменных:
- для обмена с экраном
- для привязки к аппаратной части ПР (состояние ПРМ, наличие связи с ПЧВ, состояние аналоговых входов)
- входы
- выходы

После этого с участием этих переменных создаётся программа - защиты и рабочие алгоритмы.

По мере набора программы выясняется какие переменные для настройки потребуются и они отдельно прописываются в файл импорта сетевых переменных.
А пока эти места пропускаются.
Настройки удобно хранить в сетевых переменных - они энергонезависимы, позволяют редактироваться и с экрана и с панели (SCADA / OwenCloud), получают начальное значение.
Также в сетевые переменные отправляются текущие состояния (измеренные температуры, давления, упакованные биты состояний-сигнализации-блокировок и пр.)

Когда вся программа готова - окончательно приводится в порядок файл импорта сетевых переменных. Exel помогает вычислить адреса и заполнить дублирующиеся поля.

Импорт сетевых переменных их расстановка по экрану.

Структура программы позволяет сразу реализовать защиты. Отрицательный эффект в появлении множества переменных, который диалектически приводит к применению Exel и в целом ускоряет работу.

Не слежу за развитием ПР200, ещё недавно для инициализации начальным значением для сетевых переменных требовались дополнительные макросы - возможно уже это улучшили.

Вчерне этот рассказ иллюстрируется тремя последовательными этапами программы-примера: 2 насоса работают на одну магистраль.
Это просто иллюстративный пример, подозреваю, что на оборудовании не заработает.


Достоинство методики, на мой (авторский) взгляд:
1 механистический подход к значительной части программы - т.е. защиты и блокировки 100% не будут пропущены из-за спешки, т.к. реализуются в самом начале
2 сама программа разделяется на почти независимые разделы, а переменные служат для связи между ними. Причём, переменные имеют одинаковый префикс и механистически только по признаку этого префикса подключаются к макросам на холсте
3 при необходимости расширения программы - переменные состояния и блокировки уже объявлены и ждут лишь переименования под ситуацию

В архиве файлы для каждого этапа программы:
- создание множества стандартных переменных (получение образца, черновое массовое создание "протягиванием" ячеек в Exel, переименование под конкретную задачу)
- создание программы (механистическое создание части без рабочих алгоритмов, "интеллектуальное" создание рабочих алгоритмов, завершение кода после импорта сетевых переменных)
- создание множества сетевых переменных (получение образца, заполнение по мере разработки программы, уточнение адресов и дублирующихся полей)

Иллюстация(возможно_с_ошибками).zip