Siemens CPU 417-5 H. Управление с DO. PCS7

[Arist007]

Доброго времени суток, уважаемые!
Система: резервированная на CPU 417-5 H PN/DP. Крутится все на PCS7 V.8.0 SP1. Верхний уровень на WinCC Runtime V.7.2.
Собственно вопрос: На данный момент происходят чудеса - нет дискретного управления. Что я имею в виду - не меняются сигналы на DO на переферии! Управляешь оборудованием со СКАДЫ, при этом смотришь с инженерной станции (через HW Config --> Monitor/Modify) сигналы меняются - управление вроде бы как бы идет (вирутально), НО по факту на модулях ничего не происходит! По факту индикация не меняется на самих модулям DO и, как следствие, команда управления не уходит! При этом, все дискретные и аналоговые входные сигналы (DI и AI) приходят корректно и отрабатывают - затык только в дискретных выходных (DO). Пробовал и Modify-ить переменные - тот же результат (как через HW Config, так и через Variable table). Очень нужна Ваша помощь! В чем может быть проблема??
под спойлером схема - желтым выделена линия связи, по которой не происходит управление! По другим линиям связи-то все происходит нормально!

[+] СХЕМА

[aranea]

почему желтая линия не заходит в Резервный ПЛК?
раньше все работало или так с самого начала?
по периферии лучше выложить скрин Hardware (лучше в онлайне), так не очень понятно из этого куска
по диагностике шаги такие:
1. смотрим в онлайне программы что DO формируются (но могут затираться другим кодом к концу программы)
2. смотрим в Monitor/Modify или VAT таблице что DO в образе процесса включаются (DO кстати в образе или вне?)
3. идем к модулю DO и смотрим на лампочку соответствующего канала, что она горит зеленым
4. тестером мерим напряжение на выходе модуля, что канал не выгорел и выдает сигнал
5. тестером смотрим доходит ли напряжение на исполнительный механизм (катушка контактора, реле или что там у вас должно включаться)

у вас какой тип резервирования периферии

1.PNG

2.PNG

[Arist007]

почему желтая линия не заходит в Резервный ПЛК?
раньше все работало или так с самого начала?

Все именно так. Заходит в основной контроллер (Rack0), который по факту сейчас StandBy. Именно так и работало все изначально.

по диагностике шаги такие:
1. смотрим в онлайне программы что DO формируются (но могут затираться другим кодом к концу программы)
2. смотрим в Monitor/Modify или VAT таблице что DO в образе процесса включаются (DO кстати в образе или вне?)
3. идем к модулю DO и смотрим на лампочку соответствующего канала, что она горит зеленым
4. тестером мерим напряжение на выходе модуля, что канал не выгорел и выдает сигнал
5. тестером смотрим доходит ли напряжение на исполнительный механизм (катушка контактора, реле или что там у вас должно включаться)

Уже было сделано. Хронология:
1. В онлайне в программе (в логике PCS7) формируется сигнал, который уходит на DO (Q55.4 - конкретная переменная);
2. Смотрю через HW Config через Monitor/Modify - сигнал присутствует (горит зеленый индикатор и присутствует "true"), захожу в VAT - там создаю переменную (Q55.4) и там аналогично смотрю, что она в "true". Затем открываю через чарты Cross Referenses лишний раз убеждаюсь, что никто больше никак не использует этот выход;
3. Иду к модулю DO - и... данный выход НЕ горит! вот тут чудеса начинаются! - вот в чем непонятность.... как так, пока нет догадок
4. 5. только после выполнения 3.
Тип резервирования: Децентрилизованная периферия.
Скрин с HW Config-ом прикрепляю, только я его слегка урезал - вся периферия всяко не поместится. Оставил только "проблемную" часть.
Собственно Скрин

P.S. Как выяснилось, 1.5 года назад была аналогичная проблема (я на этом объекте 2й месяц). Разработчик системы сказал, что это так называемая "утечка памяти", после чего затер всю память с контроллера (включая программу) и залил заново. Проблема решилась.
На данном этапе таким путем пойти не сможем, так как фабрика работает непрерывно.

