Ошибка обмена данными

[asutpist]

Ситуация такая: два взаиморезервируемых контролера CPU 414 4H PG(CPU 0 был горячим резервом а CPU 1 мастером), у CPU 0 пропадает состояние RUN соответственно выходит ошибка резервирования, проходит 11 минут( контроллер 2 раза пытался включится за это время) он включается и резервирование возвращается,но при этом он становиться мастером
Мое предположение ушел в диагностику, а когда продиагностился в диагностику пошел CPU 1
но возникает вопрос почему не включился 2раза, и при смене мастера отказал 1 датчик

[stesl]

asutpist, в какую диагностику он по Вашему ушел? Его задача стоять в резерве, и ни в какую диагностику он не ходит. Для того чтобы понять, что произошло, загляните для начала в диагностический буфер CPU

[POV]

Я бы даже дополнил - ОБОИХ цпу. Можно там экспорт сделать и сюда приложить. Для получения конкретных ответов, а не гадания на кофейной гуще.

[asutpist]

asutpist, в какую диагностику он по Вашему ушел? Его задача стоять в резерве, и ни в какую диагностику он не ходит. Для того чтобы понять, что произошло, загляните для начала в диагностический буфер CPU

я в этом деле новичёк,грубо говоря только эксплуатирую, тех процесс в работе, возможности диагностировать у нас нет, хотел услышать хотя бы возможные догадки, ведь контроллер просто так мастера не меняет на резервного,темболее если до этого резервный отключался
я нашел только такую информацию --- "Если в режиме резервирования происходит ошибка сравнения ОЗУ и
образа процесса на выходах, то резервный CPU переходит в режим
поиска ошибок (реакция по умолчанию), а главный CPU продолжает
работу в одиночном режиме.
Реакция на ошибку сравнения ОЗУ и образа процесса на выходах может
быть изменена при проектировании (напр., резервный CPU переходит в
состояние STOP).
Целью режима поиска ошибок является обнаружение и локализация
неисправного CPU. Во время поиска ошибок резервный CPU выполняет
полное самотестирование; главный CPU остается в режиме RUN.
Если ошибка обнаружена, то CPU переходит в режим DEFECTIVE
[неисправен]. Если ошибка не обнаружена, то CPU подключается снова.
Отказоустойчивая система снова переходит в состояние резервирования.
Затем происходит автоматическое переключение главный/резервный. Это
гарантирует, что при обнаружении следующей ошибки в режиме поиска
ошибок аппаратура прежнего главного CPU будет тестироваться.
В режиме поиска ошибок обмен данными невозможен."

[stesl]

хотел услышать хотя бы возможные догадки

А кому нужны догадки? Это как в мире авто. Чек горит - да по ходу бенз хреновый залил )
Так же как и там существует код ошибки, от которого нужно плясать, так и здесь есть диагностический буфер куда последовательно записывается происходящее.

тех процесс в работе, возможности диагностировать у нас нет

Естественно, что чтение из буфера возможно без остановки CPU, ну и тех процесса соответственно. Все что нужно, это подключиться к CPU тем же Step 7 и заглянуть в этот буфер.

я нашел только такую информацию

А вот это уже хорошо ) Ткнули носом всезнайку (меня) ))) Не знал. Но это опять же догадка. Читайте буфер обоих CPU. И хорошо если там предыдущие сообщения уже не затерлись. По хорошему нужно по горячим следам. Хотя... Не знаю, может у 400х он там какой нибудь безразмерный (архивируемый) - мало с ними работаю.

Отправлено спустя 1 минуту 33 секунды:

у CPU 0 пропадает состояние RUN

RUN потух, или мигал?

[asutpist]

RUN потух, или мигал?

Потух
поймите меня правильно, персонала который занимается у нас контроллерами у нас нет, соотвественно прочитать ошибки,диагностику возможности нет, ко мне пришло начальство и потребовало объяснения происходящего, т.к сфера скажем так узко направленная сложно в интернете найти какую-либо точную информацию
я только за если можно было бы продиагностировать

[stesl]

ко мне пришло начальство и потребовало объяснения происходящего

Вы там как на зоне какой то... Что, если скажите, что не понимаете в контроллерах, уволят?
Гуглите: как прочитать диагностический буфер ПЛК Siemens