Установка конфигурации:
int CBRV_LTR34Device::BRV_LTR34SetConfig(CHAR *SerialNum, int slot_num){
    // инициализируем указатель
    int res = LTR34_Init(hLTR34);
    // настраиваем
    hLTR->saddr = SADDR_DEFAULT;
    hLTR->sport = SPORT_DEFAULT;
    // открываем канал для связи
    res = LTR34_Open(hLTR34,hLTR->saddr,hLTR->sport,SerialNum,slot_num);
    if(res == LTR_OK || res == -10)
    {
        // проверяем модуль ltr34
        res = LTR34_TestEEPROM(hLTR34);
        // если все прошло удачно
        if(res == LTR_OK){
            // загружаем калибровочные коэфф.
            res = LTR34_GetCalibrCoeffs(hLTR34);
            // для каналов упр. слова
            for (int n = 0; n < NumOfChannels; n++) {
                // каналы 1-4, режим 1:1
                hLTR34->LChTbl[n] = LTR34_CreateLChannel(ChannelInfo[n].ChannelNumber,0);
            }
            //прописываем количество используемых каналов
            hLTR34->ChannelQnt = NumOfChannels;
            // установка режима генерации
            hLTR34->FrequencyDivisor = 64 - (2000000 / Rate);
            // использовать калибровку
            hLTR34->UseClb = true;
            // тип подтверждения каждое слово
            hLTR34->AcknowledgeType = true;
            // Внешний старт отключен
            hLTR34->ExternalStart = false;
            // Потоковый режим
            hLTR34->RingMode = AutoGeneration;
            // Сбрасываем модуль
            res = LTR34_Reset(hLTR34);
            if (res == LTR_OK) {
                // конфигурация модуля
                res = LTR34_Config(hLTR34);
            }
        }
    }
}

// поток для отправки данных
DWORD WINAPI G_LTR34SendData(LPVOID pvParam){
    int res;
    // преобразуем структуру в наш класс ltr34
    CBRV_LTR34Device *pltr34 =  (CBRV_LTR34Device *) pvParam;
    // записываем данные в ltr
    res = pltr34->BRV_LTR34StartSendData(true, false);
    // запускаем режим генерации и отправки данных
    res = pltr34->BRV_LTR34DACStart();
    while (pltr34->ThreadWorks){
        // режим автогенерации выключен
        if (!pltr34->AutoGeneration) {
            res = pltr34->BRV_LTR34RecV();
            res = pltr34->BRV_LTR34StartSendData(true, true);
        }
    }
    // останавливаем режим
    res = pltr34->BRV_LTR34DACStopClose();
}

// запуск потокового режима
int CBRV_LTR34Device::BRV_LTR34DACStart(){
    return LTR34_DACStart(hLTR34);
}
// останов потокового режима
int CBRV_LTR34Device::BRV_LTR34DACStopClose(){
    return LTR34_DACStop(hLTR34);
}

"Получается, что, пока все данные записанные в буфер ltr_server////'a не будут переданы в модуль - остановить работу нельзя?"
Если комманда передачи данных закончила свою работу, то можно уже передавать и другие комманды.
Ваш код выглядит нормально, но непонятно как именно вы отправляете данные и как вы их принимаете.
И у вас сейчас включен режим "кольца" а не потоковый, но это наверно вы пробовали.

Что-то смущают меня эти ThreadWorks и StartSendData.
Не может быть, что !ThreadWorks становится раньше, чем фактически завершаются все операции?

Новый вопрос:
Имеется LTR43-4, беру пример LTR//Lcard//LTR//SOURCE//ltr-34//example//BCB_6.
Запускаем, выбираем 1 канал активным и выставляем Значение mV - 1000
скорость нарастания - 1000
В идеале на выходе АЦП должен выставиться сигнал в 1 В.
Проверяем - на выходе 0,98.
Подобная проблема была и с ltr11, все успешно решилось после считывания калибровочных коэффициентов.
В примере для LTR34-4 как и написано в документации, процедура LTR34_Open содержит функцию LTR34_GetCalibrCoeffs().
Хотелось бы узнать, почему выходное напряжение не соответствует?

На каком выходе вы измеряете, и какой режим при этом указан для канала (1:1 или 1:10)?

Выход 1 OUT1
Канал настроен как 1:1.

Пример работает корректно, проверил. Попробуйте вывести сигналл другой программой или другим примером, и ещё, чем вы меряете???

Приношу свои извинения.
Пример и оборудование работают корректно, вольметр уже свое отживает )

Вопрос по потоковому режиму.
В отдельном потоке использую цикл для передачи данных в буфер ltr server.
// записываем данные в ltr
for (int i = 0; i < 10; i++) {
res = pltr34->BRV_LTR34StartSendData(true, false);
}
// запускаем режим генерации и отправки данных
res = pltr34->BRV_LTR34DACStart();
while (pltr34->ThreadWorks){
// режим автогенерации выключен
if (!pltr34->AutoGeneration) {
    pltr34->test();
//pltr34->BRV_LTR34StartSendData(true, true);
        }
    }
// останавливаем режим
res = pltr34->BRV_LTR34DACStopClose();