[aranea]

почему желтая линия не заходит в Резервный ПЛК?
раньше все работало или так с самого начала?

Все именно так. Заходит в основной контроллер (Rack0), который по факту сейчас StandBy. Именно так и работало все изначально.

картинка немного не совпадает с хардваром
в хардваре показано что резервируемая периферия сидит на профинете от портов ПЛК в слоте #3-4 (A00-PLC-01-0 и A00-PLC-01-1)
а желтая линия отходит от коммуникационных процессоров в слоте #5 (CP 343-1)
поэтому на картинке нужно смотреть на зеленую линию

что за ошибки на 8 и 9 адресе?
что пишется диагностическом буфере ПЛК?
нет ли ошибки резервирования (REDF)?
лампы форсирования (FRCE) не горят на ПЛК?
проверьте питание всех модулей согласно схеме подключения в руководстве и проекте

у вас на то и H-система, чтобы была возможность перезагрузить оба ПЛК по очереди без остановки производства (только очень аккуратно, PCS та еще бякость (имхо))

[Arist007]

картинка немного не совпадает с хардваром

согласен, есть несовпадения с проектом, причем большие. Я скинул схему для общего понимания картины больше. Местный проект (как, в принципе, и везде) исправляли чёрти знает сколько, но ни единого изменения схемы АСУТП нет! Так что примерно так...
В новом скрине (под спойлером) я скинул показать линии связи, подключенные к ПЛК (как бы тоже для общего понимания, но для решения проблемы, я думаю, они не помогут).

[+] СКРИН

1. на скрине ошибки с адресов 8 и 9 с полным содержанием ошибки. Физическая связь адресов 7-10 указана на схеме - она верная по факту (за исключением номеров портов). С этой ошибкой сейчас связь работает - от аналоговых входов с адресов 8-9 приходят показания (они изменяются как на скаде так и в ПЛК);
2. в диагностическом буфере контроллера ничего интересного и ничего, касающегося этой темы (отваливались и подсоединялись обратно пару датчиков, сидящих не на рассматриваемой линии);
3. лампы REDF не горят - резервирование активно. Недавно было падения резервирования (вылетел модуль синхронизации H Sync, но все починили, работает - по крайней мере по индикации все нормально);
4. нет, FRCE лампы не горят;
5. питание, вроде как, приходит правильно на модули (работало же как то все до этого..), и светодиоды горят на модулях (подтверждают питание).

получается можно будет сбросить всю программу с работающей резервированной системы?? Сначала один ПЛК перезагрузить, потом дождаться его "поднятия", а затем и другой ПЛК прогрузить?.. Мне же нужно будет полностью очищать память с ПЛК.. Тогда вопросы:
1. Допустим я стер всю память с контроллера (это как я понимаю последовательностью действий с рычажком RUN/STOP/MRES, правильно? - эта процедура не называется ли холодным пуском (cold start)?)
2. память с контролера стерлась - как мне заново прогрузить на один из резервированных контроллеров? через инженерную станцию, как я понимаю, правильно?

P.S. на счет бякости PCS7 не раз уже слышал - многие АСУТП-шники плюются.. Сам только недавно с ней столкнулся (до этого был все просто сименс) и ничего хорошего не нахожу!

[Arist007]

проблема решилась очисткой памяти с контроллеров и записью программы полностью.
Алгоритм:
Сначала сделали Reed Back. Далее перевели в режим стоп ПЛК Rack0 (он был StandBy), через MRES сброс памяти, оставляем в режиме СТОП. Далее аналогичные действия с ПЛК Rack1 (он был в Master'е). Далее сделали обоим контроллерам Clear/Reset (на всякий пожарный), компиляция и прогрузка Entire Project в каждый ПЛК. Затем рычажком в RUN ПЛК Rack0 - он поднимается, становится Мастером, затем рычажком в RUN ПЛК Rack1 - поднимается становится в StandBy.
Затем проверяем выходные сигналы ии, о, чудо чудесное, работает!

Загадкой остается причина возникновения неисправности.