Здравствуйте!

Осваиваем ваш девайс и столкнулись с проблемами. Коротко о сути нашей задачи.

Необходимо оцифровать аналоговый сигнал, но при внешней синхронизации. Согласно описанию, на вход INT аналогового разъема подается синхроимпульс (обратный перепад, размах 5В, длительность порядка 300мкСек). Частота его 100герц. Необходимо получить кадр по поступлению данных синхроимпульсов.

Пытаюсь использовать ваше стандартное ПО - LGraph 1/2 на первом этапе, чтобы протестировать принципиальную корректность работы режима и железную часть, в дальнейшем планируется программирование. Пока не удается достигнуть желаемого результата.

Выставляю режим синхронизации "Цифровая покадровая синхронизация". Правильно ли я понимаю, что частота работы АЦП может быть практически любой, но бОльшей чем необходимо для формирования кадра из N каналов? Поскольку наш сигнал весьма медленный, это несложное условие. Т.е. частотой работы АЦП мы устанавливаем скорость формирования кадра, а далее просто происходит простой и ожидание следующего синхроимпульса? Мне нужно получить 100 отсчетов в секунду с нужного числа каналов, согласно частоте синхроимпульсов. Но такое ощущение, что система/программа просто этих импульсов не замечает.

Помогите разобраться.

Здравствуйте.  На первый взгляд, Вы всё правильно понимаете.
В режиме синхронизации "по нажатию кнопки пуск" работает нормально?

Там две разных внешних синхронизации: SYN и INT.

