Да понятно всё. Вместо power_status в in пихаем соотв. выход
Не наработка же ПЛК интересует :)
Вид для печати
Да понятно всё. Вместо power_status в in пихаем соотв. выход
Не наработка же ПЛК интересует :)
С этим как раз все понятно...Цитата:
Сообщение от capzap
По поводу точности: у уважаемого swerder-а тоже есть ограничение в 49 суток (только не понял и хотелось-бы уточнить: работы ПЛК или тех. процесса?).
А что скажете о точности при вызове процедуры счета из конфигуратора задач?
Лично в моем случае (задача по сути сбор статистики и отработка аварийных ситуаций для дробильной установки) работа самого техпроцесса даже в теории не более 12 часов, но в принципе при определенных условиях думаю 49 суток без потери питания тоже теоретически возможно. И потеря 1,5% в моем варианте не столь критично. Да и если стабильное отклонение в 2 цикла, то при определенном времени цикла можно минимизировать эти потери, сделав блинк не 500мс, а рассчитать нужный... даже программно.
Да и часы реального времени в ПЛК тоже вроде не блещут точностью ))
Функция TIME() возвращает время в миллисекундах от начала работы системы в формате TIME (работы ПЛК)
Максимальное значение длительности: t#49d17h2m47s295ms
Выполните такое преобразование TIME_TO_DWORD(T#49d17h2m47s295ms); и сравните с верхним пределом из таблицы элементарных типов данных у DWORD
49 суток это ограничение работы самого таймера, через время pt := t#49d таймер остановится. прекратится счет наработки. у меня даже теоретически станок не проработает столько без выключения, поэтому над другими решениями голову не ломал, хотя способ Валенка вроде бы лишен этого ограничения.Цитата:
Сообщение от skodafelicia
Нормально. Перезапуск по Q и обнуление metronom - это же делает и передергивание питанияЦитата:
Сообщение от swerder
PT можно поставить любое - хоть 1 день
Добрый день.
Может кто подскажет как сконектить ПЛК110-30М с LECTUS по TCP/IP
Заранее благодарен.
Я решил поломать )Цитата:
Сообщение от swerder
Во вложении - результат
stat_count вызывается из основной программы, stat1 - раз в секунду из конфигуратора задач
q1 - q4 - отклонения...
В ПЛК крутится небольшая программка: опрос пары датчиков температур по 485 с МВА, вывод на ИП320 + моргание парой выходов
Какое решение использовать - решать Вам ) Думаю вполне все нормально считают. Кстати, в эмуляторе расхождения были на порядок больше даже уже за пять минут, только решение swerder-а показывало нулевое отклонение...
Swerder - 1 место !!!
Насчет эмулятора - у него цикл 50..70мс и нестабильный, средняя ошибка в полцикла - 2-3%
И любопытно - какой minlengthcycle, и что показывает про длительность цикла statistic при обмене по 485 ? :)
Перегрузка - из-за процедуры stat_count
Непонятно работа оператора JMPC. Простой пример: при наличие true на входе DI1, y=true, x=false. При DI1=false, наоборот. У меня всегда х=true, y=false. В чем ошибка?