Переустановил Windows, установил драйвер на модуль L-Card 14-440 с родного диска 2005г. Программа, написанная в те годы заработала прекрасно, а PowerGraph 3.3demo, который работал ранее работать отказался - скачал новый версии 3.3.8 и установил. Теперь не работает моя программа - пишет, что не может получить доступ к модулю. Меняю lusbapi.dll на v3.3, скачанную у вас - программа пишет, что неправильная версия dll. Возникает вопрос: "Что, при обновлении драйверов нужно переписывать старые программы?! Или новые нужно писать под старые драйвера?!" Неужели нельзя было оставить поддержку старых версий библиотеки lusbapi?

1. При обновлении только USB драйвера переписывать старые программы не надо.
2. При переходе на новую версию библиотеки Lusbapi может понадобиться пересобрать проект старого приложения.
3. Начиная с версии 3.2 в библиотеке Lusbapi изменился файл USB драйвера. Подробнее смотри п.2.4. "Различия в USB драйверах библиотеки Lusbapi" в руководстве пользователя:
http://www.lcard.ru/download/e14_440_users_guide.pdf

Спасибо за совет. Но здесь проблема в том, что программа написана в Buildere 6.0 а сейчас в 2006-м, а в переходе есть некоторые проблемы. Один раз мне пришлось полностью переделывать интерфейс и связи - трудоемкая процедура.

В смысле-сейчас пишу в 2006-м Buildere.

Необходимость пересобирать приложение с новой DLL связана со способом реализации интерфейса (через класс), т.е. lusbapi.h, с которым собрано приложением, должен соответствовать версии lusbapi.dll. Для этого и рекомендуется делать строгую проверку равенства версии.

Но ничто не мешает прикладывать нужную DLL к своему приложению.

Смена драйвера - тут, конечно, есть неудобство. В принципе можно держать и оба драйвера, например, в зависимости от того, в какой порт включено устройство (если так поставить драйверы). Или даже менять из .bat файла с помощью утилиты devcon (devcon updateni такой-то.inf "USB//VID_0471&PID_такой-то").

Но, может, проще найти, где пересобрать приложение?

Я, собственно, и кладу lusbapi.dll в папку с программой. Только при установке нового драйвера PowerGraphом у меня моя программа стала писать что не может получить доступ к модулю при подключении АЦП к любому разъему кроме одного. Я вначале и не мог понять в чем дело - такого никогда не было. Обнаружил что в оборудовании на этих USB LCARD находится в другом месте. На этом сайте посмотрел что вышла новая библиотека, заменил ей старую и получил сообщение о несоответствии версии. Попробую пересобрать в старой версии. В любом случае спасибо за все предложения. Будут еще - с радостью выслушаю, тем более, что я только начинающий программист на таком уровне.

Еще смущает способ обращения к модулю - посмотрел новое пособие к программированию и смутили изменения.Не знаю - будет ли работать обращение по старому.

Ну все правильно: очевидно, у Вас был на одном из портов установлен старый драйвер.
Отличить, какой стоит драйвер, можно в диспетчере устройств:
Старый драйвер называется ldevusb.sys, а в его inf-файле устройства описаны как "такая-то board" и в дисп.устройств попадают в список USB-контроллеров. Новый драйвер называется ldevusbu.sys (с буквой U в конце), inf-файл создает класс "USB устройства от фирмы L-Card" с иконкой печатной платы (как у сетевых адаптеров) и показывает устройста там.

Поясню еще насчет связи с портом USB. В наших устройствах на уровне USB не прописываются серийные номера, а в windows действует такое правило: если при установке USB-устройства у него нет уникального номера, то драйвер ассоциируется с номером порта, то есть драйвер применяется к  "устройству VID xxxx PID yyyy на USB порту zz".
Они (MS) это сделали намеренно, чтобы при подключении нескольких однотипных устройств их порядок в системе был детерминирован, т.е. чтобы они не менялись местами случайным образом.
Именно поэтому, когда Вы первый раз включаете устройство в другой порт, опять выпрыгивает "обнаружено новое устройство".
Так вот, эту особенность можно при желании хитро использовать, а именно - поставить разные версии драйвера для одного и того же устройства на разных портах. Это не вполне уклюже, но если Вам сильно нужно запускать старые и новые программы попеременно - тоже вариант...

