Начал рассматривать примеры и вот что стало непонятно:
E440v20/Examples/BC5/ReadData/
В файле Readme  написано,что "Подключение сигналов - дифференциальное." Каналов - 4.
При этом, в ControlTable[0] - ControlTable[3] грузятся значения  64, 65, 66, 67 (исходный текст ReadData.cpp) . А это, судя по описанию формата логического кадра канала "п.1.3.2.3 Руководства программиста. Rev. A" означает подключение в режиме с общей землёй каналов 4,5,6 и 7 соответственно с коэввициентом усиления - 4. И что самое интересное, далее в структуре ADC_PARS_440 полученной с АЦП обнаруживаю, что загружено ещё 4 таблицы ControlTable[4] - ControlTable[7] со значениями 4,5,6  и 7, что соответствует уже включению этих же четырёх каналов в дифференциальном режиме с коэффициентом усиления 1.
Аналогично и в примере динамической загрузки на MSVC6 в директории E440v20/Examples/MSVC6/DynLoad/  :

  ******************************************
Console example for DLL dynamic loading    
******************************************
'Lusbapi.dll' Dynamic Loading --> OK
Address of GetDllVersion() --> OK
GetDllVersion() --> OK
Address of CreateInstance() --> OK
Module Interface --> OK
InitLDevice() --> OK
GetModuleName() --> OK
The module is 'E-440'
LOAD_LBIOS() --> OK
MODULE_TEST() --> OK
GET_LBIOS_VERSION() --> OK
LBIOS Version --> OK
GET_MODULE_DESCR() --> OK
GET_CUR_ADC_PARS() --> OK

Это данные в АЦП "по умолчанию":
am.size = 316
am.AdcEnabled = 0
am.CorrectionEnabled = 0
am.InputMode = 0
am.SynchroAdType = 0
am.SynchroAdMode = 0
am.SynchroAdChannel = 0
am.SynchroAdPorog = 0
am.ChannelsQuantity = 8
am.ControlTable[0] = 0
am.ControlTable[1] = 1
am.ControlTable[2] = 2
am.ControlTable[3] = 3
am.ControlTable[4] = 4
am.ControlTable[5] = 5
am.ControlTable[6] = 6
am.ControlTable[7] = 7
am.ControlTable[8] = 0
am.ControlTable[15] = 0
am.ControlTable[16] = 0
am.ControlTable[17] = 0

FILL_ADC_PARS() --> OK

md.size = 66
md.SerialNumber = 5L737875
md.Name = E440
md.Revision = B
md.Dsp_Type = 2185
md.IsDacPresented = 0
md.QuartzFrequency = 24000000
md.CalibrKoefAdc[0] = 4
md.CalibrKoefAdc[1] = 5
md.CalibrKoefAdc[2] = 12
md.CalibrKoefAdc[3] = 38
md.CalibrKoefAdc[4] = 33091
md.CalibrKoefAdc[5] = 32929
md.CalibrKoefAdc[6] = 32768
md.CalibrKoefAdc[7] = 32755

am.size = 316
am.AdcEnabled = 0
am.CorrectionEnabled = 1
am.InputMode = 0
am.SynchroAdType = 0
am.SynchroAdMode = 0
am.SynchroAdChannel = 0
am.SynchroAdPorog = 0
am.ChannelsQuantity = 4
am.ControlTable[0] = 64
am.ControlTable[1] = 65
am.ControlTable[2] = 66
am.ControlTable[3] = 67
am.ControlTable[4] = 4
am.ControlTable[5] = 5
am.ControlTable[6] = 6
am.ControlTable[7] = 7
am.ControlTable[8] = 0
am.ControlTable[15] = 0
am.ControlTable[16] = 0
am.ControlTable[17] = 0

Module E-440 (S/N 5L737875) is ready ...
Adc parameters:
   ChannelsQuantity =  4
   AdcRate =  400.000 kHz
   InterKadrDelay = 0.0025 ms
   ChannelRate =  100.000 kHz
   QuartzFrequency = Hz 

