Функция LTR51_Stop работает очень медленно при остановленном сборе данных. Можно ли это исправить - "ускорить" выполнение этой функции, если сбор уже остановлен?

Вы можете определить остановлен сбор или нет? если можете, то просто не запускайте Stop в случае когда сбор уже остановлен.
   Комманда стоп посылает запрос и ждет ответ. Соответственно она заканчивает работу или когда ответ приходит, или по таймауту. Когда сбор данных не запущен процедура выходит по таймауту.
   В библиотеке установлен таймаут 6000мс, Можете поменять его, если хотите. Исходники библиотеки есть на диске.

1. В том то и дело, что определить состяние LTR51 (запущен или остановлен) средствами ltr51api.dll невозможно. Поэтому предполагается предварительно использовать LTR51_Stop, чтобы иметь гарантированное состояние остановки перед изменением настроек и последующим запуском. Конечно это не критично и "избыточные" LTR51_Stop можно убрать, но тогда возникает следующий вопрос - что произойдет, если при запущенном сборе данных вызывается LTR51_Config?:
1) функция не выполнится и вернет ошибку;
2) новые параметры установятся, сбор данных будет остановлен или продолжится?

Точно такая же проблема с длительной остановкой сбора данных была у LTR212 и ее совершенно логично исправили без какой-либо доплаты:
http://www.lcard.ru/forumthreads/4041 

Еще несколько вопросов:
2. В функцию LTR51_ProcessData можно передавать только TbaseQnt кадров исходных данных или любое количество, кратное TbaseQnt? Другими словами LTR51_ProcessData обрабатывает только один цикл времени счета или может сразу обработать несколько циклов - N * TbaseQnt?

3. LTR51 высылает данных сразу для всех 16 каналов, но таблица логических каналов LChTbl может быть меньше 16. Вопрос: какие параметры (диапазон порогов, значения порогов, тип перепада) используются для каналов не указанных в таблице логических каналов? Или эти каналы не опрашиваются?

Дополнительно для обсуждения (может будет полезно):
4. Непонятно почему время счета AcqTime имеет тип INT, а не double, как другие значения частоты или времени? Время счета в целых значениях миллисекунд накладывает ограничения на возможные значения BASE. Например, при Fs=500 кГц и BASE=16384 период измерения составит 16384/500 = 32.768 мс, т.е. никакое целое TbaseQnt уже не даст целое число миллисекунд (INT). Хотя BASE и может принимать любые значения от 70 до 65535, но для установки времени счета в единицах миллисекунд период измерения тоже должен быть кратен миллисекунде, т.е. для Fs=500 кГц BASE должно быть кратно 500.
В конечном итоге AcqTime вторично по отношению к TbaseQnt, т.е. должно принимать любые значения TbaseQnt*BASE/Fs, а для этого нужен double.
Конечно это тоже не критично, ltr51api.dll "подправит" значение AcqTime до целого числа миллисекунд, но будет ли это соответствовать условиям решаемой задачи? Получается, что весьма гибкие настройки ограничены типом входного параметра.

1) Щас сделаю чтобы на команду STOP, в случае запущенного сбора ответ шел быстрее. Как сделаю пришлю на ящик, отправьте мне пустое письмо пожалуйста, чтобы я знал куда отвечать.
2) В описании указано, что процедура ProcessData обработает все данные, и осреднит по всем кадрам. Это-же видно из примера с Диска, там ведется сбор данных 5 сек, а потом процедура ProcessData подсчитывает среднюю частоту за весь период времени в указанных логических каналах.
3) Значения порогов по умолчанию +/-0.497V для диапазона +/-1.2В и  +/-4.1393 . Вообще настройки остаются те, которые были последний раз установлены, однако каналы, не описанные в структуре логических каналов отбросяться автоматически процедурой ProcessData.
4) Да, тип Float, возможно, был-бы тут более уместный, ну так уж исторически сложилось. В принципе чтобы получить заданное время сбора более точно можно подобрать FS и BASE так, чтобы FS делился на BASE  с минимальным остатком. Боюсь сейчас будет непросто заменить Тип INT на Float так чтобы не повредить тем кто уже написал свои программы под INT. Я подумаю как можно сделать это корректно.

1) Это не срочно. Если сделаете, положите в библиотеку файлов или на FTP.
Подразумавалось, что STOP будет работать быстрее в случае остановленного (а не запущенного) сбора.