А что вызывает опасения в способе обращения к модулю?

Из истории...

К сожалению, в силу ряда причин, до 2006 года lusbapi работала через //'свой//' драйвер, а PCI и ISA платы через другой драйвер, что приводило к постоянной путанице и нареканиям. В 2006 году мы таки разрубили этот гордиев узел, перейдя на один драйвер (ldevusbu.sys). Извините, что так получилось, но совместимого решения не получилось.

Александру Е.
Совершенно верно - на одном из портов и стоял старый драйвер. Как его менять я разобрался. Спасибо. И выбирать порт для каждой программы-это выход, правда не совсем удобный, но всеже.
По поводу обращения к модулю.
Старая программа написана на основе "скелета" из руководства программиста 2005г. на с.17-19 и примера E14-XXX//E14-440//Examples//BCB5//Synchro с диска к АЦП.
В руководстве 2008г. "скелет" на с.17-18 другой.
Нужно ли изменять этот блок, или будет со старым работать на новом lusbapi?

Владиславу.
И еще в примерах на диске тогда в 2005г. были обнаружены некоторые ошибки, какие - уже не помню, но помню что долго парился. На сайте у Вас даже тогда кто-то ругался на счет некачественного ПО. Как мне сейчас показалось, что ситуация меняется. Спасибо за это.
Тогда мне очень не понравился способ ожидания заполнения половины буфера в программе ReadData:
"// ждем заполнения первой половинки буфера AdcBuffer
while(!BufferHalf) { if(ReadComplete) break; };
BufferHalf = false;"
Уж очень процессор такой способ загружал и в книгах по программированию так делать крайне не рекомендовали. Я переделал с использованием событий - при этом загрузка со 100% упала примерно до 20%.
Сейчас, по-моему, алгоритм в примере изменили. И это действительно радует!

М-м... насчет старого руководства ничего сказать не могу, надеюсь - завтра Сергей посмотрит.

Но в общем случае лучше отталкиваться не от примера, а от описания lusbapi. То, что удовлетворяет описанию, должно работать.

Последовательность вызова управляющих функций от открытия модуля до пуска, по-моему, сильно не менялась (GetModuleName GetModuleDescription STOP_ADC SET_ADC_PARS START_ADC ... STOP_ADC), а что касается самого цикла сбора данных, то можно пользоваться новой функцией ReadData (там другой формат вызова, появилась структура IO_REQUEST_LUSBAPI), а можно, если хочется, вообще системным ReadFile() - только обязательно в режиме OVERLAPPED.

Стандартная схема процесса чтения - поток, в котором крутится цикл с двумя буферами на событиях (один запрос overlapped всегда в очереди): WaitForSingleObject - GetOverlappedResult - ReadFile - смена индекса буфера - WaitForSingleObject...
Сюда добавляются по мере надобности таймауты, события от других потоков (пользователь нажал кнопку Stop в интерфейсе) и т.д.

Загрузка CPU должна быть очень низкая, если только в реальном времени не идет какой-то обсчет собранного сигнала. Практически все время поток сидит в каком-нибудь Wait.

