Работаем с LTR212. Возникли следующие вопросы и проблемы:
1. Постоянно при вызове LTR212_Start  после нескольких успешных запусков возникает ошибка "Невозможно выполнить сброс AD7730". После этого устройство отказывается работать. С чем это связано и как с этим бороться?
2. Функция LTR212_Stop работает очень долго - несколько секунд. С чем это связано и можно ли это исправить?
3. Возможно ли в LTR212 добавить функцию чтения единичного значения с указанного канала, типа LTR212_GetSample, как это принято у Вас для других устройств? 
4. В USB модулях E-xxx минимальное количество передаваемых значений ограничено минимальным размером блока, передаваемого по USB (64 - для USB 1.1). Как удалось преодолеть эту проблему в крейте LTR, который может передавать данные и меньшими порциями?

>>4. В USB модулях E-xxx минимальное количество передаваемых значений ограничено минимальным размером блока, передаваемого по USB (64 - для USB 1.1). Как удалось преодолеть эту проблему в крейте LTR, который может передавать данные и меньшими порциями?

Аппаратно LTR сделан по другим принципам.

На вопросы по LTR212.
1. Скачайте, пожалуйста, с нашего сайта новые версии библиотеки ltr212api.dll и БИОСа ltr212.bio. Скорее всего, после обновления ошибки появляться не будут. Скачивать лучше в понедельник, т.к. сегодня будут внесены самые последние изменения в библиотеки.
2. Функция LTR212_Stop() выполнялась долго,т.к. она откачивала данные, накопившиеся в буфере до аппаратной остановки модуля. Сейчас это выполнено более оптимальным способом, и функция LTR212_Stop() завершается очень быстро. Таким образом, решение проблемы опять же в обновлении библиотеки.
3. Теоретически функция получения одного сэмпла возможна (при, конечно, отключенных программных фильтрах). Если это действительно нужно, то  можно попытаться реализовать.   
P.S. В новой версии ПО произведены некоторые изменения, несовместимые со старыми версиями. Это сделано с целью унификации интерфейса программиста при работе с библиотеками разных модулей. Пожалуйста, скачайте Руководство программиста по модулю LTR212, чтобы произвести необходимые незначительные изменения в Вашем пользовательском ПО в соответствии с новой библиотекой.

1-2. Спасибо, в понедельник скачаем и проверим.
3. Практически у всех ваших устройств есть режим одиночного измерения по запросу, поэтому в нашем ПО используется и непрерывная многоканальная регистрация, и единичиные асинхронные запросы. При отсутсвтии единичных асинхронных измерний некоторые части программы не будут работать, а насколько это действительно нужно будут решать конечные пользователи. В качестве пожелания, конечно хотелось чтобы такой режим был (с целью унификации работы с устройствами вашего производства).
P.S. Если возможно, укажите пожалуйста конкретнее какие сделаны изменения несовместимые со старыми версиями. Очень не хочется долго выискивать в двух документах различия в тексте.

5. Возможно ли добавить 4-х канальные режимы для старших каналов 5-8? Если нужны только эти каналы, то переключать входы АЦП нет необходимости, но пока получается что эти каналы ущербные и могут быть использованы только в 8-канальном режиме c "плавающей" частотой.
По логике работы LTR212 8-канальный режим необходимо включать когда тольеко когда наблюдаются "совпадающие" каналы 1+5, 2+6, 3+7, 4+8. Если этого нет, то вполне можно было бы использовать полноценный 4-канальный режим, например для следующего набора каналов - 1,3,6,8.

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

Изменения, несовместимые со старой версией:
1). Тип данных для структуры описания модуля теперь именуется не descr_ltr212, а TLTR212. Из этой структуры исключена подструктура ID_Record. Вместо этого определяется тип данных TINFO_LTR212 (структура), а поле ModuleInfo этого типа вводится в структуру описания модуля TLTR212. Таким образом, теперь вместо hnd.ID_Record.Serial будет hnd.ModuleInfo.Serial; вместо hnd.ID_Record.ModuleName будет hnd.ModuleInfo.Name и т.д. Аналогичные изменения внесены и во все другие LTR-модули. Например, для LTR11 вместо descr_ltr11 определен тип TLTR11. В этой структуре также имеется поле ModuleInfo типа TINFO_LTR11. И так же для всех остальных модулей.

  2). Посадочное место модуля в крейте нумеруется С ЕДИНИЦЫ. Т.е. параметр slot_num в функции LTR212_Open() может принимать значения 1-16, а не 0-15, как это было ранее. То же для все остальных модулей.
  3). В функциях LTR212_Recv() и LTR212_ProcessData() параметр *size имеет тип указатель на DWORD, а не на INT, как было ранее.

  Модуль LTR212 разрабатывался по принципу преемственности по отношению к LC212. Чтобы пользователям, работавшим ранее с LC212, было удобнее переходить к использованию нового устройства, в LTR212 сохранены те же 3 режима сбора данных с той же конфигурацией каналов, как это было в LC212.

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

Этот вопрос также связан с 5-м пунктом. Для единичных асинхронных измерений не нужны фильтры и высокая точность, поэтому подошел бы режим средней точности на максимальной частоте. Но старшие каналы при потоковом сборе можно использовать только в 8-канальном режиме на минимальной частоте, хотя нужно всего лишь быстро получить одно значение одного канала, например для проверки.

6. Возник вопрос монопольного доступа к модулю крейта. Сейчас две программы могут одновременно открыть один и тот же модуль и соответственно будут мешать друг другу работать. Планируются ли какие-то изменения в библиотеках с вашей стороны для предотвращения подобных ситуаций. Хотя бы, чтобы LTR Server сообщал, что модуль занят другой программой.

