Господа Разработчики! Не сочтите этот вопль за посягательство на вашу интеллектуальную собственность (ведь в таком виде API когда-то уже поставлялось с модулем)! Но, кажется вы совершенно зря закрываете доступ к своим исходникам на C++. Если бы коды функций были более просты в осмыслении, они стали бы более просты в применении. Тогда мы, потребители API, не винили в ошибках и недоработках (см. тему про скорость обмена с модулем) вас, а могли винить только себя за недостаточную квалификацию. Сейчас же я (я думаю, я не один такой), получив задание разработать и собрать прецизионную экспериментальную установку, неделю своего отпуска
потратил на написание и отладку СОБСТВЕННОГО модуля, обеспечивающего интерфейс с E24.
А ваша API (взять хотя-бы функцию InitE24) правильно работала через раз. И если дело в кабеле, то кому как не вам, разработчикам ВНЕШНЕГО модуля(и кабеля, как составной его части), заботиться обо всех тонкостях своего изделия. Зато теперь на вашем сайте не найти вообще никаких библиотек API для Е24. Ни новых, ни старых.
Может быть, единственное прецизионное АЦП среди вашей продукции стало неперспективным, и нет лишних ресурсов времени на его поддержку? Но модуль на 2-х AD7714 и 1-м Atmel-e стоит 333 у.е.. А это в России пока деньги. Неужели человек, купивший когда-то ваш АЦП должен платить еще неделю своего отпуска (правда, не вам), чтобы он заработал? Как сказал бы мой шеф, Господа Разработчики, "Так работать недопустимо!".

1. Если у Вас были проблемы с API для E-24 лучше всего было бы сразу об этом здесь и написать - мы бы постарались разобраться.
2. Насчет AD7714 - из там вроде как 4
3. Из сообщения не совсем понятно:
- под какой ОС происходит разработка?
- на каком языке Вы работаете?
- Ваш модуль в результате заработал или же проблема осталась?
4. Я бы все же предложил перейти на более дружественный тон - мы всегда стараемся помочь нашим клиентам, если у них возникают проблемы с оборудованием.

Могу еще добавить, что на CD-ROM, поставляемом с E-24, исходник API лежит в директории //LPT_COM//E24//BC50//dll//.

Извините за тон письма. Просто шеф говорил со мной еще более жестко, и совершенно по-делу - я был виноват. АЦП этот у нас используется довольно давно. Раньше он работал в другой установке, из которой (за срочной надобностью прецизионности) был временно извлечен(аккуратно, и вместе с кабелем). Это двухканальный модуль. Почему он такой - я не знаю. Покупался он вместе с прибором еще до моего прихода в шефовладение(думаю, году в 1999). Диска, естественно, к нему не прилагается. По крайней мере, шеф мне сразу сказал:"Пиши все сам". А я, вдохновившись описанием, решил использовать библиотечные функции. Нашел поиском на машине шефа (О удача!) е24api.dll... Получил за его использование (точнее, за "Все еще!" не работающий регистратор) по шее... И писал принимающие данные функции и инициализатор сам.
Писал я их под Windows на MS VC++ 6.0. Кстати, я бы никогда не возмутил вашего спокойствия, если бы не решил в (кои-то веки!) поискать "е24" вашей поисковой машиной - вдруг e24api.срр найдет? Она мне выдала тему про злоключения со скоростью передачи данных. Тут я уже не выдержал и решил написать - уж больно красив был диалог Автора и вашего сотрудника Павла. Все кто меня читает! Слушайте шефов! Пишите интерфейс ко всем железякам сами! Лучше всего - на уровне машинных команд для контроллера! Не наступайте на мои грабли!
А за тон еще раз извините, я к всеобщему сожалению еще молод и ко многому не привык.
За помощь спасибо, приму к сведению. Судя по скорости и содержимом реакции на мою реплику, в случае наступания на очередные грабли, может быть, удастся спасти голову. Но, все равно, людям, посещающим ваш сайт по профессиональной надобности, было бы очень приятно и полезно увидеть исходники e24api.dll в виде -//-.сpp в библиотеке. Спасибо за выдержку! И еще раз извините за критику, надеюсь конструктивную.

О! Один Ваш вопрос я пропустил. Модуль заработал.
При инициализации я сначала изменил dcb ком-порта так, чтобы ReadFile() ждала 100 мс а затем по 50 мс на каждый читаемый байт (а их там 7 читается; может 50 и много, но так надежнее, а быстрее мне, слава Богу, ни к чему). Подавал питание на RTS, открывал ком-порт для чтения, читал свои 7 байт  Затем устанавливал dcb-"читательные" члены так, чтобы припоследующих обращениях функция тут же возвращала, что прочитала, делал порту SetCommTimeouts (если я правильно воспроизвел название функции установки интервалов чтения-записи,.. может - SetFileTimeouts - я уже точно не помню) с измененным dcb. Вроде работает. А при чтении - я включил в модуль кроме собственно чтения еще и то, что делает ConvertE24Block и валидизатор посылок, восстанавливающий первую нецелую посылку серии новосчитанных данных по отброшенной в буфер нецелой голове предыдущей порции, замещающий единичный инвалидный отсчет средним арифметическим по следующему и предыдущему по времени отсчетам данного канала, если они есть, если следующего пока нет - делающий отсчет равным предыдущему. Может быть, я в чем-нибудь не прав (у меня, например, есть серьезные подозрения, что нельзя управлять таймаутами чтения уже открытого файла), но как не странно, все пока работает...

Судя по всему у Вас старая версия API. Кстати, на нашей конференции эта проблема уже обсуждалась и была решена (тред http://www.lcard.ru/forumthreads/120). Павел сегодня выложит в библиотеку файлов свежую версию с исходником.