Требуется одновременно считывать состояние цифровых датчиков (f=5..10 Гц), считать прямоугольные импульсы по 2 каналам (с угловых датчиков (f=600 Гц),  выводить цифровые данные(f=5..10 Гц), и считывать аналоговые сигналы по 2 каналам (f=5 Гц). И все это одновременно. И все это в Delphi.
  Как пробовал сделать.
Создал отдельный постоянно действующий поток, в котором в цикле:
1) -опрашивается цифровой порт(TTL_In_PLX) + отслеживаются два бита, соответствующие счетным входам и соответственно программно изменяются показания счетчиков.
2) -через каждые 20 опросов цифрового порта производится запись в цифровой порт(TTL_Out_PLX) и чтение данных с 2 каналов АЦП (ADC_Sample_Plx)
  А вся остальная обработка идет в основной программе, где в т.ч. подготавливаются выходные биты для дальнейшей загрузки в порт.
  В принципе - работает. Но есть существенная погрешность счета. Наблюдается эффект пропадания некоторых импульсов с повышением входной частоты до 600 Гц. Я думаю это из-за непостоянства интервалов времени между соседними выборками в отдельном потоке и соизмеримости максимальной частоты опроса цифровых входов с частотой входного сигнала.
  Можно ли что-то придумать для моего случая (карта L-761).
  Буду очень признателен за совет.
   

На уровне DSP реализовать все это относительно просто, используя таймерное прерывание для ввода и вывода дискретных сигналов, а для аналоговых - стандартные действия из штатного bios/

А можно поподробнее (желательно не на уровне DSP - это для меня неподъемно)

Без DSP можно только один канал счета импульсов: завести его на вход цифровой синхронизации и тогда число отсчетов в FIFO-буфере на ПЭВМ будет соответствовать числу импульсов. При этом можно опрашивать и аналоговые каналы по этому импульсу (используя в Delphi функции библиотеки для потокового ввода), тогда необходимо только их прореживание.
Второй канал счета рекомендую организовать, дополнив штатную bios короткой подпрограммой обработки прерывания IRQL1 (вход INT цифрового разъема) типа

Irql1Handler:
ENA SEC_REG;
AR=DM(Count2);   // ячейка памяти с результатом
                  // счета импульсов
AR=AR+1;
DM(Count2)=AR;
RTI;

Обломись бабка - в дельфях такое не делают.
А под виндой "эффект пропадания отдельных импульсов" будет наблюдаться всегда
И даже предложение Victoria/'и не поможет

To:Victoria - импульсов там два быстрых, значение которых надо знать одновременно и несколько медленных

To: Рамиль
Насколько тут нужна жесткая синхронизация дискретных, аналоговых и каналов-счетчиков (условия одновременности) по условиям задачи?

То: Папа Карло
счет импульсов и считывание - разные понятия, может и необходимо знать одновременно знать число импульсов по обоим счетчикам, но не с частотой же 600 Гц (это опять вопрос к автору темы)

To Victoria:
для угловых датчиков одновременно надо смотреть на два сигнала, так называемые синус  и косинус.
Более того, есть подозрение что 600Гц надо умножить на 4 и еще на 2(чтобы гарантировать непропуск импульсов)

1. Меня бы устроило если счетчики считали импульсы двух входящих сигналов с частотой 600 Гц и заносилось бы это дело в две переменные в плате. А я бы по мере надобности (с частотой не более 10..20 Гц) считывал бы их значение из платы (каким-то образом).

2.Никаких особых требований по синхронизации остальных входов и выходов не предъявляется. Посредством них производится мониторинг состояния датчиков и управление исполнительными механизмами. А частота опроса и вывода (5..10 Гц)чисто условна и выбрана из такого соображения, что хотелось бы, чтобы задержка на срабатывание исполнительных механизмов в зависимости от состояния датчиков и счетчиков не превышала ~0.2 сек. ( По крайней мере в таком районе)

3. Да, а насчет синусов и косинусов париться не стоит - используется лишь по одному выходу с датчиков (точность устраивает, а направление не нужно). Т.е. простые прямоугольные импульсы  возможно с переменной частотой (но до 600 Гц).

Вы хотите сказать, что угловых датчиков тоже два ??
Может тогда расскажите более подробно, что это за такое устройство и чего вы от него хотите

Рамиль: Меня бы устроило если счетчики считали импульсы двух входящих сигналов с частотой 600 Гц и заносилось бы это дело в две переменные в плате.

