Имею:
WinXP SE2
Delphi7
E14-440
Библиотеку и драйвер из последней версии (3.0)
Немного измененный БИОС - добавлено усреднение показаний АЦП по 4, сравнение с записанной в ОЗУ переменной (порогом), в случае превышения - вывод 0 в один из битов выходного регистра.
В процессе работы примерно раз в секунду производится _последовательно_ (по командам с РС):
- установка параметров АЦП и его запуск
- вывод информации в выходной регистр (цифровые линии)
- запись данного в ЦАП
- запись данного в ОЗУ (порог)
- вывод информации в выходной регистр
- периодическое считывание показаний АЦП - с паузами в десятки мс
- установка параметров АЦП
- вывод информации в выходной регистр
- запись данного в ЦАП

Все указанные функции DLL вызываются впрямую, без использования GetOverlappedResult, но там ждать, собственно, нечего.
Сделана защита от перекрытия вызова функций - собственными флажками.
В случае, если функции возвращают отрицательный результат, сделаны повторы вызовов через паузы в 50 мс (до 3 раз).
Вся эта последовательность постоянно рушится, то есть даже три повтора не дают положительного результата. Нормальная работа продолжается в среднем не более 5 ..10 секунд. Наиболее часто не выполняется функция вывода данных в выходной регистр.
Несколько помогает увеличить время нормальной работы паузы в 150 мс после вызова каждой функции. Но вероятность отказа все равно остается - просто несколько уменьшается. Да и такой подход неприемлем для устройства - нужно все делать быстро.
Пару лет назад уже был опыт использования модуля в аналогичном устройстве, только там использовалась Win98. Отказы тоже проскакивали (именно тогда появились повторы вызовов), но были крайне редки. Сейчас просто не дают работать.
Замена библиотеки с версии 2 на версию 3 не дала ничего - эффект остался неизменным.
Заранее спасибо за ответы.

1. У модулей Е-440 с ревизиями от A до D есть глюк. При одновременной работе АЦП и ТТЛ выходов у модуля часто сносит крышу. Вам требуется небольшая аппаратная доработка  http://www.lcard.ru/forumthreads/2817
2. Фразу "Все указанные функции DLL вызываются впрямую, без использования GetOverlappedResult..." я совсем не понял. Можно ли добавить каких-нибудь пояснений.

По п.2. В примерах есть две скудные программки чтения АЦП и записи в ЦАП. Там использована эта функция. Ожидание выполнения функций чтения и записи сделаны через нее. Я догадываюсь, что это связано с большим объемом данных и длительным временем их чтения (записи). Я же просто вызываю функции DLL, и надеюсь, что функция возвращает результат только после _окончания_ физического обмена по USB.
По п.1. Прикольно. Мы покупали модули отнисительно недавно, ну явно не в 2005, когда был обнаружен глюк. И в 2007 их нужно везти на доработку??? Ревизию я уточню завтра.
Может, Вы поясните, _что_ нужно дорабатывать? Все равно ваши коробки мы вскрываем - нам проще будет сделать доработку самим.

Описанное Вами поведение модуля, было детально исследовано только в середине 2006 года. В настоящий момент производятся модули ревизии "Е", в которых эта проблема устранена. Обсуждение этого уже было на форуме - http://www.lcard.ru/forumthreads/3527.
Устранить этот недостаток в ревизии модуля "D", Вам возможно самостоятельно и удастся, а может и модуль испортите, Вам оно надо? Привезите модуль на доработку, за час доработку в цеху сделают.

Спасибо, Владимир. Видимо, привезем.

Евгению. По п.2.
Настоятельно рекомендую использовать функции ожидания завершения выпролнения асинхронных запросов: WaitForSingleObject(), GetOverlappedResult() или HasOverlappedIoCompleted(). Без их использования вполне можно найти себе ненужные приключения.

Сергей,
хотелось бы уточнить.
Что, ВСЕ функции (задать параметры ЦАП и АЦП), прочитать или записать ячейку ОЗУ, читать или писать цифровые линии и т.п. - завершаются как бы не дождавшись результатов обмена?
Еще раз. Я _последовательно_, _в одном потоке_, вызываю, например, задать параметры в ЦАП и задать параметры в АЦП, затем запустить АЦП. Что, реально могут быть проблемы???
Какие функции DLL, связанные с обменом по USB, _реально_ требуют такого ожидания? Не хотелось бы городить горы кода без нужды.
Ваше замечание тем более странно, что в примере инициализации модуля ничего такого не применяется. Там все последовательно, без извращений.
Еще раз повторю. _Я сам_ разберусь с неналезанием вызовов из разных потоков. Этого достаточно?

