Realtime драйвер под Windows для ПАУК-4x

[x4axis]

Есть программа ПАУК-4х(www.x4axis.com) для управления ЧПУ через lpt порт очень хотелось бы сделать в ней настоящий реалтайм . На сегодня программа не имеет нормального драйвера и рассчитывает интервалы между импульсами меряя тики(QueryPerformanceCounter) процессора и все это в цикле... в отдельном потоке программы... но в общем реализовано жутко и работает это на троечку.
Требуется написать драйвер, который будет получать пару: байт-задержка|байт-данных. В состоянии обеспечить выдачу байта-данных в LPT порт с частотой 100Кгц. У кого есть опыт и желание в написании реалтайм драйверов под Windows?
Приглашаю к разговору.

[raxp]

Realtime драйвер под Windows

Не всякий Windows годится, да и не в драйвере дело. Раз вы не в теме, процитирую RTAPI:

Возможность использования Windows NT в качестве ОС реального времени

В последнее время приобретают популярность расширения реального времени для Windows NT. Это обусловлено, с одной стороны, расширением областей применения компьютерного управления, с другой стороны - сравнительно малой известностью и высокой стоимостью специализированных операционных систем реального времени. Интерфейс Win32 является стандартным и хорошо знакомым большому числу программистов. Под NT существует огромное число готовых приложений (в том числе коммуникационных), а также популярные средства разработки. К сожалению, Windows NT "в чистом виде" нельзя отнести к операционным системам реального времени. Обсуждению причин этого посвящены статьи Martin Timmerman и Jean-Christophe Monfret в Real-Time Magazine Q21997. Вот некоторые из них: недостаточное количество real-time приоритетов, отсутствие наследования приоритетов, как средства борьбы с инверсией приоритетов, неподходящая для RTOS система обработки прерываний.

В Windows NT доступ к прерываниям осуществляется из драйвера ядра, а сами прерывания обрабатываются в два этапа: сначала вызывается очень короткая Interrupt Service Routine (ISR), осуществляющая критическую обработку, основная обработка прерывания происходит в Deferred Procedure Call (DPC). Все DPC выполняются с одинаковым уровнем приоритета в порядке поступления (FIFO). Таким образом, время окончания обработки вашей DPC оказывается зависимым непредсказуемым образом от наличия в системе других драйверов и их активности. Для систем с жестким детерминизмом необходимо точно знать максимальное время от момента возникновения прерывания до входа в процедуру обработки и гарантировать его непревышение.

RTX - real-time extension для Windows NT от компании VenturCom

Одним из возможных решений - является использование совместно с Windows NT подсистемы реального времени, исполняющейся на том же процессоре (если процессор один) или на выделенном процессоре(-ах) (если их несколько). Этот подход использован фирмой VenturCom в продукте RTX (Real Time Extension). Сущность подхода заключается в использовании модифицированного HAL (Hardware Abstraction Level). Изменять kernel Microsoft не разрешает, а исходный код HAL предоставляет своим партнерам, одним из которых является VenturCom. После установки RTX стандартная NT Workstation или Server превращается в операционную систему реального времени с жестким детерминизмом (hard real-time). Сама NT об этом, правда, не подозревает. Ни ядро, ни исполняющая подсистема NT не были изменены. Подсистема реального времени видна из Windows NT, как еще один драйвер устройства. Схема функционирования RTX в составе Windows NT представлена на рисунке... http://www.osp.ru/print_text.php?typ...d=179403&isPdf

В системе появляется планировщик задач реального времени. Новый HAL по прерыванию от часов реального времени передает управление этому планировщику, который следит за очередью задач реального времени, находящихся в системе и выделяет им время в соответствии с приоритетом. В RTX существует 128 фиксированных приоритетов для задач реального времени. Если в очереди таких задач нет, то управление передается стандартному планировщику NT. При этом времена исполнения кодов модифицированного и оригинального HAL совпадают, т.е. присутствие RTX не сказывается на производительности Windows в отсутствие real-time процессов. Однако, если real-time процессы будут занимать все процессорное время, то Windows NT не получит управления и окажется подвешенной. В принципе, если данная ситуация не входит в планы разработчика, ее можно предупредить, установив в опциях настройки RTX "сторожевой" таймер, срабатывающий, если один поток занимает CPU больше определенного времени.

Все программы, исполнявшиеся на машине до установки RTX, будут по-прежнему на ней исполняться, но, к сожалению, не в real-time режиме. Такие программы нужно писать и компилировать самому с помощью поставляемых VenturCom библиотек, содержащих функции Real-Time API (RTAPI).

Создание приложений реального времени с помощью RTAPI

