Форум:

Если так написано, то это для актуальной версии неправильно, см. исходные тексты lusbapi.
422 - это действительно таймаут:
#define    E2010_BASE_ERROR_ID (400)
#define    E2010_ERROR_ID_22 (E2010_BASE_ERROR_ID + 22)
E2010_ERROR_ID_22,    "Таймаут ожидания ввода данных."
Собственно, эту строку и должна была вернуть функция GetLastErrorInfo.

А вот почему, я пока не понял. Пуск АЦП, говорите, точно успешно выполнился? Внешний запуск вроде бы не включен.

Величина таймаута рассчитывается странно (по-моему, для получения времени сбора надо было разделить еще на число каналов), но это в большую сторону ошибка, а потом еще +1000 (секунда).
Вообще-то бывают фокусы с большим размером запроса в зависимости от USB хост-контроллера на компьютере. 512 кБайт (SHORT[256*1024]) - это не так уж мало, а что если попробовать уменьшить буфер в 2, 4, 8 раз?

Евгений, по такому описанию очень трудно что-либо понять.
Функцию main не вызывают явно.
Если Вы хотите переделать консольный пример на GUI, надо разнести соответствующий код по обработчикам события элементов управления. Например, можно расписать блок-схему консольной программы (в каком порядке и с какими параметрами вызываются функции библиотеки) и потом, руководствуясь этой блок-схемой и общими правилами написания GUI приложений, реализовать аналогичную функциональность.
Консольный вывод (printf, puts...) надо переделать на соответствующие вызовы GUI. Например, писать их в text box.
Цикл чтения данных и записи в файл по идее надо бы вынести в отдельный поток, т.к. он исполняется длительно, а кнопки в интерфейсе надо обрабатывать. Или (хуже) вызывать функцию для обработки GUI - смотря на чем Вы пишете - типа ProcessMessages, ProcessSystemEvents и т.п.
Начинающие часто засовывают весь алгоритм в обработчик события кнопки "начать" - смотреть на это больно, но для первой пробы хотя бы так.

Если "не компилируется" - значит, что-то не так в самом тексте или заголовочный файл не включили. Если не линкуется (ошибка типа undefined external) - то это может быть связано с тем, что не добавлен необходимый .lib файл.

Нужны конкретные сообщения об ошибках и, возможно, исходный текст (если он небольшой).

Только, очевидно, PCI плату придется программировать своими силами на низком уровне, основываясь на исходных текстах lcomp_linux или l502api. Думаю, пригодится какой-нибудь 32-битный DOS extender, что-то вроде DJGPP.
В "совсем голом досе" будет тяжело - нужен прямой доступ в верхнюю память. Хотя есть и big real mode.

Позволю себе чуть подробнее раскрыть совет Poul.
Если речь о том, чтобы одновременно работать с одним и тем же устройством, то в общем случае такая задача едва ли решается, поскольку устройство физически одно и его состояние зависит от предыдущих операций.
Чтобы получилось что-то осмысленное, надо фактически придумать протокол более высокого уровня, учитывающий логику вашей задачи и сообразно ей ограничивающий и сериализующий действия приложений (например, одно приложение управляет, а второе только наблюдает копию данных, или одно работает только с ЦАП, а второе только с АЦП). Вспомогательная программа, реализующая такой протокол, и будет "сервером" (демоном, службой).

Это похоже на задачу измерения АЧХ/ФЧХ, тогда надо действительно запустить одновременно ЦАП и АЦП, соединив (корректным образом) выход ЦАП со входом тестируемой схемы, а выход тестируемой схемы со входом АЦП.
И важно не забыть настроить не только ЦАП (параграф 3.1.2), но и АЦП (параграф 3.1.1).

Артем, спасибо за диагностику.
На скриншоте ошибка возникла после 184194 успешных циклов - это такое поведение (т.е. ошибка возникает не сразу) или это Вы отсоединили "паразитное питание" на ходу и сразу произошел сбой?

Для синхронного см. документацию на сайте.
У E14-440 по e14_440_programmers_guide.pdf сетка частот 24000000/N Гц, где N = 60...65535
У L-502 по l502api.pdf опорная частота 2 МГц или 1.5 МГц делится на N = 1...1048576

Да просто заполняете массив отсчетов и пишете его через LTR_Send. (Естественно, после процедуры инициализации и старта.) В отличие от USB модулей (Exx-xxx), для LTR34, если я не ошибаюсь, не нужно писать специальную двойную буферизацию и т.п., скорость вывода регулирует ltrserver (ltrd). То есть можно писать "просто подряд", как будто в файл на диске эти массивы записываете.

Пока две версии: либо неправильно собрана программа, либо прибор неисправен (не может включить ПЛИС?)

1. А при каких обстоятельствах прибор последний раз успешно использовался?

2. LGraph2 пробовали?

3. Из вот этого архива попробуйте программы unidir.exe ttl_speed.exe

Дело в том, что этой информации объективно немного: работа с TTL линиями в E14-440 и подобных приборах - не основная функция. Возможности ее скромные: просто записать или считать регистр, однократно, по команде от компьютера.
Все режимы синхронизации, линия INT и прочее относится к работе АЦП.

Например. Только надо учитывать, что когда Вы приводите константы типа IN<1...16> = 0x2020, это получается состояние всех 16 каналов в один момент времени, а не последовательность бит по одному каналу.

Возможны разные решения. Можно написать программный аналог USART (в синхронном режиме) или SPI, используя какую-то линию как CLOCK (например, при изменении с 0 на 1 брать биты данных с другой линии). Но из-за работы в режиме опроса этот интерфейс получится медленным. Возможно, Вам удастся опрашивать TTL_IN() до 250 раз в секунду, но важно понимать, что эти считывания не привязаны к равномерным интервалам времени, а происходят "как получится". Если компьютер "задумается", можно пропустить импульс. Поэтому надо либо оставлять большой запас по времени (и программно защищаться от сбоев), либо делать интерфейс с подтверждением (как STROBE/ACK у LPT порта).

У нас на сайте есть заметка, в которой рассмотрен похожий вопрос.

Пожалуй, только так можно сделать на этом устройстве более продвинутую работу с TTL линиями.

Попробуйте скачать дистибутив lcomp и поставить его.

Если "время между кадрами" - это период кадра, то это одно и то же.

Размер буфера в байтах разделить на размер отсчета АЦП (если отсчет 16-битный, то 2) - получится размер буфера в отсчетах.
Если дополнительная межкадровая задержка не используется, то размер буфера в отсчетах просто разделить на частоту дискретизации и всё.
А если межкадровая задержка есть, то разделить на количество каналов в кадре (получится количество кадров в буфере) и умножить на период следования кадров (см. 3.2.4. "Формат кадра отсчетов" в том же руководстве).