Я же вроде бы написал, что речь идёт о выполнении асинхронных запросов, т.е. о функциях ReadData() и WriteData(). Как нетрудно было заметить в наших консольных примерах, именно эти функции использовались с упомянутыми выше функциями ожидания. Эту же информацию можно было бы почерпнуть и из тех.описания.

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

Извиняюсь, что не по обсуждаемой здесь теме.
Вопрос о возможностях использования Е14-440.

Возможно ли подключение Е14-440 непосредственно к термопаре?
Ведь напряжение на от термопары порядка нескольких милли вольт, будет ли Е14-440 достаточно чуствителен, что бы зафиксировать его?

Юрий.
Скорее всего нельзя. Диапазоны несопоставимы.

Вынужден продолжить обсуждение.
Получили новые Е14-440 ревизии Е. Обновил БИОС.
ЛУЧШЕ НЕ СТАЛО.
Разобрался, что происходит. По-моему совершенно немотивировано, периодически, функции DLL (НЕ ПОТОКОВЫЕ) возвращают false. Функция определения последней ошибки выдает всегда "Ошибка 320. Не выполнена фукнция Send_Command() Не удалось передать номер команды в LBios." Примерно так.
Причем, иногда помогает повторный вызов несработавшей функции через небольшую задержку, а иногда все отваливается окончательно, помогает только переинициализация модуля.
ЭТО ЧТО?

Господа авторы девайса. Не отмалчивайтесь, плз. Помогите - не работает же как должно.

Засылайте свой софт. Будем посмотреть.

Э-э-э. Какой?
Могу измененный биос.
С самой программой - затрудняюсь. Это все-таки очень большая программа - станок все-таки. Много разных блоков, подключенных к компу. На USB только Ваш.
Постараюсь как-то вычленить куски, связанный с Вашим девайсом, но это крайне затруднительно.
А просто сымитировать частое обращение к чтению и записи цифровых сигналов, задания параметров АЦП и запуска его, вывод данных в ЦАП, чтение и запись ОЗУ - все это вперемешку - самостоятельно не можете? ReadData и WriteData не пользую.
Может, поясните, по каким причинам в принципе указанная ошибка может появляться? Может , там какой таймаут маловат? А то эффект появляется чаще при включении видеоканала - через плату видеозахвата в компе.

1. "...частое обращение к чтению и записи цифровых сигналов, задания параметров АЦП и запуска его, вывод данных в ЦАП, чтение и запись ОЗУ - все это вперемешку... ReadData и WriteData не пользую". Т.о. среди прочего выполняется запуск как АЦП, так и ЦАП, т.е. используются функция START_ADC() и START_DAC(). Но зачем же это делать если впоследствии не использовать функции ReadData() и WriteData()? Как же Вы тогда собираете с АЦП или выводите на ЦАП необходимые данные?
2. А если временно не задействовать плату видеозахвата, то эффект остаётся в силе?
3. А если запользовать штатный LBIOS, то эффект остаётся в силе?

1. Я дописал БИОС - усреднение отсчетов АЦП по 4 последним - помещаем в ячейку ОЗУ, сравнение с другой ячейкой ОЗУ, задаваемой из программы на РС, при выполнении определенного условия при указанном сравнении - вывод 0 в младший разряд цифровых данных. Читаю в качестве показаний АЦП именно ячейку ОЗУ, где лежат усредненные отсчеты. Читаю не очень часто - важнее быстрый вывод 0 в цифровые данные.
В ЦАП вывожу два раза за цикл (длительность цикла и паузы между циклами определяется действиями оператора и может составлять от долей секунд до десятков секунд) - записываю некое значение в начале цикла, по окончании - записываю 0. Здесь, возможно, есть лишние действия, но пока так. Для вывода в ЦАП использую DAC_Sample.
2. Остается, но ошибки появляются несколько реже. 3. Штатный БИОС в реальной программе использовать нет смысла - он не делает то, что нужно для реальной работы.

Подумаю насчет имитационой программы, но на это требуется время.

Всё-таки попробуйте штатный LBIOS. На данном этапе совсем не важно то, что он работает не так как Вам требуется.

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

