Имеется крейтовая система l-card EU-2, содержит модуль ltr11.
Взял готовый пример Delphi, полученные данные немного отличаются от исходных.
Так если подать напряжение в 4,97, то в Delphi этому значению соответствует уже 4,73.
Зависимость похоже линейная, так как к нулю уменьшается расхождение.
Запустил пример Labview - значения с точностью до сотых абсолютно правильные.
Собственно вопросы:
1. С чем это может быть связано?
2. Формат пакета LTR11 (биты 15-0 - данные (sssd...d)), описанный в руководстве пользователя крейтовой системы модуля LTR11, какой из функций соответствует - RawData или RecV?
3. В том же формате - данные представлены в дополнительном коде?

1. С калибровочными коэффициентами, я думаю.

2. И RawData, и Recv. Raw - это поток от всего крейта, не разобранный по слотам.
Преобразование из бинарного формата в double выполняет функция LTR11_ProcessData(). Ей же задается параметр BOOL calibr, который включает применение калибровочных коэффициентов.
Если Вы по каким-то причинам не хотите использовать LTR11_ProcessData(), то калибровочные коэффициенты для нужного диапазона можно взять из ltr->ModuleInfo.CbrCoef после LTR11_GetConfig(), но имейте в виду, что в двоичных данных, кроме собственно отсчетов, могут попадаться секундные метки и какие-то управляющие слова. См. ltr11api.cpp

3. В дополнительном. Но DWORDы, которые вернет Recv, в формате хоста, а не в формате модуля. Описано в ltr.pdf п.4.5.1.
Биты 31..16 - данные в дополнительном коде.
Биты 15..12 - для данных равны 00xx (биты 15,14 равны нулю), иначе это управляющее слово.
Биты 11..8 - номер слота в крейте.
Биты 7..0 - управляющий байт (то, что в 5.3.3.1 обозначено NNMMCCCC).

Думаю, что проще использовать LTR11_ProcessData()

Есть другой вопрос:
Использую LTR_Recv(&hLTR11->Channel, DataRec, TimeMarks, data_size, 10000);
для считывания данных.
Возвращается верное количество данных, но массив TimeMarks остается пустым.
Что нужно для генерации эти меток?

Нужно их включить.
В крейт-контроллере EU есть встроенные средства синхронизации, см. ltrapi.pdf по поводу меток СТАРТ и СЕКУНДА.

Хочу использовать метки генрации Секунда.
Устанавливаю TLTR_CONFIG *hLTRconfig:

hLTRconfig->userio[4] = LTR_USERIO_DEFAULT; // Значение в нормальном режиме работы
hLTRconfig->digout[2] = LTR_DIGOUT_SECOND; //На выход подаются метки "Секунда"
hLTRconfig->digout_en = 1;// вкл

Компиляция проходит нормально, при отладке выскакивает исключение.
Есть пример работы с генерацией меток?

1. Для начала - память под структуру TLTR_CONFIG выделена? У Вас переменная hLTRconfig типа указатель, значит, надо сделать
hLTRconfig = new TLTR_CONFIG;
(а потом, когда больше не нужна, delete hLTRconfig)
либо в стиле C:
hLTRconfig = malloc(sizeof(TLTR_CONFIG));
if (!hLTRconfig) { ошибка выделения памяти }
...
free(hLTRconfig);

Но проше сделать обычную автоматическую или статическую переменную:
TLTR_CONFIG LTRconfig;

Во-вторых:
hLTRconfig->userio[4] = LTR_USERIO_DEFAULT;
hLTRconfig->digout[2] = LTR_DIGOUT_SECOND;
Ой. Это Вы так пытаетесь инициализировать массивы?
Так не пойдет. В квадратных скобках указывается индекс массива, т.е.
hLTRconfig->userio[0] = ...
hLTRconfig->userio[1] = ...
hLTRconfig->userio[2] = ...
hLTRconfig->userio[3] = ...

hLTRconfig->digout[0] = ...
hLTRconfig->digout[1] = ...

Инициализировать нужно все поля структуры, чтобы не было мусора на входе. Не забудьте вызвать LTR_Config().

Либо можно описать инициализированную структуру:
TLTR_CONFIG LTRconfig =
{
  { значение userio[0], значение userio[1],
    значение userio[2], значение userio[3] },
  { значение digout[0], значение digout[1] },
  значение digout_en
};

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

Примеры в ltr_sources.zip -> LTR_SOURCES/ltrapi/examples

P.S. Кстати, чтобы синхронизировать модули внутри крейта, вывод на DIGOUT не нужен. Он нужен только в том случае, если Вы хотите получить синхроимпульсы в электрическом виде на круглом разъеме SYNC крейта.

