[?]: S7-416 мигают все светодиоды

[a_gricaj]

Доброе время суток всем!

Случилась такая ситуация - работал себе S7-416, потом стали на нем мигать все светодиоды. Подключиться по МPI, Профибас и LAN не получилось - не находится партнер для подключения
Передергивание питания не помогло - таже ситуация.
Выключил питание, вынул батарейки из блока питания и флешку с контролерра - контролер запустился.
Выключил питание, вставил батарейки в блок питания, флешку в контроллер, включил питание - контролер запустился - программа загрузилась - все ОК. Но буфер стерся и ошибки не посмотришь.

На форуме находил подобные ситуации S-300, но все же не понятно как это ситуация могла случится.

в Мануалах по S7-400 не нашел инфы по одновременном мигании всех светодиодов

Ситуация усугублена тем, что подрядчик утверждает, что виновна наша сторона - так как мы вмешивались в роботу контроллера - хотя этого не делали.

Может кто-то встечался с подобной ситуацией, или имеет какую-то информацию по определению ошибки (магание всех светодиодов).
Подскажите пожалуйста.

[Marrenoloth]

Бобик умер. Ремонт или замена по гарантии. В последнее время все чаще всплывают подобные сообщения, чем Сименс подрывает свою репутацию "дорогого и надежного". Увы.
Если хотите из него что-то слить, скиньте питание на часик и включите. Часто он может проработать достаточно для аплоада программы, потом опять в ступор.

[vlad2006gr]

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

Ремонт или замена по гарантии.

могут и не помочь. После сброса питания какое-то время работает нормально. Отправляли по гарантии, вернули, сказали исправный, прошел тестирование. Поставили, пол года проработал, потом опять начались ступоры. Что- то напоминает ситуацию с материнками компьютеров и их мостами в корпусах BGA- http://ru.wikipedia.org/wiki/BGA . Перегрев, недостаточное охлаждение в закрытом шкафу, особенно в летний период, изменение геометрии плат и как следствие нарушение пайки. Дальше в результате нестабильного контакта- корозия и полное отсуствие соединения. И в этом больше виноваты покупатели, которые стараются на всем сэкономить, и поставщики автоматики устанавливая малоразмерные шкафы набитые под завязку, выбрасывая из проекта вентиляцию и кондиционеры, климат расчеты для уменьшения стоимости проекта.
Насчет ремонта, я категорически против. Это не бытовая техника, и часто от нее могут зависить жизни людей. Если только производитель будет ремонтировать, что абсолютно невероятно.

[Rex2701]

Есть у нас один контроллер, который иногда ведёт себя так же - зажигает все индикаторы, и моргает ими пока не обесточишь.
Только контроллер не 400-ка, а 300-ка (6ES7315-2AG10-0AB0).
Закономерность появления симптома - предположительно в превышении числа подключений по Industrial Ethernet от WinCC.
Постоянно к контроллеру обращаются следующие узлы: сенсорная панель (MP277 10"), сервер WinCC (проект №1), программатор FieldPG (проект №2).
Также в сети есть инженерная станция с 3-м типом проекта WinCC, при запуске которого, через некоторое время получаем сбой 300-ки. Сейчас инженерка стала использоваться только для STEP-7, проблем с контроллером больше не возникало.

[vlad2006gr]

Речь, как я понял, шла о том, что оборудование долгое время работало нормально, потом внезапно перестало работать без веских причин. Хотя и в этом случае возможен человеко- машинный фактор. Скажем, невозможная операция, неучтенная программистами сименса или пром помеха, гроза при данной архитектуре процессора привела к такой ситуации. Сложилось десять предпосылок и больше такого не сложиться. И вручную не получится добиться. И после сброса процессор отработает без отказа сто лет.
В случае

предположительно в превышении числа подключений по Industrial Ethernet от WinCC

тут проблемы обработки связи в написанной программе на WinCC и S7-300. Со стороны WinCC - это типа dos атаки при неправильно выбранных параметров обновления, считывания и записи в базу переменных.
[color=#4040FF]http://ru.wikipedia.org/ ... ка[/color]
У меня похожая ситуация была на линии связи modbus. Когда на ней висело много различных по типу устройств, альтиваров 61, 31 и tesys-ов. При попытке добиться нормальной связи без обрывов увеличивал таймаут связи. В результате ПЛК практически входил в ступор, хотя и не до конца. В ПЛК обработка связи имеет один из высоких приоритетов. И если не учитывать это в программе, могут быть нежелательные последствия. Если задействованы блоки обработки ошибок связи, установлены корректные временные параметры контроллера, то проблем при связи не должно быть. В выше указанном случае- решение поставить мосты эзернет - модбас на однородные устройства и дальше по сети на контроллер. В этом случае, мост только получив ответ, отправляет его контроллеру, не вынуждая его ждать ответа при провале связи.

[Rex2701]

тут проблемы обработки связи в написанной программе на WinCC и S7-300. Со стороны WinCC - это типа dos атаки при неправильно выбранных параметров обновления, считывания и записи в базу переменных.

О каких программах идёт речь?
В WinCC используется стандартный "родной" драйвер для связи с S7, циклически забираются тэги, и всё.
В контроллере взаимодействие с WinCC вообще никак не прописано, да и не его это дело.

[vlad2006gr]

Я пытаюсь разобраться в возможных причинах того, либо иного поведения контроллера, непрописанного в мануалах.

В WinCC используется стандартный "родной" драйвер для связи с S7, циклически забираются тэги, и всё.

- тут вы совершенно правы. За исключением того, как драйвер забирает теги. Вот пример из сдк на драйвер:
"DeviceConnectTimeout" Value="2000" //Время ожидания ответа от ПЛК на соединение
"DeviceTimeout" Value="1000" // Максимальное время ожидание ответа на запрос
"DeviceReconnect" Value="100" // Время переподключения
"TagsUpdatePeriod" Value="500" // Время глобального обновления тегов
"CommandsTimeout" Value="2000" // Максимальное время ожидания подтверждения команды
Если ответ потерялся, скада занимает линию целую секунду пытаясь обновить значение блока данных. Потом ожидает 100 мс и повторяет попытку. И после двух- трех попыток дает запрос на считывание следующего блока. Если ответа нет, пытается заново подключится и ждет в течении двух секунд. Визуально скада резко начинает тормозить. И что будет с ПЛК при постоянно занятой линии связи? Если посмотреть на HW Config, свойства CPU 313C, закладка Cycle/Clock Memory: Время мониторинга цикла по умолчанию 150мс, и максимальное время на коммуникацию 20% от времени цикла. Если параметры впритык, и полностью забираем максимально разрешенное время на связь, в один из моментов ПЛК остановится. Через день или через два года. Это только предположения по влиянию связи на работу ПЛК. В моем случае было видно неправильное заполнение таблицы в контроллере, и соответственно неправильная отработка программы. А так-же терялась связь со всеми устройствами на линии.

[Rex2701]

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