Ничего не приходит на ум, кроме как использовать дополнительные логические элементы на входе INT (лог. сложение? обоих импульсов), а в подпрограмме обработки прерывания считывать состояния обоих дискретных входов, и анализируя их инкрементировать соответствующий счетчик

//Вы хотите сказать, что угловых датчиков тоже два ?? 
Совершенно верно.
//Может тогда расскажите более подробно...
С удовольствием проясню тему (немного упуская неинтересные подробности).
Есть некая установка - ф-ция которой смешивание двух компонентов. Компоненты подаются из двух дозаторов (цилиндр+поршень) . А ход этих поршней (т.е. кол-во подаваемых компонентов) отслеживается с помощью этих самых угловых датчиков (поршень-трос-ролик-угловой датчик), которые вырабатывают N импульсов на 1 мм хода поршня. Для того чтобы правильно управлять работой установки, в определенные моменты времени (но с частотой не более чем 10 Гц, ну... 20-идеал) мне нужно знать положение обоих дозаторов. Это про счетные входы.
  Просто цифровые входы - датчики-концевики. Сейчас опрашиваю с частотой 5 Гц, в принципе уже устраивает.
  Аналоговые входы - 2 шт, контроль давления 2 компонентов (точность не требуется) для выработки аварийного сигнала. Давление - достаточно медленно меняющийся процесс, достаточно 2..5 выборок в сек.
  Цифровые выходы - управление исполнительными механизмами (в т.ч. дозаторами) в соответствие с программой обработки входных данных.
  Вот такая карусель...
//и чего вы от него хотите
Меня бы даже устроило если количество "пропадаемых" импульсов увеличивалось с ростом частоты, но пропорционально и предсказуемо, тогда бы я программно предусмотрел поправку, на практике же это не так. Тем более дозаторы могут перемещаться с разной скоростью, поэтому и частота будет разная, соответственно и количество непосчитанных импульсов по разным каналам будет разным. Все эти проблемы снимаются если счет идет точный, а доступ к счетчикам устроит со скоростью не более 10 Гц.
  Прошу прощения, постарался донести проблему поподробнее.

To: Victoria @ All
Где-то видимо ввел в заблуждение. Подчеркиваю два входящих сигнала (имульсы которых нужно посчитать) абсолютно независимы друг от друга, и могут иметь разную частоту (от 0 до 600 Гц). Нужно независимо считать количество имульсов первого и второго сигналов. Т.Е. в итоге нужно поиметь два независимых счетчика.

На L783 я бы не задумывалась, и для второго счетчика использовала бы аналогичную подпрограмму обработки второго прерывания (прерывания цифровой синхронизации, у которой и вход свой), т.к. в Вашей задачи цифровая синхронизация опроса АЦП точно не используется.
С L761 у меня нет уверенности, т.к. эта функция цифровой синхронизации вроде бы исполняется дополнительным микроконтроллером AVR. Поэтому я предложила первый свой вариант. Будете опрашивать по мультимедийному таймеру число новых отсчетов в этом буфере - и это будет соответствовать числу импульсов второго счетчика. Минус - ADC_Sample уже нельзя будет использовать. Придется прореживать отсчеты АЦП из буфера.

Во-первых, ваши дозаторы могут двигаться совсем не в том направлении, куда вы думаете, что они должны двигаться. Во-вторых за счет этого у вас тоже будет набегать неконтролируемая ошибка.
В третьих, в интересных подробностях, возможно, опущены проблемы с помехами/наводками, от которых тоже некотнролируемая ошибка...Пинайте вашего электронщика или электрика
В четвертых, если уж так сильно хочется делать через одно место - то возможны два варианта - либо итди в голый дос, либо изучать что такое приоритет в винде и как его задрать.
В пятых, еще один вариант - рожать внешнее прервание от изменения "суммы двух сигналов" и так далее.При этом надо пинать электронщика....
В шестых опять можно пробовать пинать электронщика  ;-) для установки внешних счетчиков и канала для считывания их показаний

А что скажет общественность на такой вариант решения проблемы.
  Подавать счетные импульсы на аналоговые входы (я так понимаю карта позволяет вводить аналоговые сигналы с такой частотой ~600 Гц "без потерь"). Как я себе это представляю -