2) т.е. ProcessData никак не учитывает TbaseQnt и возвращает только одно значение Frequency для каждого логического канала?
В описании и примерах рассматривается только частный случай, когда получение данных и обработка осуществляются одинаковыми порциями по TbaseQnt кадров. Однако с помощью Recv может быть получено любое количество кадров, например 10*TbaseQnt, но о том, что в ProcessData можно передавать только TbaseQnt кадров негде не сказано. Цитата:
"В любом случае, при задании входного значения параметра size следует помнить, что оно должно быть кратно 32!"
Отсюда не следует, что значение size должно быть ВСЕГДА фиксированным - 32*TbaseQnt.
Фразы о том, что "осреднит по всем кадрам" в описании ProcessData нет, однако подразумевается, что осреднение осуществляется по TbaseQnt кадрам, т.е. при передаче в функцию N*TbaseQnt кадров должно получиться N средних значений.

4) Конечно я не предлагал изменять тип данных (нарушение совместимости гораздо хуже, чем эти мелкие ограничения), просто информация для размышления.
Впрочем, ничего не меняя в структуре можно исправить ситуацию следующим образом - в LTR51_Config использовать TbaseQnt как входной параметр, если AcqTime равно 0. Тогда можно будет задавать время счета и через целые миллисекудны (установка AcqTime) и через количество периодов измерения (установка TbaseQnt и обнуление AcqTime).

1)Нашел в чем дело, если не срочно то со следующей сборкой библиотек будет все быстро, но могу и послать ее вам. Теперь никакой лишней задержки небудет.
2)Важно только чтобы их было кратно 32. ProcessDATA посчитает значения частот по тем данным, которые вы ей дадите, вы можете вполне разбивать принятые данные на несколько кусков, чтобы получить несколько значений частоты на канал для установленного времени измерения.
4)Да, это очень красиво смотриться, я добавлю это как режим при SetUserPars=2, Тогда установленный зарание FS, Base, и TBaseQnt будут определять AsqTime, значение которого будет вычисляться в LTR51_Config. Тогда с новой сборкой всё это будет доступно.

1) и 4) Спасибо, будем ждать очередной сборки. Не подскажите когда она появится, хотя бы ориентировочно?

2) Если в ProcessDATA можно передавать любое количество значений, кратное 32, то возникает вопрос по поводу выходного массива dest[] с коэффициентами N и M. Цитата:
"Количество кадров в массиве dest[] будет соответствовать количеству периодов измерения в требуемом времени счета, т.е. значению поля TbaseQnt структуры описания модуля. А общее количество элементов этого массива будет равно произведению TbaseQnt*LChQnt."
В последней фразе утверждается, что ProcessData вернет только TbaseQnt кадров логических каналов. А если в функцию передать больше, чем TbaseQnt кадров исходных данных, например 10*TbaseQnt, функция все равно вернет только 1*TbaseQnt кадров N и M? А куда денутся остальные 9*TbaseQnt кадров N и M?

1) Нужно будет поправить описание, и протестировать все тщательно, некоторое время это займет, точнее сказать не могу.
2) Логика работы процедуры подразумевает что вы будете обрабатывать порции данных полученные за один раз, с настройками, установленными на момент запуска сбора данных. Как можно получить больше данных?
Если просто повторить полученные данные, то процедура вернет ошибку - не совпадут внутренние счетчики в данных.
А если принять данные два раза, и передать их в процедуру с увеличенным в два раза параметром Size, то и данных в массиве data будет в два раза больше, А частота посчитается по всем данным.

2) Вообще-то LTR51_Recv, а точнее LTR_Recv, не накладывает никаких ограничений на количество запрашиваемых данных. Ведь LTR-Server'у безразлично сколько данных отправлять клиенту? Вы предлагаете запрашивать только TbaseQnt кадров, но это Ваша логика. А может быть и другая логика, например при времени счета 2 мс (что в принципе возможно) "дергать" LTR51_Recv каждые 2 мс нерационально - логичнее считывать данные большими кусками, а затем обрабатывать. Вопрос был только в том как можно обрабатывать - целиком или только кусками по TbaseQnt кадров.

В общем продолжать обсуждение думаю не стоит.
Если под массивом "data" Вы подразумеваете dest (в описании ProcessData нет аргумента "data"), то в описании присутствует неточность относительно размера выходного массива dest[] - указано только TbaseQnt*LChQnt, а может быть также кратно этому количеству.