ради эксперимента забиваю в буфер ltr 10 готовых буферов с данными.
а затем в цикле (pltr34->test()) отправляю готовый буфер со старыми данными (т.е. время на генерирование данных не тратится)
в итоге на осциллографе поначалу (когда в буфере ltr server данных хватало) отображается нормальная синусоида.
когда приходит время отправки данных в цикле, синусоида начинает рваться на части.
где-то было написано, что в случае опустошения или голодания, на выходе остается предыдущее значение - очень на это похоже.

Хотелось бы поднять этот и вопрос и попросить пример работы ltr34 в потоковом режиме.
хочется посмотреть, как данные успевают накачиваться в буфер.

Не собирается из исходников проект
LTR34-4 зав.№ 3R752164
прошу помочь!

ExampleLTR34VC++
2 ошибки линковки
ExampleVC++.obj : error LNK2019: unresolved external symbol __imp__LTR34_SendData@24 referenced in function _wmain
ExampleVC++.obj : error LNK2019: unresolved external symbol __imp__LTR34_SetConfig@4 referenced in function _wmain
Предположительно в ltr34api.lib отсутствуют функции LTR34_SendData и LTR34_SetConfig.

Прошу помощи!

модуль LTR22 зав.№3R751946
работает в LGRAPH2 и не  работает в программах UTS-pro и в PowerGraph через USB.

LTR34_Send() и LTR34_Config()

Похоже, что пример устарел и не поправили. Пардон.
В примере Generate, который лежит рядом, имена функций правильные.

По второму вопросу - более подробно описать сможете? Что видите в UTS?

Вчера блок работал с UTS, а после работы с POWER GRAPH перестал:
При входе в UTS сообщение
"Точка входа в процедуру LTR_GenericCtlFunc не найдена в библиотеке DLL LTRAPI.DLL".
После выбора LTR22 сообщение
"No any plugin axists for this type of modules".
Выяснилось, что это со всеми модулями.

повторная инсталляция UTS не помогла

Спасибо, всё скомпилировалось, но при запуске EXE-файла  с примером  для модуля LTR34 выводится черное окно с сообщением
"Error open module -5
enter value and press enter to exit from application".

Похоже, что инсталлятор от powergraph записал Вам поверх новой старую версию DLL.

Переставьте ltrdll_1_22.exe, а потом на всякий случай положите все нужные dll (ltrapi, ltr34api, ...) в директорию со своей программой.

Повторюсь, вдруг ответят:
"Хотелось бы попросить пример работы ltr34 в потоковом режиме.
хочется посмотреть, как данные успевают накачиваться в буфер."

пример LTR_SOURCES//ltr-34//example//BCB_6 не подойдет? Там потоковая генерация.

Подключение по USB или по IP?

В данном примере потоковая генерация константы, меняющейся во времени.

Если задать периодический сигнал - sin, то при подкачке данных в потоковом режиме будет интересная картина.
Отправив первый раз через Send данные и начав генерацию через DACStart, необходимо успевать подкачивать данные. В реальном времени буфер не сможет принимать данные и отправлять их сразу же.

Поэтому как и написано в руководстве к ltr34, возможно опустошение - т.е. новые данные не пришли, а старые уже отправили и последнее значение висит на выходе - видим константу.

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

надеюсь, у меня получилось объяснить.

А не маленький ли размер начальной загрузки?
У LTR34 очень большой буфер (2048K отсчетов). Перед началом вывода желательно его заполнить, а затем подкачивать данные (в простейшем случае - LTR_Send() в цикле).
Тогда в норме буфер вывода будет полон, и запас на случай пробуксовки компьютера будет весьма большой (>4 сек на максимальной частоте 500 кГц).

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

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

И Вы не сказали: подключение крейта по USB или по TCP/IP? По IP скорость ниже ( см. http://www.lcard.ru/products/ltr/ltr-eu-2 ), не на всякую частоту дискретизации хватит (1 отсчет = 4 байта).

Подключение крейта по TCP//IP.

С большим заполненным буфером, вероятно, таких проблем не будет.

спасибо за совет, попробую сделать так.

По TCP/IP осторожно со скоростью. Заявленные 1.4 МБайт/с соответствуют частоте дискретизации около 360 кГц. Может получиться и больше, может меньше (например, если воткнуться в 10-Мбитный хаб или устроить пакетный шторм в сети).

Тестируйте. Смотрите в ltrserver на заполнение FIFO (в статистике для ltr34 показывается). Счтечик должен показывать заполнение и в течение всего времени генерации трепыхаться в районе максимума.

Основные правила для непрерывного потока:
1) источник данных должен обеспечивать установившуюся (среднюю) скорость подкачки заведомо больше скорости потребления данных. Желательно в разы.
2) начальное состояние FIFO буфера - полный.
3) толерантность к кратковременным перерывам подкачки определяется размером буфера, частотой перерывов, запасом скорости (можно подсчитать).

Здравствуйте!
Возможен ли в ltr-34 вывод в режиме автогенерации двух когерентных синусоидальных сигналов, сдвинутых по фазе?
Заранее спасибо

Да, возможен.