В общем, не работают примеры под Labview с последним драйвером (3.2). Ошибка "Не могу получить дескриптор интерфейса!" Грустно. Разработка под Labview8.5
Если в Вашей компании есть маркетолог - его надо гнать в шею. Вы посмотрите на темы в конференции! Каждая третья - про проблемы с работой под Labview. И после этого Вы продолжаете считать, что классы интереснее  и удобнее? А пользователи пытаются воспользоваться теми огрызками, которые вы скидываете, лишь бы отстали. Детализация задач съема и выдачи данных весьма ограничена - инициализация, сбор и выдача данных, классы здесь ну абсолютно не при делах. И это ясно видно на примерах того, как сделаны драйвера у того же Advantech, не говоря уж про National Instruments. Для лабораторных задач, не говоря уж о промышленных Labview имеет значительное преимущество перед C++ в сроках разработки, простоты и надежности реализации. И все это нивелируется тем, что попытка прикрутить даже простейший сбор данных от Ваших изделий требует весьма нетривиальных познаний и инструментов. От себя добавлю - времени и нервов. Получается, что вместо того, чтобы писать функционал, нужно производить НИОКР сбора данных. Вот ни разу с такими проблемами не сталкивался при работе с Advantech, тем более NI. Хотелось-бы иметь ГОТОВЫЙ НАБОР базовых ФУНКЦИЙ. Пусть даже в виде DLL, просить сделать llb, вижу, бессмысленно.
Еще раз повторю - то, что в конференции большая часть тем про работу Ваших плат под Labview, говорит о том, что Вы этот аспект совершенно упустили. Лично я при выборе оборудования рассматриваю ваши платы в последнюю очередь именно из-за драйверов. Хотя аппаратная реализация очень интересная.
Пора уже делать изделия для работы а не для  изучения. Пусть системный программист пишет драйвер, а прикладной - программу, не надо их смешивать. И чем проще будет работа с драйвером - тем лучше.

Кстати, коллега пытается создать на базе E14-440 PID-регулятор (с АЦП считывается сигнал, и рассогласование выдается на ЦАП) Ясно, что использует модуль не по назначению. Чаще чем 55мс вывести сигнал (или считать) не получается. Такая функция вообще-то требуется часто. И ее можно реализовать на уровне LBIOS.
И второе. К сожалению, из-за того, что тактовые генераторы на ЦАП и АЦП разные, принципиально невозможно реализовать синхронный детектор. Для задач, например - измерение АЧХ устройства.
И последнее. В процедуре поверки измеряются статические параметры. А вот поверка точности задания частоты дискретизации в этой процедуре отсутствует.

Alex.
По аппаратным вопросам:
1. По поводу синхронных АЦП/ЦАП. Ожидается развитие линейки изделий E14-x40 в сторону синхронного ввода-вывода и реалтайм задач. Скоро будет обнародована предварительная техническая информация.
2. В официальной методике поверки действительно нет пункта измерения точности частоты преобразования АЦП, поскольку у прибора нет штатного выхода для непосредственного измерения этой частоты. А косвенный метод оценки точности (например, по спектру сигнала от генератора) при сертификации  оказалось утвердить проблематично (если желаете, по этому поводу наш метролог может дать более конкретный ответ).
Добавлю, что в E14-440 последних лет выпуска точность частоты преобразования АЦП составляет +-50 ppm (в рабочих условиях). Если желаете явно измерить эту частоту, то могу указать внутреннюю точку прибора, где эту частоту можно измерить (для этого сообщите серийный номер).