ReleaseLDevice() --> OK

Вопрос: как же будет работать АЦП инициализированный подобным образом?

1. Для начала разрешите дать Вам совет - надо бы повнимательней читать тех.документацию, а также не мешало бы подучить мат.часть по общим вопросам программирования.
2. Логический номер канала равный 64 (десятичный формат) имеет следующее стандартное бинарное представление: 0100 0000. Это соответствует первому каналу АЦП в диф. режиме с усилением равным 4.
3. Управляющая таблица ControlTable может содержать в себе хоть все 128 элементов, но из них реально использоваться будут только первые ChannelsQuantity.

Насчёт 64 (десятичный фрмат, его бинарного представления и длины ControlTable поторопился, был неправ и приношу извинения.
Но вот другой вопрос по этим же примерам. Связан с корректировкой отсчетов с АЦП.
Первый пример:
E440v20/Examples/BC5/AdcKadr/AdcKadr.cpp
Здесь 4 канала, коэффииент усиления 4, загружаются все 8 коэффициентов  для корректровки нуля и для корректировки масштаба для всех возможных значений коэффициента усиления.
// будем использовать фирменные калибровочные коэффициенты, которые храняться в ППЗУ модуля
    for(WORD i=0; i < 8; i++) am.CalibrKoefAdc[i] = md.CalibrKoefAdc[i];

Тут всё понятно: грузим на всякий случай все значения.

Второй пример:
E440v20/Examples/MSVC6/Dynload/DynLoad.cpp
Здесь тоже 4 канала, коэффииент усиления 4.
    am.ChannelsQuantity = 4;        // четыре активных канала
    for(i=0; i < am.ChannelsQuantity; i++) am.ControlTable[i] = (WORD)(i | (0x1 << 6));
    am.AdcRate = 400.0;            // частота работы АЦП в кГц
    am.InterKadrDelay = 0.0;
    // будем использовать фирменные калибровочные коэффициенты, которые храняться в ППЗУ модуля
    for(i=0; i < am.ChannelsQuantity; i++) am.CalibrKoefAdc[i] = md.CalibrKoefAdc[i];

Тут не понятно, т.к. , загружаются только 4 коэффициента  для корректровки нуля для всех возможных значений коэффициента усиления, а для корректировки масштаба - не загружаются. В соответствии с Вашим описанием, цитирую:
"Обычная формула для корректировки выглядит следующим образом:
U = (V + A)•B,
где V – полученный отсчет с АЦП, A – кор. коэффициент смещения, B – кор. коэффициент мас-штаба, U – откорректированное значение отсчета с АЦП. "

Как в этом случае будет осуществляться корректировка?

Там очепятка. Всегда нужно грузить все восемь корректировочных коэффициентов.

Кстати, такая же "очепятка" имеется в тексте Init_CIN.c (и соответствующем Описание программы-примера E440_ADC.vi.doc)

am.CorrectionEnabled=pars->CorrectionEnabled; // включена ли коррекция.

                                               // Загружаем калибровочные коэффициенты,
                                               // хранящиеся в ПЗУ модуля
for(i=0; i< 4; i++)
am.CalibrKoefAdc[i] = md.CalibrKoefAdc[i];

Видимо это происходит потому, что Вы "зациклились" в своих примерах на 4-х каналах, что конечно же хорошо согласуется с требованиями кратности параметров AdsFifoLength и  NumberOfWordsToRead. Конечно же интересно было бы показать как заполняется буфер при количестве каналов, к примеру 5. Но эти "тонкости"  уже видимо не предусматривались в Ваших примерах.

А вот ещё вопрос:  на блок-диаграмме oscilloscope.vi в case Structure "Load Synchro pars" при рассчёте порога аналоговой синхронизации Вы делите задаваемую в вольтах величину порога ( Threshold ) на константу 0,0012207 что соответствует значению диапазона (для данного случая +-10 вольт) делённому на 8192, хотя в Вашем Руководстве программиста для модуля Е14-440 сказано, что максимальное значение кода АЦП, соответствующее максимальному напряжению на аналоговом входе, может быть только 8000 ?!

Посмотрел почти все примеры от L-Card из директории E440v20 и попробовал работу E14-440.
Вот результат:
1. Очень много опечаток. Я смотрел "по-диагонали"  и насчитал около десятка. Это грустно. Опечатки и в текстах примеров и в руководстве программиста.

2. Перекомпиллировал полностью dll. Убрал классы и сделал все функции экспортируемыми. При этом: во-первых, как мне кажется я нашёл причину происхождения опечатки с 4-мя калибровочными коэффициентами вместо 8-ми. Она происходит из реализации функции bool WINAPI TLE440::FILL_ADC_PARS(ADC_PARS_E440 *am)
В этой функции калибровочные коэффициенты грузятся 4-мя ПАРАМИ. Если про это забыть, то получаются опечатки.
Во-вторых, появился вопрос, точнее два вопроса (больше из любопытства).
2.1. Зачем было применять классы вообще? Хотя отчасти можно предположить, что предполагалось сделать некое универсальное решение для всех разновидностей выпускаемой L-Card продукции. Подменяя затем E440.cpp и E440.h на соответствующие а Lusbapi.dll остается.
2.2. Зачем в "private" разделе класса class TLE440 создаются копии структур MODULE_DESCR_E440 md, ADC_PARS_E440 am, DAC_PARS_E440 dm в которых сохраняются копии соответствующих структур после выполнения функций типа bool WINAPI TLE440::FILL_ADC_PARS(ADC_PARS_E440 *am) ? Нигде обращений к этим копиям я не нашел. Предположил, что это сделано  "на всякий случай, на будущее".

3. Попробовал BIOS от Клименко. Увидел интересный эффект, который мне стал непонятен. Проявляется следующим образом:
    - получаем ADC_PARS_E440 am. Смотрим на ControlTable. По умолчанию там 0,1,2,3,4,5,6,7,-3108,-3108...  Заполняем ControlTable[0] значением 32 (один канал, однофазное подключение с "общей землёй, коэффициент усиления 1).
    - выполняем последовательно функции FILL_ADC_PARS(&am) и GET_CUR_ADC_PARS(&am)
Снова смотрим на ControlTable. Видим там 32,1,2,3,4,5,6,7,-3108,-3108...
    - выполняем ещё раз последовательно функции FILL_ADC_PARS(&am) со значением  ControlTable[0] равным 32 и GET_CUR_ADC_PARS(&am)
Снова смотрим на ControlTable. Видим там 32,-3108,-3108,-3108,-3108,-3108,-3108,-3108,-3108,-3108...
Вопрос: а почему изменились со второго раза значения ControlTable[1] - ControlTable[7]? Хотя они и не важны вроде как при количестве активных каналов 1.
4. Попробовал работу под LabVIEW с dll от L-Card и перекомпилированной. Кстати, здесь мне понравился прием от L-Card с подменой  в кластере read_pars  кластера  на OVERLAPPED ReadOv! У National Instruments ничего похожего я не видел.
Вроде всё работает c  обеими dll и BIOS, но появился ещё один вопрос:
Устанавливаю значение PointsToRead = 3840 (ровно 10 половинок буфера). Запускаю циклически функции ReadData и цикл WAIT отслеживающий событие GetOverlappedResult и вижу странный эффект. Если частота кадров ADC_Rate = 1 кГц, то период обновления данных в массиве буфера состовляет примерно 6,4 сек. А должен быть примерно 3,84 сек
Ставлю частоту ADC_Rate = 10 кГц - получаю период обновления примерно 0,64 сек. А должен быть примерно 0,384 сек.
При ADC_Rate = 100 кГц период замерять не стал, но обновляется во много раз быстрее чем при 10 кГц.
При этом, значения считываются правильные, количество точек - 3840. "Тормоза" наблюдаются где-то в цикле WAIT!? Но он же простой до безобразия и отслеживает только одно событие!
На примере от L-Card под названием Oscilloscope.vi - эффект тот же. Вот тут у меня возник вопрос, о происхождении этого эффекта и видимых причин оного я пока не нахожу. Буду рад если у кого-то есть свежие мысли на этот счёт! )

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

2.1. Применение классов - это не только универсальность, но удобство и комфортность написания кода.

2.2. Если бы Вы внимательно просмотрели исходный текст библиотеки (хотя бы обычным поиском), то без труда бы обнаружили места, где используются структуры MODULE_DESCR_E440 md, ADC_PARS_E440 am и DAC_PARS_E440 dm.

3.По поводу BIOS'а от Клименко следует обращаться непосредственно к Клименко: AKlimenko@insat.org.ua

Касательно вопроса о величине периода измерения при работе с LabVIEW: этот период зависит не только от частоты сбора данных (параметра AdcRate), но и от величины межкадровой задержки. В связи с этим вопрос: какую межкадровую задержку (в секундах) Вы устанавливаете? (или какое значение параметра InterKadrDelay применяете)?

Уважаемый Сергей!

Во-первых, наличие "очепяток" в принципе это нормальное явление, но только не в примерах и документации ибо на примерах учатся, а документация - это руководство к действию! Мы не "друганы" L-Carda,  а пользователи его продукции, которые заплатили за неё свои деньги. И хотели бы знать как ею правильно воспользоваться. А если у пользователя есть вопрос, то он вправе задать его в службу технической поддержки, которая просто должна на него ответить и ВСЁ! ПРОСТО ОТВЕТИТЬ на вопрос, а не искать врага в пользователе и комментировать знания и умения пользователя, который вполне возможно классом ниже чем разработчики такой технически сложной продукции!

Во-вторых, применение классов имеет свои преимущества, но только не в данном случае, когда пользователь начинает работать с устройством. Ведь что Вы всем пользователям отвечаете (или почти всем!) перекомпиллируйте библиотеку!!! Вот здорово! Как будто это ерунда какая-то, мелочь! Выпил чашку кофе и за 5 минут всё сделал! Я это смог сделать, но многим другим это просто не под силу!

В-третьих, речь в моем вопросе шла не о ADC_PARS_E440 вообще а о TLE440am. Вот фрагмент из реализации функции GET_CUR_ADC_PARS:

//-- ----------------------------------------------------------------------
// получение текущих параметров работы АЦП
//-- ----------------------------------------------------------------------
__declspec(dllexport)BOOLEAN  GET_CUR_ADC_PARS(ADC_PARS_E440 *am)
...
TLE440am = *am;

В-четвёртых, BIOS от Клименко оказался непричём. Просто на нём я увидел этот эффект. С  BIOS от L-Card эффект тот же. И вместо того, чтобы сразу же перевалить проблему на другого, я просто хотел от Вас как от технических специалистов услышать Вашу версию относительно замеченного эффекта. И ВСЁ!

И поверьте, меня интересует только техническая сторона этих проблем, а до "чистоты Вашего мундира" мне дела нет. А оскорбительный тон всех Ваших ответов наводит на мысль о том, что Вы не осуществляете техническую поддержку о отбиваетесь от нападок надоедливых пользователей. Так вот, я не надоедливый пользователь, я просто пользователь продукции от L-Card, и я ХОЧУ ЗНАТЬ КАК ЕЮ ПОЛЬЗОВАТЬСЯ!!! Поэтому задаю и буду задавать вопросы.

Ответ Алексею:

ADC_RATE = 400 кГц
ChannelRate = 1 кГц
PointsToRead = 3840
InterKardDeley = 1мсек

Только я не очень понял насчёт межкадровой задержки. Я полагал, что она входит как составлящая в период кадра и если я устанавливаю частоту кадров 1 кГц то должен получать 1000 отсчётов в секунду. Ведь в руководстве программиста от L-Card п. 1.3.4. Формат кадра отсчётов (стр. 16) именно так и написано. А я получаю 3840 отсчётов не за 3.840 сек, а за 6.4 сек. Вот в чём вопрос. А LabVIEW здесь, как мне кажется, непричём!
С Уважением,
JKL

Прошу прощения, сгоряча не ту реализацию привел в качестве примера. Надо так:
(E440.cpp)

//-- ----------------------------------------------------------------------
// получение текущих параметров работы АЦП
//-- ----------------------------------------------------------------------
bool WINAPI WINAPI TLE440::GET_CUR_ADC_PARS(ADC_PARS_E440 *am)
{
.
.
.

    TLE440::am = *am;

    return true;
}

Меня интересовала структура TLE440::am
JKL

В гл. 2.5.4.3. "Технического описания и Руководства программиста" (описание функции FILL_ADC_PARS) указано, что параметр "Поле am->ChannelRate является выходным для данной функции и в нем возвращается частота опроса ChannelRate (в кГц) фиксированного канала из управляющей таблицы (фактически это период кадра)." Т.е. установка пользователем вручную параметра ChannelRate не будет иметь эффекта. Значение этого поля определяется АВТОМАТИЧЕСКИ на основании AdcRate и InterKadrDelay. Т.е. входными параметрами для расчета частоты кадров и определения временных интервалов сбора данных должны быть значения AdcRate и InterKadrDelay. После выполнения функции FILL_ADC_PARS Вы можете проконтролировать значение параметра ChannelRate, но не изменить! Еще раз подчеркну: это параметр ВЫХОДНОЙ, и изменение его вручную иметь эффекта не будет.
  В гл. 2.3.4. указана формула для расчета фактических периода и частоты опроса одного канала (кадра). По этой формуле Tk = 1/ChannelRate = (ControlTableLength–1) * tАЦП + tмкз. Или Tk = 1/ChannelRate = (ControlTableLength–1)/AdcRate + InterKadrDelay.
  Исходя из Ваших данных Tk=(4-1)/400000+0.001 (Я предполагаю, что у Вас 4 канала, как и в примере под LabVIEW). Tk=3/400000+0.001=0.0010075 c. Частота опроса одного канала (ChannelRate)=1/Tk=1/0.0010075=992.56 Гц.
  Это значение совсем не похоже на то, которое указываете Вы (1 кГц). Еще один момент: ChannelRate - это фактическая частота одного логического канала или частота следования кадров (но не сэмплов!). Если у Вас 4 канала и Вы заказываете 3840 отсчетов, то количество КАДРОВ будет равно 3840/4=960.
  С учетом того, что период кадра Tк=0.0010075с, то время приема всех кадров равно T=960*0.0010075=0.9672 с. Что совсем не похоже на Ваши результаты.
  В связи с этим просьба еще раз проконтролировать параметры AdcRate и InterKadrDelay. А также после применения функции FILL_ADC_PARS проконтролировать значение поля ChannelRate. И рассчитать ожидаемый интервал исходя из правильных данных.

Во-первых, у меня ТОЛЬКО один канал с указанными параметрами.
Во-вторых, значение InterKardDeley = 1 мсек это то, которое установило само АЦП и я его получаю выполнив повторно функцию GET_CUR_ADC_PARS. Я знаю, что это параметр выходной, но это значение дает сам АЦП. И все значения называю именно после выполнения функций FILL_ADC_PARS затем GET_CUR_ADC_PARS. Это не вручную устанавливаемые значения а возвращаемые АЦП.
Итак имеем: 1 канал, частота 400 кГц, частота кадров 1 кГц, межкадровая задержка 1 мсек. Количество отсчётов 3840. ControlTable: 32,1,2,3,4,5,6,7,-3108,-3108... 

И ещё несколько слов в порядке рассуждения на тему о том, что LabVIEW вроде как "непричём".
1. Из  LabVIEW запускается асинхронный процесс чтения данных из виртуального файла-слот_0 (читай АЦП) (WINAPI функция ReadFile). Этот процесс управляется только операционной системой и файлом , который по готовности выставляет для чтения половинки буфера и флаг готовности. Процесс от LabVIEW не зависит. Не должен!
2. Почти одновременно (т.к. ф-я ReadFile быстро завершается с ошибкой ERROR_IO_PENDING и дальше мы имеем асинхронный процесс считывания данных ) из  LabVIEW запускается другой процесс - периодически проверяется наличие события GetOverlappedResult - закончено ли считывание заказанного количества отсчётов (цикл WAIT). Этот цикл выполняется до момента наступления события и периодичность его повторения определяется частотой внутренней синхронизации в системе "Операционная Система"( Windows) - LabVIEW. Не выжно какой точно, но весьма большой. Этот цикл ожидания никак не может влиять на выполнение самого асинхронного процесса считывания данных, а сам цикл контролируется CIN WAIT. А это уже серьёзно, поскольку CIN берёт контроль над процессом в котором он выполняется! Но вроде бы для нас это не страшно, даже наоборот - бастрее должен среагировать на наступление события. Как только ожидаемое событие наступает - цикл ожидания должен прекратиться (весьма быстро) и мы должны получить ожидаемую порцию данных. А он прекращается с задержкой в 3-4 секунды при частоте кадров 1 кГц.
ВОПРОС: почему?

Кстати, я уже пасал в одном из предыдущих сообщений, что на примере от Л-КАРД под названием E440LV Oscilloscope точно такой же эффект задержки. Я же всё сказанное выше наблюдаю в консольных приложениях на С++ и в написанном мною очень простом приложении на LabVIEW, позволяющем детально и удобно изучать процессы инициализации АЦП и последующего сбора данных.

Как говорил один известный киногерой: "Давайте не будем нервничать и спокойно во всём разберёмся".

1. Об опечатках ...
Я попросил у Вас всего лишь список найденных опечаток и ошибок. У нас нет штатных редакторов и бета-тетстеров, поэтому большую роль в выявлении всякого рода недоработок играют сами пользователи. А посему они не могут быть врагами ))