Если Вам надо, чтобы каждое преобразование АЦП (т.е. каждого канала) тоже запускалось от внешнего импульса, то надо поставить ClkSource = EXT_ADC_CLOCK_E140 и подавать на SYN импульсы нужной частотой, которая должна быть достаточно для формирования кадра и т.д. (В руководстве есть описание с диаграммой (http://www.lcard.ru/download/e14_140_pr … _guide.pdf параграф 3.2.4).

А от INT в покадровом режиме стробируется начало кадра.

То есть если не нужно запускать от внешнего сигнала каждый отсчет каждого канала, а нужно только кадр, то можно использовать внутренний ClkSource и установить частоту дискретизации программно.

Нет, каждый отсчет каждого канала с синхронизацией нам не требуется, для нашего достаточно медленного сигнала считаем преобразование для N каналов по одному синхроимпульсу "одновременным", хотя конечно понятно, что 1-й и N-й канал будут оцифрованы с некоторым смещением, тем меньшим, чем выше частота АЦП.

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

Если вернуться к моим экспериментам с программой Л-Граф. Для простоты я беру один канал, остальные выключаю. Развертку ставлю 1сек/деление, у меня получается 8 секунд все окно. Если выставляю "покадровая синхронизация", то во временной развертке у меня остается активным только поле "частота АЦП", "межкадровая задержка" и "частота кадра" становятся вот такими "?????", т.е их не имеет смысла устанавливать и это верно по идеологии работы данного алгоритма.

Для моей частоты синхроимпульса в 100Гц и одного канала я ожидаю увидеть 100 отсчетов/сек или 800 отсчетов за 8 секундное окно. И это не должно зависеть от установки частоты АЦП, ведь так? А по факту зависит, чем выше я ставлю эту частоту, тем дольше у меня накапливается это окно в 8 секунд, поскольку увеличивается число отсчетов вместе с повышением частоты АЦП. При этом, если убрать галку "автозапуск", то по ручному старту кнопкой, получаю лишь один этот 8-ми секундный экран и далее сбор останавливается. Хотя по идее, он должен продолжаться, ибо синхроимпульсы то идут без перерыва. Что не так?

Возможно ли какое-то продолжение диалога с техподдержкой? 

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

Не очень ясно какая диаграмма требуется, сейчас не так важны конкретные параметры оцифровки, у меня принципиально не хочет работать режим с внешней покадровой синхронизацией. Эти внешние синхроимпульсы как бы просто не замечаются, оцифровка идет как и без синхронизации. Пока использую ваше стандартное ПО, но уже начал пробовать и собственное программирование на базе ваших же примеров. Здесь у меня конечно же также наверняка возникнут вопросы, но пока хочется понять, почему не удается достигнуть результата стандартным готовым ПО. Параметры синхроимпульса вроде удовлетворяют требованиям, но не замечаются.

То есть частота кадров, если я правильно понял.

Как будто бы. Но частота АЦП должна быть достаточно большой, чтобы успеть оцифровать кадр.

Поставьте 100 кГц. 800 отсчетов заполнится сразу же (за 8 мс)?

Какая галка имеется в виду, в каком окне?

Прилеплю два скрина с разными параметрами частоты АЦП (ну и какая галка там тоже видно). Во вкладке синхронизации установлена "покадровая синхронизация". Сбора при частоте АЦП 0.2КГц я ждал примерно 16сек, для 1КГц более минуты. Разумеется 100КГц и не пытался дождаться. Примерно на 4-й секунде после запуска в обоих случаях был сгенерирован похожий сигнал, который виден на графике. В общем что-то работает не так.

Я уже начал программировать и первые результаты обнадеживают. Устанавливаю структуру так:

ap.ClkSource := INT_ADC_CLOCK_E140;
ap.EnableClkOutput := ADC_CLOCK_TRANS_DISABLED_E140;
ap.InputMode := TTL_KADR_SYNC_E140;
for I := 0 to (ap.ChannelsQuantity-1) do
    ap.ControlTable I] := (I or (1 shl $5) or (InputRange shl $6));
ap.AdcRate := AdcRate;
ap.InterKadrDelay := 0.0;

Мне требуется оцифровывать каналы с общей землей и поэтому записываю в 5-й байт каждого канала единичку (это корректно так как у меня здесь?) Пока только начал работать, но в данном раскладе попробовал изменять AdsRate и получаю одинаковое число отсчетов за одинаковый период сбора, независимо от этой частоты, что для 100КГц, что для 1КГц к примеру. А это так и должно быть, ибо это частота собирания кадра, а сами кадры стробируются внешними синхроимпульсами требуемой частоты. Сами собираемые данные пока не смотрел.

В общем получается, что в LGraph что-то не так работает или я что-то не так настраиваю.

Насколько я понял, вы ожидаете увидеть на экране lgraph данные как бы в реальном времени, т.е с учетом пауз, когда модуль не собирает данные. На самом деле lgraph отображает сэмплы как они есть, поэтому у вас так долго заполняются большие временные окна. И надо учесть, что данные с модуля по usb читаются пакетами, поэтому модуль накапливает перед отдачей некоторое количество данных, поэтому на экране они не будут отображаться отсчет в отсчет.

Я попробовал собирать данные с частотой синхронизации кадров 100 Гц в lgraph2, все работает. У меня данные с модуля приходят кусками по 960 отсчетов. Советую вам тоже пользоваться lgraph2, т.к первая версия больше не поддерживается.

Да, у E14-140M минимальная порция передачи данных составляет 64 байта, т.е. 32 отсчета. Пока не набрался очередной 64-байтовый пакет, модуль не отсылает данные по USB. Это описано в документации.
Но это ограничение ощущается обычно на задачах, где серия синхроимпульсов конечна.

В LGraph2 должно работать, проверяли.

В пятый бит. Да, все правильно, при этом I может быть от 0 до 31.

Спасибо за ответы, но у меня по прежнему какая-то ерунда творится. Я конечно пробовал и в ЛГраф2, у меня ровно тоже выходит. Если я использую режим "без синхронизации", то все нормально и логично. В нужном мне режиме нет. Число отсчетов зависит от частоты АЦП, хотя не должно. Я уже грешу на сами эти синхроимпульсы, но там вроде все нормально. Вот выложу заголовки файлов экспорта для двух случаев с частотой 1КГц и 0.2КГц. Интервал сбора в обоих случаях задан в опциях в секундах (3сек).

----------------------------------------------------------------
Oscilloscope Data File
Experiment Time :   24-04-2014 14:33:09
Number of frames: 3000

Module: E-14-140M (1D899062)

Number Of Channels : 1
Input Rate In kHz: 1.000000
Input Time In Sec: 3.000000
Decimation: 1
Data Format: ADC codes
Segments: 1
Data as Time Sequence:
    Ch  1  
 Канал 1   
-----------------------------------------------------------------

Oscilloscope Data File
Experiment Time :   24-04-2014 14:19:10
Number of frames: 599

Module: E-14-140M (1D899062)

Number Of Channels : 1
Input Rate In kHz: 0.199900
Input Time In Sec: 2.996497
Decimation: 1
Data Format: ADC codes
Segments: 1
Data as Time Sequence:
    Ch  1  
 Канал 1   
-------------------------------------------------------

Если следовать логике работы алгоритма, то при моей частоте синхроимпульсов в 100Гц, должно быть 300 кадров за 3 секунды. Поскольку у меня здесь 1 канал, то и 300 отсчетов. Я вообще ничего не понимаю. У меня что-то не так с синхроимпульсами?

- От какого источника сигнала подаёте, через какой кабель, какой длины?
- Электрические уровни напряжения нуля и единицы, длительность  фронта можете осциллографом посмотреть?  Длительность импульса синхронизации 300 мкс?
- Источник сигнала синхронизации изолирован от земли? Если нет, то как соединены цепи заземления источника сигнала синхронизации и компьютера?

У меня идея. Кажется, дело просто в том, что под "собрать сигнал на N секунд" LGraph2 подразумевает "собрать N * Fs отсчетов", где Fs - частота дискретизации АЦП. При покадровой синхронизации это, конечно, не настоящие секунды, что и правда сбивает с толку.
Но можно длину сбора задавать не в секундах, а в кадрах, так путаницы меньше.

1. Генератор на микроконтроллере (Attiny) запитан от контактов GND и +5В разъема Digital (контакты 36 и 37). Провод одиночный длинной 30см.
2. 0 и +5 (из единицы падает в ноль), длительной фронта 15нс. Да, 300мкс
3. Ну собственно земля модуля и является землей источника синхросигнала, поскольку питание идет от самого модуля.

...Тогда можно считать, что синхросигнал - идеальный.
В своей схеме только учтите, что эти 5 В от E14-140M - это не стабилизированное напряжение питания, оно может зависеть и от длины USB-кабеля и от динамического тока потребления самого E14-140M...

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

Конечно, ведь тогда данные поступают действительно с частотой дискретизации АЦП.
Я что имею в виду: когда вы задаете ширину окна в секундах, LGraph2 рассчитывает количество данных исходя из частоты АЦП. Одна такая "секунда сигнала" содержит столько отсчетов, сколько герц в частоте дискретизации (Fs * (1/Fs) = 1).

Поэтому за 3 "секунды сигнала" Вы собрали 600 отсчетов при Fs = 200 Гц и 3000 отсчетов при Fs = 1000 Гц.

Но при покадровой синхронизации эти "секунды сигнала" не являются секундами физического времени. Если частота кадров 100 Гц и в кадре 1 отсчет (1 канал), то у Вас получается 100 отсчетов за физическую секунду всегда, а на сбор одной "секунды сигнала" потребуется (Fs / 100) физических секунд.

В каком смысле? Допустим, 500 кадров соберется за сколько физических секунд?

500 кадров собирается (примерно)
- 10сек на частоте 1кГц,
- 20сек на частоте 2кГц.
- 100сек на 10кГц
- 6 сек на 0.2кГц

От числа каналов данное время сбора не зависит.

Ага, ясно. В LGraph2 "Настройки -> Общие настройки" есть "минимальный интервал между запросами, мс". Он, судя по всему, пересчитывается в длину считываемого за один раз блока опять же исходя из частоты дискретизации, т.е. в "миллисекундах сигнала".
По умолчанию 1000 мс, т.е. Fs/100 с времени, что у Вас и получилось.
Минимум этого параметра вроде бы 20 "мс".
Я ставил 50 и получил примерно одинаковое время сбора 1000 отсчетов, близкое к 10 с.
Только на самом деле LGraph2 вычисляет размер блока как-то более хитро: во-первых, он должен быть кратен 32 отсчетам по требованиям модуля, плюс еще, возможно, какие-то соображения. Например, при Fs = 1000 Гц у меня чтение 1000 кадров выполняется за 16 блоков (видно по тому, как заполняется экран), т.е., видимо, по 64 отсчета за блок (16 * 64 = 1024 >= 1000), а при 4000 Гц за 6 блоков (вероятно, по 192 отсчета: 6 * 192 = 1152 >= 1000).

В общем, это специфика внутреннего устройства LGraph2.

Получается да, все это специфика внутреннего устройства ЛГраф. После экспорта данных и просмотра их посредством стороннего ПО все становится нормальным.

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

В общем для меня пока вопрос решен, устройство работает в нужном для меня режиме, синхроимпульсы удовлетворяют требованиям и тд. Теперь можно изготавливать нормальный генератор и заниматься программированием. Всем спасибо за участие в разговоре Надеюсь программирование пройдет легче с учетом уже выясненного.

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

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

Снова здравствуйте, буду продолжать писать здесь.

Привожу код из примера на Делфи ReadData.

// ожидание выполнение очередного запроса на сбор данных
//if not WaitingForRequestCompleted(IoReq[RequestNumber xor $1].Overlapped^) then break;
if not WaitForSingleObject(IoReq[RequestNumber xor $1].Overlapped.hEvent, IoReq[RequestNumber xor $1].TimeOut) = WAIT_TIMEOUT then 
begin 
ReadThreadErrorNumber := $03; 
break; 
end;

Приведены два варианта ожидания следующей порции, через свою функцию WaitingForRequestCompleted, которая в свою очередь использует стандартную GetOverlappedResult и просто через системную функцию ожидания. Первый вариант закомментен.
Так вот, мне кажется во втором случае NOT явно лишний, мы ведь ждем WAIT_OBJECT_0 при нормальном раскладе, так? Получается код как-то работает, но с ним мы никогда не сможем обработать WAIT_TIMEOUT. Или я чего-то не правильно понимаю? И кстати, как лучше все-таки работать, по первому или по второму варианту в плане надежности?

Да, похоже, что в примере ошибка. Это получается бинарная инверсия DWORD, приоритет not выше, чем =.

Лично я предпочитаю пользоваться функциями WinAPI.
Советую посмотреть вот этот длинный пост про использование OVERLAPPED / WaitFor... / GetOverlappedResult / CancelIo.
И еще могу посоветовать почитать исходные тексты примеров из e140-console-test.zip (со страницы http://www.lcard.ru/lsoft/E14-140M). Они, правда, на C.

Александр, спасибо за ссылки. С таким подробным разбором трудно что-то не понять. Пытаюсь реализовать через ReadFile-WaitFor-GetOverlappedResult. По каким-то неясным для меня причинам, чтения не производится. Запускаем ReadFile, она возвращает False, но при этом  имеем нормальный ERROR_IO_PENDING. Нормально дожидаемся сигнального события структуры Overlapped. А вот GetOverlappedResult дает ошибку 31 (ERROR_GEN_FAILURE). Но с оборудованием все в порядке, тут же при использовании ReadData все работает. Где рыться? С событиям, индексами вроде в не напутал ничего.