To Alex.
Большое спасибо за конструктивную критику, в связи с возросшим в последнее время интересом к LabView мы сейчас над этим вопросом активно работаем. В апреле должны появиться DLL и LLB для E14-140, E14-440 и E20-10. В настолящее время полноценные LLB приборы с соответствующими неклассовыми DLL-ми поставляются для E-154 и LTR модулей.
Поскольку работа эта ведется прямо сейчас, было бы очень интересно услышать Ваше мнение относительно ПО для LabView, разработанного для E-154 (ссылка на описание виртуальных приборов для E-154: http://www.lcard.ru/download/e154_labview_manual.pdf). Если бы Вы смогли уделить немного своего времени и написать Ваши замечания и пожелания относительно LLB приборов для E-154, для нас это было бы чрезвычайно полезно.
В принципе, если для Вас это будет еще актуально, мы можем изменить внутренний план работ и в первую очередь закончить LLB приборы для E14-440. Эту работу было бы реально закончить где-то к 18 марта.

Владиславу.
Прошу сообщить конкретные даты появления DLL и LLB для E14-440. От этого зависят сроки моего проекта.

А чем неустраивает библиотека lcomp.exe с примерами WLCOMP_LV.TST и библиотекой WLCOMP которая без классов?

Ответил на e-mail.

На сайт выложена библиотека виртуальных приборов и DLL-ка для LabVIEW для E14-440.

Адрес: http://www.lcard.ru/download/lusbapi32.exe

Описание: http://www.lcard.ru/download/e440_labview_manual.pdf

Полностью присоединяюся к всему вышесказоному Alex-ом. Сам уже более 10 лет программирую под Labview изделия LCard. За это время помимо своей воли пришлось освоить C++, чтобы писать свои "обёртки" dll к библиотекам призводителя.
Последние примеры для L14-440, конечно, уже большой прорыв. Спасибо уже хотя бы за то, что не используются CIN-ы. Однако, посмотрев повнимательней, хотел бы высказать некоторые замечания:
1. К чему делать два примера: сбор данных в реальном времени и многоканальный синхронный сбор? Разве механизм сбора данных на уровне работы платы в двух этих случаях чем-то различается?
2. Зачем в "вводе в реальном времени" в цикле сбора данных два раза повторяется одно и то же? только для того, чтобы показать пользователю, что копирование идёт из разных половинок буфера? Более красиво было бы вообще скрыть от пользователя низкий уровень и предоставить ему один "кубик", который бы сам следил за буфером выдавал по мере готовности свежую порцию данных. Если же программа пользователя по каким-то причинам не успевает считывать каждую порцию, то эти данные утрачиваются -пусть это лежит на совести пользователя.
Таким образом, синхронный сбор данных можно было бы организовать в 4-х функциях: подготовка, страт, считывание свежей порции, стоп. (не считая вспомогательных  - разделение каналов, преобразование в вольты и др.) Так, например, принято у NI и является наиболее удобным для пользователя.

Идея хорошая. Как раз сейчас заканчиваю библиотеку для E14-140, попробую там эту идею реализовать. Видимо в таком варианте в "кубик" сбора данных надо будет передавать число N сколько данных хотим забрать и флаг, надо ли сидеть в кубике до тех пор, пока данные не соберутся или выдавать столько данных, сколько пришло на момент вызова кубика? Если не сложно, просьба поделиться своим мнением.

Так тоже хорошо, если будет работать надёжно...

Хотя по второму режиму возникают вопросы.  Чтобы он имел смысл, надо прерывания чаще генерить, чем пол-буфера. Вопрос возникает - насколько чаще?..Дополнительный параметр вводить...

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

Ещё важно позаботиться, чтобы в режиме ожидания свежей порции "кубик" тратил как можно меньше ресурсов, чтобы оставалось пользовательскому приложению на обработку. (Я, например, делал паузу для E440 и L783. Как сделать по-другому в LCOMP, я не нашёл. Для Е20-10 в Lusbapi это делается через асинхронные запросы.)

Спасибо за дельные советы. Для E14-140 библиотеку и примеры под LabVIEW закончил, следуя Вашей идее все получилось гораздо проще и нагляднее.
Шаг прерываний и общий размер буфера сделал задаваемыми при старте сбораю. Осталось только дописать описание и потестить, так что надеюсь в понедельник к вечеру выложить на сайт.

Доступен для скачивания архив http://www.lcard.ru/download/lusbapi32.exe, в который добавлены примеры, документация для работы E14-140 в LabVIEW.