ПЛК 110 [M02] произвольные перезагрузки

Добрый день, коллеги!

Есть проблема с самопроизвольной перезагрузкой контроллеров М02 модификации. Один из них (проект ГП из приложения) работал с 12.01.2019 по 14.06.2019 без замечаний, 14.06.2019 перезагрузился первый раз, что привело к технологопроблемам на ~12 часов, после этого 1.10.2019 произошел идентичный случай. В поддержку звонил/писал с вопросом как безошибочно определить контроллер бракованный или нет а так же в чем могут проблемы (вдруг я программу криво написал...), но по телефону сказали что-то из разряда "это ваши проблемы, если хотите отправьте в ремонт/для диагностики оставьте его с любой программой на 5 минут, если не сломается то с ним все ок", а в запросе на почту (Обращение № :##246621##) пишут что может быть прошивка стара, а может быть плата плоха... Ну или высоковольтное оборудование, которого там рядом нет.

Симптомы произошедшего:
Все значения уставок стали равный нулю (ModBus Slave ретейны по умолчанию же?), некоторые ретейн переменные (настройки регуляторов) записались с ошибками, причем без возможности их перезаписать (только после заводского сброса их изменил).

В приложении два проекта с которыми данное событие произошло.
1) МДИ работал до этого на старых таргетах, потом при томощи экспорт импорт стал работать на новых таргетах (работал отлично 3 месяца, потом ребут. Уже 5 недель полет нормальный)
2) ГП про него написано выше.

В общем прошу помощи, т.к. на форуме как то мало информации для такого большого провала, а поддержка вежливо молчит...

Здравствуйте, приложите из контроллера файл debug.txt
онлайн - читать файл из ПЛК - написать ручками debug.txt
в файле будет указана причина перезагрузки. склоняюсь в первом приближении на срабатывание watchdog'a
также будет хорошо, если в конфигурацию добавите модуль статистики - посмотреть свободное процессорное время и флаг его перегрузки.

Цитата:

---

Сообщение от Трофимов Артем

Здравствуйте, приложите из контроллера файл debug.txt
онлайн - читать файл из ПЛК - написать ручками debug.txt
в файле будет указана причина перезагрузки. склоняюсь в первом приближении на срабатывание watchdog'a
также будет хорошо, если в конфигурацию добавите модуль статистики - посмотреть свободное процессорное время и флаг его перегрузки.

---

Вы были правы, это watcdog (до плк не смогу добраться ещё день-другой, но на столе есть ещё один, см. вложение), но что может его вызывать (вопрос как к более опытному)?

Вроде все разделено на кусочки, вроде все блоки простые, нет сложных вычислений...

мне подозрительно не нравится число ПИД регуляторов, которые Вы вызываете на обработку синхронно в один такт. т.е. у Вас в new_task вызываются две программы с 9 ПИД регуляторами каждая+ есть возможность наложения OLDTask вызова в момент исполнения кода.
приоритеты задач у Вас одинаковые. у Вас в менеджере задач даже написано максимальное вполнение OLDTask около 4 миллионов миллисекунд - даже если ошибка в отображении плагина ( должен всё таки в микросекундах ввыводить ) 4кк мкс = 4 секундам выполнения,
а у Вас сторожевой таймер настроен на 1 секунду незавершения цикла выполнения.
никогда не рекоммендовал вызывать более 4-5 ПИД регуляторов одновременно :
1) не факт , что обновились данные на входе регулятора , с учётом пулинга в 100мс в конфигурации ПЛК.
2) а требуется ли Вам обработка ПИД регулятора каждые 50 мс? я бы порекоммендовал всё таки сделать обработку ПИД регуляторов по очереди по входам EN/ENO, допустим 2 в первом вызове программы, следующие 2 ПИД в след вызове и так далее по кругу.
ПИД регуляторы одни из самых требовательных для расчётов ФБ к ресурсам процессора.

Спасибо Коллеги за столь быстрый ответ! Благодаря такой поддержке ОВЕН в СНГ вне конкуренции.

Цитата:

---

а у Вас сторожевой таймер настроен на 1 секунду незавершения цикла выполнения.
никогда не рекоммендовал вызывать более 4-5 ПИД регуляторов одновременно :

---

Я думал наоборот, что это самое простое для контроллера, исправлю, спасибо!

Подскажите так же как интерпретировать значение в конфигураторе задач: NewTask макс 940µс. Я понимаю это так, что 50 Миллисекунд (наш цикл) = 50000 Микросекунд, а если мы 18! PID-ов обсчитываем за 940 Микросекунд (это <5% цикла), а это основная масса программы, то по сути у нас контроллер отдыхает и можно в оптимизацию не лезть. Потом ещё статистика в "конфигурации ПЛК" говорит что из 1000Мс у нас 900Мс контроллер простаивает.

Цитата:

---

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

---

А можно подробнее про экспоненту. Как можно от этого защититься и при каких условиях можно это достичь? Я думал что могу выйти за диапазон в пересчете скорости изменения уровня в расход (Raz_v_n), но "на настольных" условиях с учетом "проверки достоверности" и масштабирования сигнала не смог...

