Выполнение действия через промежуток времени

[Ins]

Ребята, QueryPerformanceCounter и всякие высокоточные таймеры - это конечно хорошо, но вы не учитываете две вещи:

1. Windows - система многозадачная, процессор(ы) - ресурс ограниченный. Различные потоки конкурируют за этот ресурс, а планировщик Windows управляет кому и когда отдать квант процессорного времени, при этом остальные потоки будут мирно ждать своей очереди. Вы не можете из программы прямо управлять планировщиком (только косвенно путем выставления приоритетов) и не знаете, когда у вашего потока заберут квант. Может получиться, что нужный интервал в 0,1 мс растянется на неопределенно долгое время.
2. Работа с портами (автору нужно отправлять запросы на порт) в Windows осуществляется также, как и с файлами - через драйверы файловых систем. Все запросы таким драйверам асинхронны по определению (даже если вызвать функцию ввода/вывода в синхронном режиме), т.е. мы просто кладем в некую очередь запрос на операцию, которая будет выполнена когда-нибудь кем-нибудь. При синхронном вызове функция просто дожидается окончания асинхронной операции. Когда операция будет выполнена - также определяет планировщик.

[SunKnight]

Согласен с Ins и исходя из его цитаты, Вам прийдется заниматься пайкой схемы для управления двигателем (как я понял) и через программатор делать с ним все что хатиш, задавать время с точностью до 1нс. А из винды врядли получиться сотворить такое.

[chingiz]

Обидно все таки - неужели ничего нельзя сделать. Программа уже почти готова, в смысле интерфейса, расчетов и т.д. и столько времени затрачено впустую? Когда начинал писать прогу даже не думал что на последнем этапе вылезет такая подлянка. Железо для управления есть,программа управления тоже есть и все прекрасно работает НО! в DOSe. Поэтому и занялся прогой под винду, просто чтоб интерфейс покруче был. Кстати пробовал в DOS на паскале функцию Delay - такая же ерунда как с таймером в дельфи. Под DOS прогу писал не я, даже не знаю остались исходники или нет надо поискать, но точно знаю что интервал времени задается замедлением системного таймера. Как насчет замедления системного таймера в Винде - возможно такое и что из этого получится? (Старая программа отлично работает под виндой в консольном варианте)

[SunKnight]

Можно попробовать снести винду и работать с прогой чисто из ДОСА (т.к. однозадачный). Ну это как вариант... жаль просто твою работу и время. и лучьше взять старенькое железо, чет типа Пня 1 и пробовать.

[SunKnight]

Притом у Вас уже есть прога которая работает хорошо из доса, к черту интерфейс, главное - результат.

[Ins]

такая же ерунда как с таймером в дельфи.

Дельфи тут ни причем. Это ограничение системы. Почему это происходит? Прежде всего нужно понять чему равен минимальный период срабатывания юзер-таймера (тот самый, надстройкой над которым является компонент TTimer). В документации пишут, что даже если установить период срабатывания таймера 1 мс, то на Win9x реальный период срабатывания будет не менее 55 мс, а на NT - 10 мс. То же относится и к функции Sleep, WaitForSingleObject и другим функциям, работающим с временными интервалами. И вот почему (упрощенно):
1. Существует некий аппаратный таймер, тикающий с частотой 55 мс (10 на NT).
2. Получив прерывание от этого таймера, управление получает планировщик потоков.
3. Планировщик потоков выполняет действия по диспетчеризации потоков. Например, если истек квант выполняющегося потока, планировщик передает управление другому. Если один из потоков вызвал Sleep, тем самым исключив себя из числа планируемых на определенный период, то планировщик уменьшает время ожидания, и если оно истекло - снова ставит поток в очередь планируемых. И наконец, если поток установил таймер, также проверяет, истек ли его период, и если да - генерирует сообщение WM_TIMER. Так как планировщик получает управление не чаще чем 55 (10) мс, то он не сможет соблюсти меньший период для таймеров.
4. Очевидно, что сообщение WM_TIMER кладется в очередь не чаще чем 55 (10) мс. Но и это не есть точное время срабатывания таймера. Сообщение будет обработано не сразу, а с некоторой задержкой во-первых потому, что положить сообщение в очередь - не есть сразу его обработать. Оно будет обработано лишь тогда, когда поток вызовет GetMessage или PeekMessage (а ведь в этот момент поток может быть занят чем-то другим или вообще квант будет принадлежать не ему) и направит его оконной функции. Более того, сообщение WM_TIMER имеет самый низкий приоритет (обрабатывается в последнюю очередь, если в очереди сообщений имеются другие) а также, если в очереди уже лежит WM_TIMER, новое сообщение не кладется.

Из этого всего вывод, что юзер-таймеры Windows не обеспечивают точный период срабатывания, и погрешность тем больше, чем меньше период и чем выше нагрузка на процессор.

Как насчет замедления системного таймера в Винде

Считайте что никак. Во-первых, прямого доступа к портам таймера (в прочем, как и к любым другим) в 3-м кольце нет, без драйвера тут не отделаешься. Во-вторых, это может привести если не к краху системы, то точно к ее нестабильной работе. Дело в том, что тот самый планировщик как раз получает управление по прерыванию от системного таймера (которой как раз на 10 мс и запрограммирован). Так вот, уменьшив этот период, мы изменим квант выделяющийся потокам, у них останется меньше времени на работу, так как очень часто будет вклиниваться планировщик. За последствия - не ручаюсь

PS: А что вы с такой частотой слать хотите и на какой порт, коли не секрет?

[chingiz]

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

Притом у Вас уже есть прога которая работает хорошо из доса, к черту интерфейс, главное - результат.

Так то оно так но все таки хотелось бы под винду. К томуже в старой проге надо кое чего добавить, а если исходники не найду, то все с нуля но уже для ДОСа.

[Ins]

chingiz, а что вы хотели? Система реального времени и многозадачность - это две вещи взаимно исключающие друг друга. Либо у нас много задач, между которыми нужно делить процессорное время, либо у нас одна но очень важная задача, у которой никто процессорное время отнять не может и она будет делать что хочет и когда захочет, никто ее не прервет.

[SunKnight]

CHINGIZ, я живу в городе машиностроителей и немного знаю обо всей этой каше. Для управления на заводах станками используют не проги из под винды (это просто смешто). Я приведу свои аргументы против:
- у тя нет проги под винду
- если захочеш запатентовать или продать проэкт, прийдется повозится с лицензией винды
- многозадачность винды проявляется в том что она выполняет задачу и в это же время тупит

P.S. под ДОС прогу интерфейс "забацать" тоже можно

[chingiz]

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

chingiz, а что вы хотели? Система реального времени и многозадачность - это две вещи взаимно исключающие друг друга. Либо у нас много задач, между которыми нужно делить процессорное время, либо у нас одна но очень важная задача, у которой никто процессорное время отнять не может и она будет делать что хочет и когда захочет, никто ее не прервет.

1) Почему же тогда ДОСовская прога нормально работает под виндой из консоли? Правда не пробовал что будет если паралельно запустить другую задачу.

2) Программа управляет станком с ЧПУ. На данном этапе нужно обеспечить перемещение стола станка с максимальной скоростью 600 мм/мин а это при имеющемся типе двигателя 60000 управляющих импульсов/минуту на управляющую схему привода, или 1000 импульсов в секунду. Все это передается через LPT.