Тут еще одна мысль есть. После выполнения условия сравнения (усредненных показаний АЦП и данных в ячейче ОЗУ (порога) я начинаю с частотой опроса АЦП (100кГц) вызывать функцию IO(TTL_OUT)=AR;
Это не страшно?

Не страшно.

Спасибо. Возьмем небольшую паузу. Постараюсь сляпать программку, из которой все выброшено, кроме Е440. Сымитирую. Попробую с Вашим БИОСом. Потом продолжим.

Программку сляпал. Попробовал на совершенно пустой машине - ничего лишнего в ней нет. Результат - виноват измененный мной БИОС. Со штатным биосом все работает.
Изменения в БИОСЕ:
1. В Var.h добавлены 2 новых переменных

{ ZeroOffset array for all gains                                                   }
.VAR/SEG=INT_PM_USER/ABS=ZeroOffsetAddr/PM/RAM ZeroOffset[4];
.INIT ZeroOffset:          M(0x0), M(0x0), M(0x0), M(0x0);

{-- ---------------------------------------------------------------------}
{ Начало моей вставки}
{ Текущее значение с АЦП - будем читать }
.VAR/SEG=INT_PM_USER/ABS=CurrADRESAddr/PM/RAM CurrADRES;
.INIT CurrADRES: M(0x0);
{ Пороговое значение АЦП - будем сравнивать }
.VAR/SEG=INT_PM_USER/ABS=ThresholdAddr/PM/RAM Threshold;
.INIT Threshold: M(0x0);
{ Конец моей вставки}
{-- ---------------------------------------------------------------------}

2. В Const.h определены их адреса
.const    ZeroOffsetAddr                    =    VariableBaseAddress + 0x34;
{-- ---------------------------------------------------------------------}
{ Начало моей вставки}
.const    CurrADRESAddr                    =    VariableBaseAddress + 0x38;
.const    ThresholdAddr                    =    VariableBaseAddress + 0x39;
{ Конец моей вставки}
{-- ---------------------------------------------------------------------}

3. В ADC.h вставлены следующие действия после получения и корреции очередного данного:
  а. Суммируются 4 последних отчета АЦП и кладутся в ячейку CurrADRES
  б. Данное в указанной ячейке сравнивается с данным в ячейке Threshold
  в. Если первое меньше второго, то бит 0 TTLOut обнуляется, и исправленное значение TTLOut выводится.
Получилось вот что:

    AR = IO(READ_ADC);
    AR = AR + AY1, AY1 = PM(I6,M6);
    MR = AR * MY1(SU), MY1 = PM(I6,M6);
    MR = MR(RND); DM(I3, M3) = MR1;
{-- ---------------------------------------------------------------------}
{ Начало моей вставки}
{ Усредняем несколько последних значений }
    M3 = -1;
    MODIFY (I3,M3);
    AY1=DM(I3, M3);
    AR = 0;
    CNTR=4;
    DO MyL2 UNTIL CE;
        AR=AR+AY1,AY1=DM(I3, M3);
MyL2:         NOP;
    M3 = 6;
    MODIFY (I3, M3);
    M3=0x1;
   
{ записываем в ячейку "текущее данное с АЦП" и сравниваем с порогом }

    PutPm(AR,CurrADRESAddr);
    AY1=AR;
        GetPm(AR,ThresholdAddr);
    AR=AY1-AR;
    IF LT JUMP MyL1;
    GetPm(AR,TtlOutAddr);
    AR = TSTBIT 0 OF AR;
    IF EQ JUMP MyL1;
    GetPm(AR,TtlOutAddr);
    AR= CLRBIT 0 OF AR;   
    IO(TTL_OUT)=AR;
MyL1:   
    AY1=PM(I6,M6);
    MY1=PM(I6,M6);
    M3 = 0x1;
{ Конец моей вставки}
{-- ---------------------------------------------------------------------}
Честно признаюсь, в асме ADSP я как свинья в апельсинах, и разбираться нет никакой возможности.
Слезно прошу - посмотрите, я ничего не напутал? В принципе, указанные действия выполняются правильно, однако связь по USB периодически рвется (тут, впрочем, почти никакой закономерности - может работать и час, а может прерваться и через 10 секунд). Без этих исправлений - с исходным биосом - все в норме. Может, я какие-то ячейки использовал, которые что-то портят в других частях программы?

В обработчике прерываний нельзя просто так использовать макросы PutPm и GetPm. Вернее можно, если предварительно сохранять где-либо регистр I4, как это сделано, например, в функции EnableSynchroPulse.

Сергей!
Слезно прошу - нипишите как нужно. Для Вас это 3 минуты, а я ж помру.