Цитата:

---

Сообщение от capzap

библиотека oscat, раздел математики, функция сигмоида, надеюсь по исходнику будет понятно как лучше сделать

---

У меня EXP (время цикла/пост. фильтра). Они объявлены сразу значениями и результат в промежутке от -1 до 1. Спасибо за подсказку!

Цитата:

---

Сообщение от Shpilli Willi

Спасибо Коллеги за столь быстрый ответ! Благодаря такой поддержке ОВЕН в СНГ вне конкуренции.


Я думал наоборот, что это самое простое для контроллера, исправлю, спасибо!

Подскажите так же как интерпретировать значение в конфигураторе задач: NewTask макс 940µс. Я понимаю это так, что 50 Миллисекунд (наш цикл) = 50000 Микросекунд, а если мы 18! PID-ов обсчитываем за 940 Микросекунд (это <5% цикла), а это основная масса программы, то по сути у нас контроллер отдыхает и можно в оптимизацию не лезть. Потом ещё статистика в "конфигурации ПЛК" говорит что из 1000Мс у нас 900Мс контроллер простаивает.

А можно подробнее про экспоненту. Как можно от этого защититься и при каких условиях можно это достичь? Я думал что могу выйти за диапазон в пересчете скорости изменения уровня в расход (Raz_v_n), но "на настольных" условиях с учетом "проверки достоверности" и масштабирования сигнала не смог...

---

модуль статистики говорит о том как работает основной цикл программы. у Вас он пустой и ресурсы тратятся на конфигурацию ПЛК, к сожалению этот модуль не может высчитать данные занятые под задачи таск менеджера.
да , у Вас всреднем быстро обсчитываются, но тот же плагин говорит , что у Вас там где то что то пошло не так, всё таки накопление интеграла и расчёты в определенный момент могут выйти за пределы средних значений, что вызывает в одном единственном цикле сумасшедше большое время выполнения. как видно в плагине таск менеджера. по поводу 4-5 экземпляров. возможно я не точен, т.к. опираюсь на данные используя ПЛК100 , ПЛК 63. лично на ПЛК110м02 не было у меня необходимости в ПИД регулировании, но думаю то что применимо для слабого проца - применимо как практика и для более мощного. всё таки цикл обработки программы ПЛК в большстве задач сильно меньше обновления данных в интерционных процессах , что позволяет разбить все экземпляры ПИД на группы и вызывать по очереди без вреда для технологического процесса

Цитата:

---

Сообщение от Трофимов Артем

модуль статистики говорит о том как работает основной цикл программы. у Вас он пустой и ресурсы тратятся на конфигурацию ПЛК, к сожалению этот модуль не может высчитать данные занятые под задачи таск менеджера.
да , у Вас всреднем быстро обсчитываются, но тот же плагин говорит , что у Вас там где то что то пошло не так, всё таки накопление интеграла и расчёты в определенный момент могут выйти за пределы средних значений, что вызывает в одном единственном цикле сумасшедше большое время выполнения. как видно в плагине таск менеджера. по поводу 4-5 экземпляров. возможно я не точен, т.к. опираюсь на данные используя ПЛК100 , ПЛК 63. лично на ПЛК110м02 не было у меня необходимости в ПИД регулировании, но думаю то что применимо для слабого проца - применимо как практика и для более мощного. всё таки цикл обработки программы ПЛК в большстве задач сильно меньше обновления данных в интерционных процессах , что позволяет разбить все экземпляры ПИД на группы и вызывать по очереди без вреда для технологического процесса

---

Спасибо, за пояснения по этому вопросу!

Мы тут ради эксперимента перенесли программу GP на старые таргеты (новый контроллер ПЛК110-60-24-рм 2019года, старый контроллер ПЛК110-60-24-рм 2016 года) без изменений по коду. Скриншоты в приложении.
Прогресс и мощь М02 очевидна, но вот я склоняюсь что зависания все-таки имели хардварный характер. Также тому подтверждение что мы уже заменили один ПЛК 2012 года выпуска, который работал без сбоев более 6 лет на ПЛК 2018 года выпуска М02, и за 4 месяца было одно зависание. По программе проверил все времена циклов, сторожевых таймеров, настроек вкладки "ресурсы", везде все одинаково... В чем ещё может быть причина ума не приложу.

А если все программы добавить в одну задачу, то получается интересный результат... Работает так уже часов 8...

Доброго времени суток, друзья-коллеги!

В общем я не знаю что делать с ПЛК модификации М02... У нас их на данный момент 7 шт, из них 3 уже в работе, остальные до конца года должны быть включены в работу. Проблема в том, что поддержка уже две недели молчит, контроллеры перезагружаются раз в 3-6 месяцев без видимых причин (а это деньги, простои и некондиция).

Сегодня последнее что пришло в голову проверить его на перегрев. В итоге по датчику, температура поднялась до 60 градусов в корпусе, и все отлично работало (грел тепловентилятором). В чем может быть проблема перезагрузок не могу представить, но отдавать остальные 4 контроллера в АСУТП не выяснив причин не хотелось бы.