Накапливается в буфер определенная последовательность отсетов 4 аналоговых сигналов (2 счетные + 2 давление). Пока идет накапливание я опрашиваю цифровые входы и вывожу данные в цифровой порт, затем считываю из буфера выборки и программно их так сказать разделяю и каким-то образом обрабатываю (ищу переходы сигнала через 0) и получаю кол-во импульсов по каждому каналу, а в это время в буфере продолжается накопление.
  Возможен ли такой режим работы ? (Имеется в виду одновременная работа с буфером, цифровыми входом и выходом).

To Папа: "Вашими" источниками возникновения погрешностей пренебречь и из рассмотрения исключить.

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

Если есть руки, то можно вывести irql0 на цифровой разьём также как и irql1. Можно попросить в ЛКарде сделать, чтобы не терять гарантию.

> отслеживается с помощью этих самых угловых датчиков
> (поршень-трос-ролик-угловой датчик), которые вырабатывают
> N импульсов на 1 мм хода поршня.

А какой тип датчиков? тип преобразования, алгоритм или если есть дока с описанием.

/А какой тип датчиков? тип преобразования,
/ алгоритм или если есть дока с описанием
To Стас: Да никаких преобразований и алгоритмов. Обычный "щелевой" датчик, стоит оптопара. Непрозрачный диск с "нанесенными щелями" вращаясь провоцирует появление на выходе оптапары прямоугольных импульсов ТТЛ уровня. Вот и получается - крутим диск, получаем прямоугольные импульсы, чем быстрее крутим, тем чаще импульсы. Но на 1 оборот датчика  кол-во импульсов постоянно. Поэтому и на 1 мм хода дозаторов датчик выдает определенное количество импульсов.

Вопрос к разработчикам:
Действительно ли к Вам можно обратиться с подобной просьбой ? (вывести irql0 на цифровой разьём также как и irql1) Будет ли это работать?

Вывести второе прерывание наружу не проблема, я бы даже предложил ЛКарду это рацпредложение в качестве штатной фичи реализовать в следующих релизах L761. Получаешь два счётчика, которые читаешь и имеешь скорость перемещения поршней. Но ещё непонятно как ты узнаешь направление перемещения.

Чем больше функций будет сделано на уровне дсп, тем меньше будет постоянная времени регулировки, к примеру если асинхронно делать из user-space даже 1in/out на ттл-линиях функциями существующего api, то частоты выше 50..60КГц реализовать не удастся. Синхронно из user-space (пользовательских приложений) в многозадачных ОС такие задачи не решаются. Придётся или ковыряться в драйвере или лбиосе дсп - выбирай что больше нравится.

/Но ещё непонятно как ты узнаешь направление перемещения.

А вот это как раз совсем не проблема (конечно, касательно моей задачи). Дело в том, что исполнительными механизмами, приводящими поршни в движение, управляю я же, и соответственно, я же задаю направление движения поршней, и видимо в курсе куда их двигаю. Грубо говоря, если вы включили двигатель в одну сторону, то поршень, приводимый в движение этим двигателем, никак не пойдет в другую. Хотя у меня приводы гидравлические, но смысл все равно тот же. Требуется только измерить пройденное поршнем расстояние, т.е. кол-во импульсов с датчика.

> Грубо говоря, если вы включили двигатель в одну сторону, то
> поршень, приводимый в движение этим двигателем, никак не пойдет в
> другую.

Я бы на твоём месте подстраховался от этой ситуации. Бывают сбои, нештатные ситуации и т.п.

ps Насчёт irql0 лучше задай отдельный вопрос.

Стас, по-поводу подстраховки см. законы Мэрфи !

С учётом Мэрфи: в схеме управления не предусмотрен контроль направления перемещения. Так делать нельзя, поскольку если не исключить вариант сбоя направления движения поршня при переключении, то это чревато аварией.

Поспешу успокоить вас господа. Никакой аварии в моем случае не будет. В принципе есть коссвенный контроль направления движения. Среди входных параметров у меня используется давление - 2 канала(по обоим дозаторам). Когда поршни идут в одну сторону - всасывание компонентов, т.е. Р<=0, а когда обратно - нагнетание, т.е. Р>0. Вот так и будем подстраховываться.
  А вообще, в любом даже самом худшем случае неисправности она не приведет к серьезной аварии, а лишь к нарушению режима работы, которое сразу же обнаружит оператор и вызовет сервисную службу.
  P.S. такое вот лирическое отступление, в ожидании ответа разработчиков.

Но буратино таки продал азбуку и не пошел в школу