Таймеры CoDeSys

ИМХО точки останова никак не связаны с концепцией распределения аппаратных ресурсов в многопоточной среде. Обеспечивает это распределение детерминированное выполнение в системе реального времени или реализующее вытесняющую многозадачность. Какая собственно разница. Сам по себе процесс по большому счету любой может быть остановлен на любом шаге, если при этом будут остановлены все сопутствующие процессы. Это видно из простых логических умозаключений. Другое дело, что среда программирования прерывает только процесс разрабатываемого приложения, но среда исполнения при этом никаких изменений не претерпевает, продолжая функционировать в обычном режиме, посему и таймер привязанный к аппаратному таймеру не может быть остановлен. Но это вовсе не говорит о неприемлемости точек останова. Более того возьмите хоть SoftIce он позволяет поставить в стоп вообще всю ОС. Да собственно выполнение любого кода останавливается по  завершении кванта времени выделенного потоку. Так что это нормально естественно и логично, и ничего предосудительного в поведении таймера нет…

Дэк-с ... Проблемы-то вроде нету.
Вот слегка измененный пример.
Две переменные  var1 и  var2  находятся в обоих ветках условия.
Время  _T_cycle  устанавливается таким большим, чтобы спокойно успеть заметить изменения. При большом времени, скажем - T#10s, точка останова и вовсе не нужна !  Но если нужна (когда много переменных), то можно и поставить.
Сначала изменияется  var1. При переключении таймера - var2. Все хорошо видно.
Чтобы  Win  не зависал, надо включить режим симуляции - поставить галочку  Online->Simulation Mode.

Теоретическая часть.
Точки останова опасны не для железа, а для программы.
Как было совершенно верно замечено ( Dismay ), если все части программы, связанные одним таймером остановить, то программа ничего не заметит. Но это идеализированный демо-случай. Практическую пользу имеют как-раз остановы отдельных модулей, и здесь ситуация сложнее.
Приходилось отлаживать программы работающие не от системного счетчика, а вообще от внешнего генератора. Здесь не помог даже Великий и Могучий SoftIce (хотя он имеет доступ к четырем аппаратным отладочным регистрам процессора). Пришлось вставлять свои баги, чтобы программа достигнув интересующего места остановилась и неминуемо разрушилась из-за нарушения последовательности логики. Но золотые крупицы ценной информации успевали появиться.
Хочу еще раз повторить - в каждой ситуации нужны конкретные приемы и решения.

С уважением, SAN

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

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

То была статическая отладка. Динамическая (в реальном времени) добавляет свои специфичные особенности.
Во 1-ых, точки останова работают не так, как в статике. После первой остановки, следующий шаг будет сделан не сразу на следущую команду, а через цикл. То-есть, прежде чем перейти на следущую после метки строчку, будет сделан полный цикл. Разумеется, хронологическая последовательность событий нарушится и дальнейшие результаты бесполезны. Спросите - зачем тогда нужны точки останова в RT ? Они нужны ради единственного шага, который может дать ценные сведения. И где-попало breakpoint-ы не ставят.
Вообще, каждое средство предназначено для определенных целей. Не следует возлагать лишнего, и ожидать больше чем может инструмент, а потом ругать, что он плохо сделан.

2-ое.  Надо уточнить фразу : " .. посмотреть как считает счетчик ..".
Как считает сам системный счетчик с частотой 1 кгц. (или 10 Мгц. в ядре) (?) - вряд-ли вы это прямо сможете увидеть !
А вот изменение значения функции таймеров в CoDeSys - так оно происходит с частотой цикла программы ! 

И если сделать цикл очень медленным (для отладки), то можно спокойно наблюдать за происходящим и без всяких точек останова, в реальном времени !  Правда скачки приращений будут довольно большими, но для отладки переменные всегда можно подогнать под нужную кратность пересчета.

3-тье.  Останавливать счетчик  RT  не имеет смысла - на то он и счетчик Реального Времени ! Дело не в плохой разработке среды. Есть вещи принципиально невозможные. Рассмотрение момента времени и движущееся время - несовместимы (как длину измерять в квадратных килограммах). Если остановить счетчик, то он перестанет быть счетчиком Реального Времени - в этом смысл его сути ().

Часто бывает надо выяснить какую-то конкретную предполагаемую ситуацию. Например, значения переменных при определенном значении другой переменной. Или состояние при достижении какого-то числа счетчика  и т.д.  Специально на эти случаи вставляется отладочный код, или точка останова.
Обычно подобные приемы и используются при отладке в RT.

С уважением, SAN

To Mixer http://www.prolog-plc.ru/tmpl.php?content=info3.htm

SAN, а вы не думали оформить эти измышления в виде публикации? Почитать было бы многим интересно а не только форумчанам.