1. По поводу "скелета" программы из руководства...
Существенных изменений в этот "скелет" не вносилось. Просто добавилась чисто информационная функция GetUsbSpeed(), да немного изменились названия некоторых функций.
2. По поводу "долго парился" над ошибками...
В таком случае следовало бы сразу обращаться к нам. На моей памяти не было неразрешимых ситуаций. Если действительно встречались аппаратные глюки  или программные ошибки, то все они благополучно разруливались.
3. По поводу "while(!BufferHalf) { if(ReadComplete) break; };"...
В реальности такая конструкция совсем даже не загружает процессор на 100%, скорее всего Microsoft слегка где-то подвирает. Проверяется это довольно легко. Попробуйте запустить программу ReadData. При этом система в целом вполне адекватно откликается на все Ваши манипуляции с мышью или клавиатурой. А если попробовать реально чем-то загрузить процессор на 100%, то тормоза в общении с системой просто обеспечены.

Сергей: насчет загрузки CPU.
Система с NT ядром отберет таймслайсы у задачи типа
#include <windows.h>
main()
    {
    long t = GetTickCount() + 10000;
    while (GetTickCount() < t);
    }

Но:
1) задачам, у которых меньше приоритет, не поздоровится
2) потребляемая мощность и температура процессора не будет соответствовать европейским экологическим стандартам

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

Сергею.
Хорошая мысля приходит опосля:) На тот момент я стал изучать работу с API функциями windows и потоками, a "парился" по неопытности. Потом все получилось. На счет загрузки процессора: дело в том что в программе несколько потоков. Один из них анализирует поступающие данные и дает сигнал на прерывание сбора при появлении полезного сигнала. Думаю что именно поэтому загрузка процессора около 20% при использовании событий. А в варианте с циклом, о котором я говорил, загрузка достигала 100% при этом Сeleron 2000 очень часто пропускал полезный сигнал, по крайней мере гораздо чаще, чем Athlon64 3000. Чтобы не использовать анализ в первых версиях программы был организован запуск по уровню, но при этом терялась часть полезного сигнала.

Александру Е.
Думаю что потоку анализа данных в программе и не поздоровилось.
Я пробовал организовывать потоки в самом С++ Builder, но через API работает лучше - меньше потерь полезного сигнала.
На счет иллюстрации может Вы и правы, хотя, мне кажется, что в примере лучше показывать как делать корректнее или хотя бы делать оговорки. Но всякое бывает. Главное что ошибки исправляются и коды совершенствуются!

И еще: в очередной раз спасибо поддержку.

На здоровье!

Потоки Builder по идее не должны существенно отличаться, потому что их C++ная обертка наверняка в итоге вызывает те же функции API (а как еще создать поток?).
Свойство Terminated неудобное, не дает возможности прервать какую-нибудь длинную операцию с ожиданием. Бывает удобнее сделать свой собственный hTerminateEvent = CreateEvenr()...

И раз уж о них зашла речь о TThread, там есть одна штука, которую я в свое время понял не сразу.
Когда пишете класс-потомок TThread, в конструктор базового класса опасно передавать CreateSuspended = false, т.к. он запустит поток сразу, раньше, чем выполнится констркутор класса-наследника.
То есть, например:
TMyThread::TMyThread(bool CreateSuspended) : TThread(true)
{
/* инициализация, которая должна предшествовать запуску Execute() */
if (!CreateSuspended) Resume();
}

И еще - потокам можно раздавать разные приоритеты внутри процесса.

Вероятно вызывает. Но почему-то мне показалось напрямую через API работать удобнее. Может быть билдеровский интерпретатор часть процессорного времени берет на себя. К сожалению я уже не помню что у меня не заладилось с классом TThread, но помню что что-то было не так. А поток я, пробовал создавать по-разному, в том числе и спящим, но спасибо за подсказку.
Кстати, через API по указанной Вами причине я потоки создавл именно спящими и запускал когда нужно.
По поводу приоритетов - я довольно долго выбирал приоритеты, добиваясь наилучшей стабильности. Получилось, что потоку получения данных из АЦП дал приоритет "THREAD_PRIORITY_NORMAL", а потоку который с этими данными работает - "THREAD_PRIORITY_TIME_CRITICAL". Только в этом случае получилась более-менее стабильная работа.