2. Об классах ...
а. Насколько помню, я ни в конференции, ни в тех.поддержке никому никогда не советовал заниматься перекомпилляцией библиотеки. Даже не знаю откуда у Вас такая информация. Штатная библиотека без проблем подключается и к Borland C++, и к Visual C++, и к Delphi. Так что если нет совершенно острой необходимости в изменении поведения библиотеки, то перекомпиляцией
заниматься нет никакой нужды.
б. Наша продукция изначально расчитана на достаточного грамотного пользователя, поскольку мы не предлагаем ему никаких законченных приложений, только драйвера, библиотеки и примеры программирования. Поэтому задача создания приложений под конкретные требования пользователя полностью ложится на его плечи. Правда есть возможность воспользоваться приложениями сторонних производителей (см. www.actech.ru или www.powergraph.ru)

3.  О ADC_PARS_E440 ...
Применяя обычный поиск, можно найти использование локальной структуры TLE440::am в следующих функциях (файл E440.cpp):
а. START_ADC()
б. ADC_KADR()

4. О ControlTable ...
У меня такого поведения элементов управляющей таблицы не проявилось. Засылайте Ваш код, будем разбираться.

5. О неправильном времени сбора ...
Судя по приведённым временам, Вы задаёте длину FIFO буфера модуля равным 12288 (половина FIFO равна 6144). Если это так и Вы зададёте PointsToRead = 3840, то при вводе данных модуль пока не насобирает 6144 отсчётов, он ничего в РС отсылать не будет (см. тех.описание на ф. FILL_ADC_PARS и http://www.lcard.ru/forumthreads/2962). При указанных Вами параметрах время сбора должно быть порядка 6 сек.

Добрый день!
Кажется диалог начался по существу дела и это радует.

По поводу структуры TLE440::am теперь всё понятно. Спасибо. Это всё что я хотел узнать.

По поводу ControlTable.
Это не проблема а интересный эффект. Но поскольку он не мешает работе АЦП, то и оставим его в покое. Это больше интересно разработчикам АЦП.

Насчёт классов. Это Вы лукавите. В конференции неоднократно написано, что в случае с E440 Вы пошли навстречу пользователям и написали библиотеку-враппер. Но это вроде как любезность с Вашей стороны. Во всех остальных случаях делайте это сами или перекомпиллируйте DLL так, чтобы сделать все нужные функции экспортируемыми.

По поводу очепяток. Если речь идёт о бета-тестировании, то это понятно. Делаем всем миром. Если речь идёт о примерах и документации, то данное объяснение, извините, не принимается. И как это Вы ловко поделили мир на две части: достаточно и недостаточно квалифицированные пользователи. Обычно выделяют категорию бета-тестеров, на которых "валят" сырой материал и выискивают с их помощью всевозможные ошибки и очепчтки. А дальше следуют просто пользователи, которые этими проблемами абсолютно не должны быть обременены.

По поводу неправильного времени сбора.
Суть проблемы видимо заключается в следующем: в каких единицах измерения задана длина FIFO буфера модуля равная 12288 ? Это пожалуй всё, что мне нужно от Вас узнать. Это последний вопрос.

От себя добавлю...
Есть ли возможность выложить принципиальные схемы и прошивки МК ваших устройств. Просто копаясь в исходниках и примерах многие вещи не очевидны или просто непонятны. А когда видишь схему или алгоритм работы программы МК, становится все предельно ясно.
Я не думаю, что вы таким образом раскроете своим конкурентам свои козыри. Судя по e140-e440, устройства весьма просто устроены. Более-менее грамотный электронщик сможет по аналогии спаять свое, возможно даже совместимое по драйверам. Только какой в этом смысл если можно купить готовое.
А вот когда самостоятельно пишешь свое ПО (вы как раз на это и делаете упор), схемы и прошивки были бы очень кстати. Вы же все равно ничего не теряете , а приобретаете более подкованных "тестеров" и программистов, которые благодаря этому могут работать эффективней.
И такого рода вопросы сами бы и отпали.

1. Ещё раз повторюсь: штатная библиотека без проблем работает с С++ и Delphi, при этом никакой перекомпиляции не требуется. Поддержка именно в этих средах и была официально обещана. Если же Вы, по личной инициативе, решили 'прикрутить' библиотеку к программной среде, которую 'L-Card' не поддерживает (как то LabVIEW, MatLab и т.д.), то в такой ситуации Вам, конечно же, придётся самому перелопатить библиотеку, чтобы корректно состыковать её с требуемой средой (благо все исходные тексты предоставляются).
Что касается LabVIEW... Хотя официально поддержки этой среды у нас нет, но, как Вы правильно заметили, 'L-Card' проявил любезность и предоставил набор примеров.

2. Как я понимаю, списка найденных опечаток и ошибок мы так и не увидим.

3. Ещё раз повторюсь: в 'L-Card' нет штатных редакторов и бета-тетстеров. Насколько это возможно весь сырой софт мы прорабатываем сами. Но определённая доля недоработок всё равно остаётся. И пользователи весьма активно помогают нам в выявлении оставшихся недочётов. За что им большое спасибо.

4. О разделе мира на две части...
Ещё раз повторюсь: сам факт покупки изделия от 'L-Card' предполагает, что Вы являетесь достаточно грамотным пользователем. В частности, Вы должны чётко знать зачем Вам это изделие нужно и в каких программных средах штатное ПО позволит с ним работать. Иначе всё это не имеет совершенно никакого смысла. Это примерно тоже самое, что будучи человеком не имеющим никакого отношения, допустим, к металлообработке, взять и купить токарный станок.
Так что в этом смысле мир, конечно же, поделен на две неравные части: те, кому наличие изделия от 'L-Card' принесёт пользу, и остальные.

5. Как это следуте из тех.описания длина FIFO буфера задаётся в отсчётах, т.е. в 16ти битных словах.

6. Принципиальную схему модуля Е-440 могу без проблем выслать по Вашему запросу. А вот насчёт прошивки AVR Вам нужно обратиться напрямую к нашему руководству.

1. По поводу опечаток и ошибок. Я не Ваш бета-тестер, и просто так это делать я не буду. Хотя я пытался об этом начать говорить - посмотрите данную тему сначала - но это вызвало глухое раздражение у технических специалистов Л-Карда. Что, естественно, отбило всякую охоту продолжать разговор на эту тему. Они даже перестали отвечать на мои вопросы. Хотя это была информация больше для них, чем для меня. Ну и ладно. Проехали...
2. За предоставленную информацию об устройстве буфера FIFO - спасибо. Теперь всё сходится. Больше вопросов нет.

1. Вы поймите правильно: я же не заставляю Вас круглосуточно сидеть и целенаправленно выявлять всё недочеты присущие данному модулю (что и является бета-тестированием). Я всего лишь просил присласть список тех недоработок, которые Вами уже обнаружены в процессе работы с модулем. Ведь это ВАЖНО не только мне лично или 'L-Card', но и всем пользователям данной продукции. ))

