Добрый день,
Стоит задача определения количества импульсов в единицу времени.
Импульсы цифровые, амплитуда 5 в, длительность 25 мкс, идут случайным образом.
В наличии есть LCard E-154 и LCard E14-140-M-D.
Есть ли стандартные решения данной задачи?

С точки зрения программирования написать программу, подсчитывающую импульсы, на первый взгляд должно быть нетрудно (при частоте дискретизации 100 кГц на 25 мкс придется 2 или 3 отсчета).

Но понадобится подключать цифровые сигналы к аналоговым входам АЦП, потому что цифровые входы у E-154 и E14-140M не предусматривают потоковой оцифровки. То есть сигнал нужно будет вводить как аналоговый и выделять импульсы по уровню.

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

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

Спасибо за рекомендации.
Импульсы идут от ножки микроконтроллера, после обработки сигнала газоразрядного датчика. Что касается интервала между импульсами, то его сложно определить.
В идеале желательно периодически подсчитывать количество импульсов появившихся  за время, например, 0,5 сек и выводить число на экран.

Это может быть, например, программный триггер Шмитта: берем два порога UL и UH (например, 0.3 и 0.7 от уровня логической единицы), выражаем их в кодах АЦП и сравниваем отсчеты сигнала следующим образом:

если U < UL, то выход триггера Шмитта переводится в 0;
если U > UH, то выход триггера Шмитта переводится в 1;
иначе выход не меняет состояния.

Такой детектор сможет работать даже с плохими фронтами сигнала и будет защищать от дребезга.

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

Ну это можно сделать простейшим образом, "в лоб". Отсчитали полсекунды отсчетов сигнала и вывели приращение счетчика импульсов.

Скорее всего подойдет простой вариант подсчета на цифровом входе.
Спасибо за помощь.

Цифровой ввод в E-154 и E14-140M асинхронный при работе с программой верхнего уровня под Windows. Для прямого подсчёта импульсов потребуется низкоуровневое программирование E-154 и E14-140M.
Для счёта импульсов, измерения определения частоты и периода используют LTR51 в составе крейта LTR, например, LTR-U-1-4.

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

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

Хорошо, попробуем использовать аналоговый вход.

Удалось посчитать импульсы. 
Алгоритм такой.
1. АЦП работает с частотой 40 кГц, соответственно отсчеты идут раз в 25 мксек. Сигнальный импульс тоже 25 мксек, поэтому хотя бы один отсчет должен попасть на него.
2. Данные заносятся в FIFO буфер АЦП. Буфер раз в 10 мсек по таймеру считывается  в программу на компьютере. Функция ReadData работает с синхронном режиме.
3. Массив отсчетов (30000 элементов) из буфера проверяется поэлементно на значение, сравнивая с порогом 2,5 В. В итоге получаем количество импульсов за время ( 30000*25 мксек= 750 мсек ).

Эта игра "на грани фола", поскольку, если Вы себе представите, что сами фронты-спады импульса имеют конечную длительность и АЦП имеет конечную полосу частот пропускания), то при попадании фазы выборки АЦП точно на фронт-спад, оцифрованный импульс АЦП может почти съесться по амплитуде. Я бы предложил частоту преобразования АЦП увеличить и написать нормальный алгоритм селекции импульса...

А синхросигнал опорной частоты 40 кГц можно ли снять с источника импульсов? Или, наоборот, можно ли засинхронизировать источник импульсов от внешней опорной частоты 40 кГц? Импульсы имеют постоянную фазу относительно некой опорной частоты?
Если да, то возможно ведь засинхронизировать E14-140М с источником импульсов и тогда будет вполне приемлем Ваш вариант с периодом преобразования АЦП, равным длительности импульса...

Ну вообще-то я бы покритиковал эту реализацию по всем трем пунктам
1. Как уже сказал Александр, период дискретизации надо сделать меньше минимальной длительности импульса, иначе есть вероятность пропустить импульс. А программа должна считать не количество единичек, а переходы 0->1.
2. Для ReadData не нужен таймер, более того, он может быть вреден (пропускная способность алгоритма чтения должна быть выше, а не равна скорости поступления данных).
Скорость поступления данных обеспечивается самим АЦП, Вы не сможете считать данные быстрее, чем они приходят.
Советую прочитать статьи про буферизацию - здесь и здесь (там и исходник есть).
Если в Вашей программе не стоит задача как можно быстрее среагировать на какое-то событие (а я так понимаю, что Вы считаете количество импульсов за сравнительно большой интервал), то можно читать сравнительно большими блоками любого удобного размера.  По требованиям lusbapi число отсчетов в блоке должно быть кратно 32.
Функцию обработки данных я бы советовал не привязывать к размеру блока чтения, а просто сделать функцию "обработать N отсчетов сигнала" (по типу data_callback в примере по ссылке выше). Эта функция уже сама может отсчитывать, сколько отсчетов обработано от момента пуска (в глобальных переменных, например).
Для программы, обрабатывающей данные, время физического процесса – это порядковый номер отсчета сигнала, умноженный на период дискретизации.
3. Сравнивать с порогом, пожалуй, можно и так (без гистерезиса), вряд ли на выходе микроконтроллера будет дребезг. Но все равно из п.1 следует, что считать надо будет переходы 0->1, то есть надо хранить предыдущее состояние выхода. То есть тут триггер Шмитта не усложняет алгоритм, а просто является частным случаем при равенстве порогов UL = UH. Как говорится, "за те же деньги" можно сделать сразу и гистерезис и получить помехоустойчивый счетчик.

static int dig_out = 0, pulse_count = 0;
...
if (x[i] > ADC_THRESHOLD_HI) {
    if (!dig_out) pulse_count++;
    dig_out = 1;
} else if (x[i] < ADC_THRESHOLD_LO) {
    dig_out = 0;
}

P.S. Но только важно, чтобы промежуток между импульсами был тоже больше периода АЦП, иначе триггер не сбросится.
Если он не ограничен снизу достижимым значением (5 мкс для E14-140M), то придется измерять длительность импульсов.
В этом смысле Ваш прямой подсчет единичек выигрывает, но он ненадежен из-за попадания на границу импульса.

Источник импульсов - сигнал газоразрядного датчика пламени, прошедший обработку и выведенный на ножку микроконтроллера. Имеет вид случайно появляющихся импульсов длительностью 25 мкс. Синхросигнала к сожалению нет.
Частоту преобразования АЦП увеличил до 80 кГц. Хотелось 120 кГц, но получается только 100 кГц.

Частота АЦП увеличена до 80 кГц. На данный момент потеря одного-другого импульса допускается, вероятность этого похоже небольшая.
Задачи среагировать на событие нет, пока надо оценить общее количество в разных ситуациях. Пишу на Delphi, не программист, поэтому ищу простые решения.
Хотелось бы уяснить - когда ReadData считывает буфер, что происходит с содержимым буфера? Он очищается или данные сохраняются?

Частота задается делением 8 МГц на целое, поэтому точно 120 не получится, но приближенно получится. После SET_ADC_PARS можно считать из структуры получившуюся частоту в double.

Буфер внутри модуля? Конечно, считанные данные удаляются из него и освобождают место для новых. В статье про буферизацию популярно изложено, как это всё работает.
(Вы подумали, что буфер - это в реальном времени обновляемые N последних отсчетов АЦП, и программа должна успевать считать точно нужную порцию, отсчет в отсчет, не раньше и не позже? И поэтому стали приделывать таймер? Это бы совсем не работало.)