Может плохо в документацию посмотрел, но так и не нашел описания, какие неолбходимо задать параметры для userio[0-3] и digout[0-1].
Ставлю для digout[0-1] и userio[0-3]=default (в нормальном режиме как и написано)
Делаю LTR_Config, проходит успешно.
А вот при старте генерации меток ошибка LTR_ERORO_Execute.

ltrapi.pdf п. 4.1

ltrserver какая версия?

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

userio всегда LTR_USERIO_DEFAULT
digout и digout_en нужны только для того, чтобы снимать сигналы с контактов DIGOUT1 и DIGOUT2 разъема SYNC. Значения LTR_DIGOUT_xxx в таблице в п.4.1 руководства ltrapi.pdf, страница 15.

Все функции синхронизации подробно описаны в п.4.3.3 того же руководства.

Вопрос, заданный ранее:

Имеется крейтовая система l-card EU-2, содержит модуль ltr11.
Взял готовый пример Delphi, полученные данные немного отличаются от исходных.
Так если подать напряжение в 4,97, то в Delphi этому значению соответствует уже 4,73.
Зависимость похоже линейная, так как к нулю уменьшается расхождение.
Запустил пример Labview - значения с точностью до сотых абсолютно правильные.
Собственно вопросы:

Полученный ответ:
1. С калибровочными коэффициентами, я думаю.

Перепрошил крейт новой прошивкой, ничего нового не произошло.
По-прежнему в сырых данных LTR_Recv приходят данные, не соответствующие оригинальным.
Перепробовал несколько dll библиотек различных версий - эффекта никакого.

Как так получается, что с LabView приходят результаты идеальные, а в Вашем примере Delphi с заметной погрешностью?

см. ответ от 19.07.10 13:10 пункт 2.

В сырых данных и не должно быть откалиброванных значений - применением калибровочных коэффициентов занимается функция LTR11_ProcessData() на компьютере, когда пересчитывает из DWORD в double. Причем только если функции передан аргумент calibr == TRUE.

Иными словами: крейт хранит калибровочные коэффициенты в энергонезависимой памяти модуля, но сам не использует их для вычислений. Они отдаются в PC в составе блока параметров, который считывается через LTR11_GetConfig(), и функция LTR11_ProcessData() их оттуда берет.

Спасибо за ответ.
Помогло именно применение функции LTR11_GetConfig(), которая загрузила калибровочные коэфф. и данные стали отображаться правильно.

На здоровье.

Собираю данные от крейта ltr11-модуль.
принимаю правильное кол-во данных через LTR_Recv.
Затем передаю этот массив в LTR11_ProcessData и выпадает ошибка -1011:
В массиве принятых от АЦП модуля данных имеются сбои.

Как с этим бороться, довольно часто приходят такие данные?
минимум ошибок происходит, когда ltr-server и модуль только включились и ничего с них еще не было закачано.

Через какой интерфейс работаете: USB или Ethernet? Частоту АЦП в LTR11 какую ставите?

К примеру, если АЦП настроен на 400 кГц, при этом, USB в компьютере настроен на full-speed, то пропускной способности интерфейса не хватит, и тогда, естественно, будут наблюдаться сбои.

Да, если USB, то проверьте режим порта - high speed (2.0) или full speed (1.1).
Если TCP/IP - опишите, как подключен крейт. По проводам (100 или 10 Мбит/с) или по wifi, сеть нагружена чем-то еще или выделенный шнурок между крейтом и компьютером, и т.д.

Сколько модулей всего запущено? Один LTR11 и все?
Какая версия ltrserver и ltrapi? (при желании обновитесь в библиотеке файлов)

Во время сбора данных можно посмотреть суммарный поток от крейта в окне статистики ltrserver.
Этот поток в DWORD//'ах примерно равен суммарной частоте опроса по всем каналам (число отсчетов в секунду), в байтах - умножить на 4.

Там же в статистике ltrserver показывается заполнение FIFO буфера. Если оно поднимается до 100%, то, значит, приложение не успевает вычитывать данные из сервера.

Еще можете посмотреть в task manager//'е, сколько процентов CPU скушивает ltrserver.exe и Ваше приложение.

Есть ли какие-то ошибке при работе через LGraph2, UTS?

Как реализована процедура чтения в приложении? В отдельном потоке или нет? Цикл чтения должен быть правильно реализован, без больших перерывов. Не пытаетесь ли обращаться к модулю из разных потоков одновременно?
Делаете ли STOP перед START?
...

опечатка "какие-то ошибки"

Нашлась ошибка - дважды вызывалась функция start, после чего шли сбойные данные.