Одним из преимуществ RTX, является возможность использования стандартных компиляторов для создания real-time программ и стандартного софта (commercial off the shelf, COTS), взаимодействующего с ними и работающего на той же машине. Действительно, для создания real-time программ Вы можете использовать Visual C++ 4.2 или 5.0. Кроме того, при создании Win32- приложения можно использовать любой компилятор, понимающий вызовы функций Win32 API (например C++ Builder). Один и тот же код можно откомпилировать как Win32 и как RTSS приложение с расширениями .exe и .rtss соответственно. Exe-вариант программы является приложением "мягкого" реального времени.

[raxp]

не влезло...

Функции, входящие в RTAPI на данный момент, можно разделить на 4 группы. К первой относятся функции, чья семантика и/или поведение отличается от функций Win32 API. В названии всех функций этой группы присутствует префикс Rt (например RtAttachInterruptVector) Во вторую входят функции, чья семантика и функциональность совпадают с функциями из Win32 API, но они работают в RTSS подсистеме. В третью группу входят функции runtime C библиотеки. К последней (но не по важности) группе относятся функции т.н. Windows NT Driver IPC API, позволяющие rtss и Win32 потокам взаимодействовать с обычными драйверами, работающими в режиме ядра.

Программы, скомпилированные как rtss, могут содержать только функции, входящие в RTAPI, На программы,скомпилированные как exe, такое ограничение не распространяется.

Разработку любого RTSS приложения удобно начинать с exe-варианта. Это позволяет использовать отладочные средства Visual Studio (или другого используемого компилятора). Например, если Вы пишете rtss-драйвер, обслуживающий прерывания, то скомпилировав его как Win32 программу, можно установить точку останова в процедуре обработки прерывания (в RTX обработка прерываний не разделяется на ISR и DPC, а выполняется одним потоком (см. ниже)) и сделать пошаговый прогон всей процедуры. Программы, скомпилированные как rtss, при необходимости отлаживаются с помощью WinDBG (на двух компьютерах) или SoftIce (на одном компьютере).

Обычно (хотя и не обязательно) приложение состоит минимум из двух частей - real-time процесса, исполняющегося в RTSS подсистеме и исполняющего критическую по времени работу и exe-процесса, исполняющегося в Win32, взаимодействующего с rtss-частью с помощью средств межпроцессного взаимодействия. Exe-часть может взаимодействовать с сервисами NT, другими программами, пользователем.

RTX Beginner search for example in Delphi

А теперь вернемся к нашим баранам, 100 кГц = 10 мкс, недостижимо без ухищрений:
1- QueryPerformanceCounter, как уже сказано, привязка к тикам процессора, единоразова выставленное время будет работать исключительно на той машине на которой это выставлено и как правильно отметил автор - ничего лишнего ...да и плавать будет
2- мультимедийный таймер тоже мало поможет для таких скоростей на LPT
3- что забыл автор того материала, так это об емкостях на пинах LPT ...для этих скоростей и управления шаговым их обычно выпаивают, чтобы фронты не затягивали
4- драйвер вам не нужен, достаточно использовать любой, работающий из третьего кольца для NT и выше - giveo.sys, inpout32/64
5- тема для вашего развития по управлению шаговиком http://programmersforum.ru/showthread.php?t=73294.

p.s.: следует оговорить, что для серъезных задач и больших скоростей, управление и контроль шаговиком станка реализуют на железной логике, которая способна справиться в REALTIME, а уже задачу скидывают по LPT. Однако, есть и промышленные решения управления по USB, контроллер тут будет в любом случае. Есть модификации по RS-485.

Добавлено

...любителям выжимания скоростей от LPT внимательно ознакомиться http://programmersforum.ru/showpost....12&postcount=7.

[DiemonStar]

100кГц на LPT - это из области фантастики) очень сильно сомневаюсь, что периферийный контроллер столько вытянет.

[x4axis]

raxp - огромное спасибо. Основательно и качественно ответил.

А теперь вернемся к нашим баранам, 100 кГц = 10 мкс, недостижимо без ухищрений:
1- QueryPerformanceCounter, как уже сказано, привязка к тикам процессора, единоразова выставленное время будет работать исключительно на той машине на которой это выставлено и как правильно отметил автор - ничего лишнего ...да и плавать будет
2- мультимедийный таймер тоже мало поможет для таких скоростей на LPT
3- что забыл автор того материала, так это об емкостях на пинах LPT ...для этих скоростей и управления шаговым их обычно выпаивают, чтобы фронты не затягивали
4- драйвер вам не нужен, достаточно использовать любой, работающий из третьего кольца для NT и выше - giveo.sys, inpout32/64
5- тема для вашего развития по управлению шаговиком http://programmersforum.ru/showthread.php?t=73294.