В общем я в смятении и начинаю переобуваться из адепта овна (правильно ставьте ударение!) в скептика...

Цитата:

---

Сообщение от Shpilli Willi

Доброго времени суток, друзья-коллеги!

...контроллеры перезагружаются раз в 3-6 месяцев без видимых причин...

---

Было такое, прошивку обновили и как бабка отшептала )

Цитата:

---

Сообщение от Shpilli Willi

Доброго времени суток, друзья-коллеги!

В общем я не знаю что делать с ПЛК модификации М02... У нас их на данный момент 7 шт, из них 3 уже в работе, остальные до конца года должны быть включены в работу. Проблема в том, что поддержка уже две недели молчит, контроллеры перезагружаются раз в 3-6 месяцев без видимых причин (а это деньги, простои и некондиция).

Сегодня последнее что пришло в голову проверить его на перегрев. В итоге по датчику, температура поднялась до 60 градусов в корпусе, и все отлично работало (грел тепловентилятором). В чем может быть проблема перезагрузок не могу представить, но отдавать остальные 4 контроллера в АСУТП не выяснив причин не хотелось бы.

В общем я в смятении и начинаю переобуваться из адепта овна (правильно ставьте ударение!) в скептика...

---

Добрый день.
Мне жаль, что Вы столкнулись с такой ситуацией при работе с нашим оборудованием.
Согласно нашим данным, сегодня, 3 октября, в 12.57 от технической поддержки Вам было отправлено письмо. Получили ли Вы его?
На всякий случай дублирую письмо в Ваш адрес с support@owen.ru

Цитата:

---

Сообщение от Мария Мильчакова

Добрый день.
Мне жаль, что Вы столкнулись с такой ситуацией при работе с нашим оборудованием.
Согласно нашим данным, сегодня, 3 октября, в 12.57 от технической поддержки Вам было отправлено письмо. Получили ли Вы его?
На всякий случай дублирую письмо в Ваш адрес с support@owen.ru

---

Да, получил (как только написал пост), спасибо! Кстати когда мне передали платы для замены, данной инструкции не было.

Завтра проверим "свободные" ПЛК, на следующей неделе остальные. По результатам отпишусь. Надеюсь на лучшее)

Цитата:

---

Сообщение от lazy

Было такое, прошивку обновили и как бабка отшептала )

---

Уже на последнем ПЛК прошивку обновили, посмотрим как пойдет.

Цитата:

---

Сообщение от Мария Мильчакова

Добрый день.
Мне жаль, что Вы столкнулись с такой ситуацией при работе с нашим оборудованием.
Согласно нашим данным, сегодня, 3 октября, в 12.57 от технической поддержки Вам было отправлено письмо. Получили ли Вы его?
На всякий случай дублирую письмо в Ваш адрес с support@owen.ru

---

Все платы посмотрели на предмет брака, все сфотографировали. "Бракованной" маркировки не нашли. На всякий случай фото в приложении.
Так же хотелось бы узнать "официальный" ответ как относится к модулю статистики и "полосочкам" в конфигураторе задач? Как я писал выше в ПЛК 2016 года (без M[02]), модуль статистики говорит что ПЛК перегружен, а на M[02] с той же программой что все ОК...

После обновления решили обновить/проверить полностью все ПО. Появились вопросы:
1) как посмотреть версию ИСПОЛЬЗУЕМОГО таргета (саму версию можно глянуть в C:\CoDeSys\Targets\PLC110.60_M_v2\IOModules\hardwa re_v2.cfg, знаю).
2) Если в данной папке лежит таргет версии к примеру 2.11, а для прошитого ПЛК нужен >= к примеру 2.14, то я просто ставлю поверх старого таргета новую версию (без изменений в самом проекте) и все?

Добрый день.
1. Версию используемого таргета в самом проекте посмотреть нельзя. В открываемый проект подтягивается установленная на данном ПК версия таргет-файла контроллера.
2. Да, при установке более свежей версии таргет-файла она перезапишет старую, и при следующем открытии Codesys подтянется уже новый таргет.

Не забудьте только выполнить очистить все перекомпилировать все.

[Все платы посмотрели на предмет брака, все сфотографировали. "Бракованной" маркировки не нашли.]
Какая бракованая ?

Доброго времени суток!

Спасибки за ответы насчет таргетов!

Цитата:

---

Сообщение от boxbeer

[Все платы посмотрели на предмет брака, все сфотографировали. "Бракованной" маркировки не нашли.]
Какая бракованая ?

---

Во вложении смотрите.

А еще остался вопрос...

Цитата:

---

Сообщение от Shpilli Willi

Так же хотелось бы узнать "официальный" ответ как относится к модулю статистики и "полосочкам" в конфигураторе задач? Как я писал выше в ПЛК 2016 года (без M[02]), модуль статистики говорит что ПЛК перегружен, а на M[02] с той же программой что все ОК...

---

Доброго времени суток!
Решилась ли как то ваша проблема?
Сейчас на одном объекте наблюдается похожая ситуация...