Глюки таймеров?

[superMAX]

Сейчас, собсно, работает версия без таймеров. Точнее, в работе конвейера остался задействован один таймер; остальные не юзаются.
Готова версия с собственными таймерами, прошедшее после запуска время (в миллисекундах) в которых обновляется один раз в каждом цикле программы - и тут же принимается решение об установке выхода, но внедряться она будет при плановой остановке производства. Там я на всякий случай не стал делать ФБ, а просто массивчик...
Пока что freewheeling, но, по Вашему совету, перейду на периодическое исполнение проги и, соответственно, опрос МДВВ by command. Спасибо.

Ладно, если предположение, что огромные накладные расходы на обслуживание таймеров вызваны их динамической природой, неверно, - есть другая гипотеза: сам по себе тип данных time в CoDeSys крайне тормозной и для операций над ним вызываются процедуры вычисления дат и т.д. Либо - еще одна мысль - таймеры прицепляются к обработчику прерывания часов (ну, не знаю, как там RTC реализован) и он старательно обновляет их состояние с устрашающей частотой. Как Вы к ней относитесь?

Просто выявление этой проблемы заняло очень много времени - она старательно маскировалась под сбои оборудования. Сейчас полет нормальный.

Да, и еще. Инструкция как-то не вполне объясняет инфернальный смысл параметра minCycleTime. Если это время превышено, - что, текущая задача снимается и производится запуск нового цикла? Так ли необходимы эти параметры, если есть отдельный watchdog?

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