2. Принципиальные схемы на  E14-140 и  E14-440 высылаю через е-mail.

О разделе мира на две части... (с опозданием)
Мир не дискретный, он непрерывный. И все дискретные устройства к этому стремятся увеличивая свою разрядность и соответственно число градаций. Вот и я - какой-то средний пользователь, который иногда считает себя грамотным, в данном случае ПРОСТО хотел бы иметь dll в которой экспортируются ВСЕ функции. Могу привести пару аргументов чтобы не показаться смешным и быть услышанным. Во-первых я - клиент L-Card - покупал и покупаю у них оборудование. Во-вторых это простая и понятная попытка заменить Е330 на Е14-440 при решении определенной задачи. И решение такой задачи  (некий upgrade) L-Card, кажется, мог бы максимально  облегчить для пользователей. Я знаю, что я и сам это сделаю, но зачем, ведь велосипеды мы УЖЕ покупаем готовыми. В основном. А некоторые - в коробке. А некоторые по частям и собирают сами. Мир пользователей также многообразен. И расширение сферы охвата - задача любого маркетинга.
Короче, если кто-либо не сочтет за труд выслать, буду благодарен.

Скачайте архив http://www.lcard.ru/download/e440lv.exe
Там в директории /E440LV Oscilloscope можно найти библиотеку-оболочку с "чисто" экспортируемыми функциями.

У МЕНЯ ТЕПЕРЬ ВСЕ РАБОТАЕТ,КРОМЕ перевода в матфайл
где мне взять mat.h,который подключен в файле matcreat.c
но при компиляции выдает ошибку
MATFile *pmа
неизвестный идентификатор

А что это такое матфайл,  matcreat.c, mat.h ... ? И где Вы это нашли?

это прилагается на вашем диске в папке matrix
переводит наш бинарный файл в матфайл

1. За последние 8 лет на фирменном CD-ROM такой папки как matrix не существовало.
2. Не совсем понятно, что именно Вы имеете в виду под "переводом из двоичного файла в десятичный формат"? Алгоритм, исходные тексты, программа ... ? А каковы форматы  двоичного и десятичный файла?