1.QueryPerformanceCounter -это самое работоспособное, все варианты из п.5 давно были проверены и отброшены в мусорный ящик.
3.при скорости 100кГц выпаивать кондеры не следует, выпаивать надо если скорости в 4-5 раз выше.
4.Через giveo.sys открываю себе прямой доступ к портам. А далее только "интимное" общение через _outp(BASA_LPT,data), ближе и быстрее некуда

Расширяю информацию.
У меня все работает через внешний контроллер(буфер на 16К памяти). Все замечательно пашет на 166 пентиуме и еще можно в текстовом редакторе параллельно сидеть. В прошлом году (11 августа) в интернет выложил версию, которая работает без буфера. Соответственно пришлось "засовывать" модуль расчета временных интервалов прямо в ПАУК-4х, в поток общих расчетов. За год он претерпел несколько изменений, но дальше я уже в тупике, выжал все что можно. Вот и подумал, может найдется "гуру", который поможет написать драйвер. Просто подумал, что для современных процов 100кГц - это не накладно. Но ведь MACH3(американский "аналог") работает. При том на достаточно дохлых кампах.
raxp - ты в драйверах разбираешься? просто я ноль в них.

[waleri]

Несколько старая статья, но может будет интересно почитать:
http://msdn.microsoft.com/en-us/magazine/cc163996.aspx

[raxp]

3.при скорости 100кГц выпаивать кондеры не следует, выпаивать надо если скорости в 4-5 раз выше.

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

Просто подумал, что для современных процов 100кГц - это не накладно

вы путаете, не для процов накладно, а для LPT-интерфейса. Хотите скоростей - переходите на PCI/USB (впрочем сам USB через PCI работает).

...в драйверах разбираешься?

повторяю еще раз, не в драйвере дело. Не поможет в данном случае драйвер. Читайте выше про RTAPI.

MACH3(американский "аналог") работает. При том на достаточно дохлых кампах.

это ПО для управления контроллером станка, тут и не нужен крутой ПК. Контроллер в станке уже есть. Мало того, для обмена вообще используется ActiveX- компонент, не обладающий сам по себе высокой реакцией (реализовано видимо для закрытости решения). Кол-во обращений ПО к контроллеру максимум 45 000. И опять же, для каждой машины перед каждым запуском требуется калибровка с привязкой к тикам процессора. Навряд-ли это можно считать хорошим и надежным решением.

И заметьте, из описания:

На такой скорости электронике микрошагового привода двигателя требуется 16,666 (500*200*10/60) импульсов в секунду. На компьютере с частотой 1 ГГц, Mach3 может генерировать одновременно по 35,000 импульсов в секунду для каждой из 6 возможных осей.

1- 1 гигагерц совсем не старая машина
2- 35 кГц для каждой из осей, это означает что эти 35000 импульсов не складываются, они просто идут с такой частотой по DATA пинам: D0...D7.

Руководство по MACH3 (18 МВ)

[Пепел Феникса]

Но ведь MACH3(американский "аналог") работает.

я не думаю что мой станок(лазерной резки металла) просто так(от скуки) не напрямую от компа управляеться, а у него свои контроллеры, которые получают данные от компа.

MACH3 помоему так же получает команды лишь, а не напрямую контроль?
(у нас похожую плазму увезли, не могу посмотреть уже)

[x4axis]

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

12 лет работает без сбоев, правда кабель не более 1,5метра.

вы путаете, не для процов накладно, а для LPT-интерфейса.

Тут дока на LPT они даже больше 1MHz могут вытягивать.
И вообще мы не туда полезли. У МАСH3 есть режим step/dir на канал, я реализовал точно такой же.
Думал, может кто-то подскажет простое решение.

[raxp]

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

12 лет работает без сбоев, правда кабель не более 1,5метра.

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

. в отдельном потоке программы... но в общем реализовано жутко и работает это на троечку.

вам в общем-то повезло с материнкой. Как правило, приходится выпаивать для старого хлама.

Тут дока на LPT они даже больше 1MHz могут вытягивать.

ранее вам уже давал ссылку на этот пост http://programmersforum.ru/showpost....12&postcount=7, там указано максимальное значение скорости для LPT в режиме EPP из даташита. Будьте внимательны.

У МАСH3 есть режим step/dir на канал

на один DATA пин и 35 кГц.

Думал, может кто-то подскажет простое решение.

обычное бытовое железо (не промышленный ПК) и Windows - не решение для прямого управления промышленным дорогущим станком, от работы которого зависит жизнь работника за ним и экономические затраты на него, как то инструмент, привод и т.п. Это не просто так делается на железных тупых микросхемах.