>>...нагрузка на канал будет существенно меньше, что позволит повысить надежнсть всей системы.
Дмитрий. Эта мысль непонятна.

>>...Легче Вам один раз реализовать асинхронные единичные измерения в самом устройстве
"Легче" -- это спорно. Реализовали б обязательно, но смысла в этом не видно... А то, что это просто реализуется на верхнем уровне -- это факт.

>>Для единичных асинхронных измерений не нужны фильтры и высокая точность...
Разве такое можно утвержать в общем случае?

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

Александру М.
Спасибо за конкретику. Если последняя часть вашего ответа относится вопросу о записи старших каналов в 4-х канальном режиме, то это не противоречит существующим режимам LTR212. Отличия только в том, что модуль позволит использовать старшие каналы в 4-х канальном режиме если они не перекрываются с младшими. Совместимость с LC212 при этом не нарушается.

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

Я говорил не об общем случае, а о конретном с LTR212. Для асинхронного единичного измерения важна скорость ответа от устройства, чтобы использовать эту возможность вызовом одной функции в основном потоке программы. Если такая функция будет работать медленно, то и сама программа будет тормозть. В случае LTR212 максимальной скорости можно добиться в 4-канальном режиме "невысокой" (средней) точности без фильтров. Применимость аппаратных и программных фильтров при асинхронном чтении единичных значений сомнительна.
В общем случае для высокоточных измерений конечно используется потоковый сбор, а асинхронные единичные измерения для отладки, проверки подключения датчиков и т.п.

Думаю не имеет смысла дальше рассматривать этот вопрос, это было пожелание, а его реализация остается на ваше усмотрение.

Остался вопрос о возможности записи старших каналов во всех режимах.

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

Если организовывать потоки, то функцию обработки потока все равно придется писать пользоватлю (кто - то захочет обрабатывать данные после приема прямо в потоке и отображать, а кому - то захочется иметь только мгновенные значения для передачи в другие функции или записывать в файл).
В Dll фактически будет упакована в функцию только CreateThread, что пользователь может и без проблем сам написать.
Нагрузка на систему при небольшом потоке данных вообще не заметна, поскольку используются overlapped запросы.

Если время сбора не критично, то можно использовать Старт - Стоп режим и без дополнительного потока.

В вашем же варианте наиболее подходит создание потока, который будет только заниматся приемом данных и обновлять либо поле мгновенного значения, или массив.
Основная же программа будет заниматся только отображением или обработкой этого поля, в таком случае она тормозить не будет вообще. Нагрузка на систему при небольших скоростях LTR212 может выражатся только в дополнительном объеме памяти под поток.

Над возможностью работы с остальными каналами в 4-канальном режиме мы подумаем. Возможно, это будет реализовано в следующей версии БИОСа.

Дмитрий.
В любом случае за пожелания спасибо. Все пожелания внимательно рассматриваются.
По поводу единичного опроса.
LTR оптимизирован под потоковую идеологию сбора данных -- это значит, что если Вам оперативно нужно получить данные (одиночные сэмплы или группу), то быстрее чем через заранее запущенный потоковый сбор, этого всё равно не сделать. Это непосредственно следует из описания архитектуры LTR. Если оперативность не требуется
(или нужно сильно экономить трафик, например при работе через USB1.1), то можно просто через СТАРТ-СТОП. В этой связи полностью пропадает смысл в отдельной аппаратной реализации на низком уровне механизма единичных асинхронных измерений (это будет по сути тот же СТАРТ-СТОП).

Списибо, Ваша позиция по этому вопросу понятна. Едем дальше.
Загрузили и проверили новые Dll:
1. Ошибка "Невозможно выполнить сброс AD7730" больше не появляется.
2. Функция LTR212_Stop работает быстро если ей предшествует LTR212_Start. Если сбор в модуле уже остановлен, то функция LTR212_Stop работает также долго, вероятно ждет данные от модуля, хотя вероятно можно сразу же вернуть ошибку. Сейчас нет возможности определить состояние модуля - работает или остановлен.

7. Добавьте пожалуйста в библиотеку возможность загрузки БИОСа по умолчанию, как это сделано в lusbapi для E-440. При передаче в LTR212_Open вместо имени файла NULL, библиотека будет загружать БИОС из собственного ресурса. Очень удобно и позволит избежать несовместимости БИОСа и библиотеки, если такое вдруг в дальнейшем возникнет.
Также можно было бы поступить и с фильтрами - если не полные путь и имя файла, то имя ресурса, содержащего тот же файл фильтра.

В ближайшее время выложим новые версии с учетом Ваших последних замечаний (касательно функции LTR212_Stop() при остановленном модуле и ресурса с БИОСом).

Еще один вопросик общего характера, возникший при реализации асинхронного единичного измерения потоковым сбором.
Если при запущенном в модуле сборе от программы не поступают запросы данных функцией LTR212_Recv, то модуль все равно пересылает данные в компьютер?  Если так, то кто осуществляет откачку данных из модуля без запросов от конечной программы - ltrserver или ltr212api?

ltrserver всегда откачивает данные по USB, вне зависимости от того есть запросы от пользователя или их нет. (так как в крейте буффер FIFO, то для того чтобы данные от одного модуля не затыкали данные от других модулей это необходимо)

   В ltrserver в зависимости от типа USB выделяется буффер, не менее 4 Мб на модуль для буфферизации принимаемых данных. Если этот буффер переполняется, он автоматом сбрасывается, и клиенту выставляется флаг переполнения в поле flags структуры TLTR.

Когда можно ожидать новые версии?

Постараемся до конца этой недели, просто сейчас небольшая напряженка по другим изделиям.