Каковы могут быть причины возникновения ошибок:
LTR212_ERR_CANT_GET_FRAME                         
LTR212_ERR_INV_ADC_DATA                            

Хотелось бы всё-таки получить ответ. К сожалению, в руководстве программиста есть расшифровка ошибок только для крейта:(

Ошибка с кодом LTR212_ERR_CANT_GET_FRAME в текущей версии ltr212api отсутствует и появиться не может.

Ошибка LTR212_ERR_INV_ADC_DATA может появиться при получении неверных данных от модуля. Модуль собирает данные в соответствии с таблицей логических каналов и к данным  с каждого канала добавляется его условный номер. В функции ProcessData на всякий случай есть проверка, что последовательность каналов соответствует таблице. Если будет обнаружено несоответствие, то будет выдан код ошибки LTR212_ERR_INV_ADC_DATA.

Неверные данные от LTR-модуля могут прийти:
1) В следствие какой-либо некорректной работы с LTR212 с точки зрения отправки ему определённой последовательности команд (к примеру, в LTR212 пришла аппаратная команда RESET модулю LTR212 во время сбора данных)
2) В следствие аппаратного сбоя LTR212, например, от мощной электростатической помехи, пришедшей на входы LTR212 относительно точки заземления крейта.

Помеха маловероятна, так как ошибка повторяемая.

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

Дело точно в программе. С LGraph//'ом всё работает нормально (спасибо Владиславу), теперь мы делаем программу под LabVIEW и здесь и возникли проблемы.

Может быть, на вход ProcessData() попадают данные не так (все, в том же порядке, без пропусков), как они пришли из Recv. Может быть, что-то не так с опросом Recv.
Можете попробовать сверить счетчик принятых двойных слов со статистикой ltrserver.

Скорее всего прав Александр Е. - дело в передаче массива с данными между вызовом Recv и ProcessData.

Примерчик на C# даёт ту же ошибку. Владислав, не могли бы Вы посмотреть, в чём всё-таки проблема (отправил по почте).

Не удалось ещё посмотреть, воспроизводится ли ошибка у вас?

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

какой тип крейта и как подключен (USB, TCP/IP)?

EU-2-5,TCP/IP

Псле однократного возникновения ошибки:
- можно штатно остановить сбор и запустить снова средствами приложения?
- восстанавливается перезапуском приложения, но без отключения крейта или ltrserver?
- восстанавливается disconnect/connect из ltrserver?
- восстанавливается перезапуском ltrserver?
- восстанавливается выключением крейта?

Можно снять лог ltrserver с максимальным уровнем журнализации на разных компьютерах - посмотреть, нет ли каких-то аномалий.

1. Всё ли корректно в ltrmodulesnet.dll? Она датирована 14.01.2010, а библиотеки api летом перерабатывались. Суть в том, что LGraph работает стабильно, а пример на LabVIEW нет (на одном и том же "железе").
2. Отличается ли прошивка крейтов EU-2-5, купленных летом 2010г от 1.01 (которая выложена на сайте)?

Вопрос по версиям актуален. Дело в том, что "поведение" модулей отличается.

Неужели никто не может ответить на вопрос по версиям библиотеки и прошивки?

Текущая версия крейта - 1.01.
ltrmodulesnet.dll летом не обновлялась, так что у Вас последняя версия.

ltrmodulesnet.dll лишь "обертка" над ltrapi, т.е., например, функция ProcessData из ltrmodulesnet.dll вызывает функцию LTR212_ProcessData из ltr212api.dll. Так что сама логика работы основных функций должна быть одинакова, независимо от того, вызываются они из  C или C#. И если не меняются параметры функций или поля структуры, то при изменении ltr212api.dll что-либо меняться в ltrmodulesnet.dll и не должно.

Что касается ошибки: Вы не пробовали проверять, всегда ли Recv возвращает то же значение, что и передано в параметре size. Если Recv не примет все данные за заданное время (параметр timeout), то в ProcessData может быть передано не целое число кадров, что приведет к смещению данных. В примере LabVIEW выход Recv не проверяется (более того, в качестве size в ProcessData передается константа, а не выход с Recv). Можно также попробовать сильно увеличить параметр timeout.
В LGraph2, если я не ошибаюсь, подобные ситуации отслеживаются (там вроде немного другая логика вызовов Recv/ProcessData).

Работаю с LTR212 зерез ltrModulesNet.dll (в labview).
Проблемы начинаются при попытке остановки сбора данных (команда stop). Бывает так что команда завершается ошибкой -2025 (cant_stop), а бывает что говорит ОК, а результата нет...
В итоге чтоб остановить сбор данных, команду остановки вызывал в цикле. Но это не всегда работает если буер в сервере начал заполняться.
Пока приходится выполнять последовательно команды close, open для остановки сбора данных.

Как правильно остановить сбор данных (нюансы может какие?).

Все решилось. Я пытался управлять сбором данных (старт-стоп) из стороннего потока, а этого делать видимо не стоило.
Внес команды старт - стоп в один поток со сбором данных - все заработало.

Да, non-thread-safety ltrapi описана в документации.
У LTR общий канал для команд и данных.
Обращения к одному дескриптору TLTR должны быть сериализованы, т.е. либо обрабатываться в одном потоке, либо защищаться критическими секциями.

Какое максимально количество измерений в секунду можно получить ? Если да,то как настроить?

Для модуля LTR212 максимальная частота сбора составляет 7680.0 Гц в четырехканальном режим средней точности.