Добрый день!
Помогите решить проблему с сбросом плк из-за периодического превышения времени цикла. Программа отработала около 3 мес и потом начались проблемы с кратковременным переходом плк в стоп примерно раз в 2-3 недели.
Прилагаю файл debug
Вид для печати
Добрый день!
Помогите решить проблему с сбросом плк из-за периодического превышения времени цикла. Программа отработала около 3 мес и потом начались проблемы с кратковременным переходом плк в стоп примерно раз в 2-3 недели.
Прилагаю файл debug
Такой логи простой пользователь не поймет, кроме времени перезагрузки по собаке.
Тут надо понимать, что означают ид.
Судя по логу, сброс раз в 49-50 дней (4294967295 в мс). Эту проблему на ПЛК 160 [М02] я подымал уже на форуме, поддержки не нашел(Неужели не у кого не работаю плк без выключения дольше 50 дней). В Овне подтвердили, что данная проблема существует и что сделать с этим ничего нельзя!
Перестать работать со временем так, как с ним работаете? уж не с этим ли связано? переполнение счетчика или что там еще? (предположение)
Проблема проявляется только на ПЛК 160 [М02]. Один и тот же проект работает на ПЛК 110 [М02], ПЛК 160 без проблем. Говорят аппаратная проблема.
Да, действительно, я сейчас подсчитал статистику и получилось что между остановками плк ровно 71585 минут или 49 дней 17 часов и 5 минут…..
С этим можно что то сделать?
У меня не сбрасывается. Всё норм.
На форуме обсуждали и пришли к тому, что иногда какой-то криво написанный код переполняет таймеры, которые написаны на DWORD - и от этого тупит.
В моём коде все таймеры не работают так долго... Максимум часов 8.
Вложение 85689
подвел статистику остановок плк: 1-12 остановки по питанию, 13-16 остановки по watchdog. получается, что один раз плк отработал 57 дней
Если (как сказал выше Samel) эта проблема внизу - без вариантов.
Разве только вводить в свой код принудительную перезагрузку в подходящее время и условия (типа пару недель прошло и звезды сошлись что все выключено, это безопасно и несколько сек ниочем).
Ну или менять на ПЛК110-60 + модули. Тот же Samel сказал что с этим норм.
перестаньте использовать такую точку отсчёта
нет никакого смысла вести один счёт от библейских событий
Добрый день.
Стабильно уходят 4 плк в ребут по вочдогу каждые 49-50 дней.
Подскажите, может ли бы проблема в переполнении внутренней переменной таймера TON (StartTime) ?
Если да, как лучше обыграть?
Resource_sec и TOP.Resource имеют тип данных -DINT.
P.S таких проблем в 210 (с перезагрузкой) при этом не возникало никогда.
Вложение 88528
Может кому будет полезно.
Описал эту проблему техподдержке.
Ответили, что действительно есть такой косяк - правится обновлением прошивки.
Версия 1.2.51 (от февраля 26) - которой нет в общем доступе.
На днях обновлю, будем смотреть (ждать 50 дней :o).
а зачем ждать? Открыли бибку oscat базовую, нашли реализацию, TP или TOF (TON не сложно догадаться как сделать), в строке tx := DWORD_TO_TIME(T_PLC_MS()); в место T_PLC_MS() заменили на число близкое к верхней границе диапазона DWORD и с каждым шагом добавляете к этому числу единицу, пока диапазон не переполнится и не перейдет в ноль и далее и наблюдаете, по Вашим словам, исчезновение зависания от работы таймера
Здравствуйте, а подскажите где взять эту версию прошивки? Может ссылка осталась?
Добрый день.
Напишите, пожалуйста, на support@owen.ru.
Добрый день, возможно ли проверить этот баг, не дожидаясь 50 дней (убедится что на старой прошивке происходит перезагрузка, а на новой нет)
Этот баг стабильно появляется на старой версии 1.2.42, то есть если я на старой прошивке запущу на 50 дней он перезагрузится гарантированно, или есть какие то особые условия