Здравствуйте!
Пытаюсь использовать цифровую покадровую синхронизацию на Е14-140. Не получается.
Пробую на LGraph2. Сбор данных не запускается. Синхронизацилнные импульсы подаю между входом №20 аналогового разьема (INT) и входом №36 цифрового разъема (GND). Амплитуда импульсов TTL (~3 вольт). Длительность 100 микросекунд. Пробую и обе полярности импульсов. Безрезультатно.

В чём проблема? Есть пример на С++ как использовать цифровую покадровую синхронизацию на E14-140?

Спасибо

В LGraph2 наверное настройку на внешний старт нужно сделать... Надеюсь, что относительно GND положительный потенциал подаёте. Срабатывать должен по спаду 1->0. Синхронизация частоты АЦП должна быть установлена внутренняя (по умолчанию).

Подал тот же синхросигнал между входом №20 (INT) и №21 (GND32) аналогового разъема. Заработала цифровая синхронизация начала сбора данных (TTL_START_SYNC_E140) в LGraph2. Покадровая синхронизация по-прежнему не работает.

Собственно, LGraph2 использую, чтобы вообще убедиться, что оно заработает. Мне нужна цифровая покадровая синхронизация (TTL_KADR_SYNC_E140) в моей программе на С++.

Код использую приблизительно такой:

STOP_ADC();
GET_CUR_ADC_PARS(m_DAQParams);
m_DAQParams->InputMode = TTL_KADR_SYNC_E140;
FILL_ADC_PARS(m_DAQParams);
START_ADC();
<тут запускаю свой шаговый двигатель, который во время движения выдаёт синхроимпульсы. Я правильно понимаю, что при каждом импульсе АЦП должен снимать 1 кадр и сохранять его в свой буфер?>
<После останова двигателя (прошло около 1000 импульсов):>
STOP_ADC();
SHORT* pBuffer = new SHORT[BUFFER_SIZE];
memset(pBuffer,0,BUFFER_SIZE*sizeof(SHORT));
DWORD sz = 0;
ReadData(pBuffer,&BUFFER_SIZE,&sz,NULL);

тут оказывается, что sz=0 и в буфере пусто. И лампочка на АЦП не мигала. Такое чувство, что нифига он от импульсов не запускается.

В LGraph2 то же самое, с той лишь разницей, что когда двигатель двигается (импульсы идут) - лампочка мигает. Специально проверял - двигается двигатель - лампочка мигает, не двиается - не мигает. Но в LGraph2 тоже на экране пусто.

Какие будут предложения?

Антон. С электрической точки зрения подавать синхросигнал между входом №20 (INT) и №21 (GND32) аналогового разъема абсолютно некорректно. Более того, в определённых случаях (например, при наличии разности потенциалов между корпусом компьютера и общим проводом источника сигнала) может повредить E14-140. Это аппаратные соображения. По программным вопросам в понедельник программисты ответят.

Понял, спасибо.
Буду ждать ответа программистов.

Антон:
1. У вас E14-140 или E14-140-M?
2. Меня смущает STOP_ADC() перед чтением данных. Стоп вполне может очистить выходной буфер, где лежат только что собранные данные. Попробуйте сначала читать данные, а потом делать стоп.
3. Опишите, пожалуйста, картину во временнОй области: какой интервал следования синхроимпульсов, чему равна частота дискретизации и межкадровая задержка, сколько каналов в кадре?

1. E14-140
2. Пробовал и без STOP_ADC() - безрезультатно
2. Интервал следования - 300-500 микросекунд и более, длительность - 100 микросекунд. Частота дискретизации - ставил и 10, и 100 КГц. Каналов в кадре 2. Межкадровая задержка, как я понял из описания, в этом режиме не используется, так?

ReadData() возвращается по таймауту?

Давайте попробуем сначала убедиться, что правильно работает процедура чтения, т.е. при синхронизации TTL_START_SYNC_E140 данные в программу на C++ должны приходить.

Еще советую проинициализировать все поля m_DAQParams, чтобы точно знать, в каком мы режиме. В частости, ClkSource = INT_ADC_CLOCK_E140.
Межкадровую задержку на всякий случай установите в нуль.

Да, и чему равно BUFFER_SIZE? Данные отправляются блоками по 64 байта, т.е. BUFFER_SIZE должно быть кратно 32.

По TTL_START_SYNC_E140 работает, проверял на LGraph2. По TTL_KADR_SYNC_E140 даже LGraph2 не работает.
В ReadData я передаю Overlapped = NULL, как я пойму, что возвращается по тайм-ауту? Тайм-аута точно нет, в отладчике функция возвращается сразу.

BUFFER_SIZE разные ставил. Какое это имеет значение, если в документации написано, что в случае некорректного значения функция сама его поправит и вернет исправленное? В любом случае, ставил 32 ровно - не работает.

GET_CUR_ADC_PARS(m_DAQParams); - это разве не инициализация?

Не очень удобно сравнивать поведение программы A в режиме X и программы B в режиме Y, поэтому я и подал идею проверить TTL_START_SYNC_E140 на вашей C++ программе...
Функция ReadData делает по сути вызов ReadFile() на хендл устройства, и вернуться она должна только по завершению или по ошибке. Посмотрите исходный текст lusbapi (e140.cpp).
Кстати, чему равно request.TimeOut? Не нулю?
Что возвращает функция ReadData()?

Насчет коррекции размера... меньше 32 передавать нельзя, а если больше - да, на уровне lusbapi функция просто проигнорирует хвост.

GET_CUR_ADC_PARS(m_DAQParams) - это чтение текущих параметров из устройства в структуру. Если, предположим, запустить другую программу и установить какой-то режим, то он там останется.
Конечно, сразу после включения питания конфигурация известна, но в общем случае это не так. Поэтому лучше всего, наверное, делать так: GET(), потом жестко прописать все параметры, значение которых не безразлично, потом SET().

И еще... какая версия lusbapi? Последняя сейчас  3.3 -- http://www.lcard.ru/download/lusbapi33.exe

Ок, попробую TTL_START_SYNC_E140 в четверг (сейчас в командировке, проверить не могу).

request.TimeOut
я испрользую функцию
ReadData(SHORT *Buffer, DWORD *NumberOfWordsToRead, LPDWORD NumberOfBytesRead, LPOVERLAPPED Overlapped)

версия lusbapi - 2.1.0.0
если думаете, что имеет смысл попробовать на 3.3 - попробую. В четверг. :-)

Ну... просто у меня нет исходников старых lusbapi. Надо нам позвать в эту тему Сергея, который ведет сию библиотеку.
В любом случае, по-моему, что-то тут не так, надо посмотреть, чему равно error_code = ReadData()...

ReadData возвращает булевское значение (true/false). Уточню, что именно она мне вернула.
Давайте позовём Сергея. Сергеееей! Идёмте к нам! :-)

Пардон, раз булевская, то, конечно, меня интересовало GetLastErrorInfo() в предположении, что вернулось false.

Ок, в четверг проверю и доложу.

TTL_START_SYNC_E140 в моей программе тоже не срабатывает.

GetLastErrorString возвращает "Запрос на чтение данных АЦП отправлен."

в версии 3.3 функция GetLastErrorInfo возвращает
"В Багдаде все спокойно! УРА!!!"

О! и данные какие-то вернулись
Буду проверять, правильные ли данные...

Во общем тоже столкнулся с проблемой при работе с покадровой синхронизации.
Причина: Всё дело в том что E140 передаёт данные только после того как накопит необходимое количество. Минимум 32 значения. У меня импульсы приходят раз в 100 мс, значит данные будут только через 3 сек. Если следовать рекомендации и ставить не менее 1024 отсчетов, то можно просто не дождаться данных.
У себя я решил эту проблему установкой минимума отчётов на передачу (32) и добавления в кадр ещё 31-го измерения. Тогда данные возвращаются сразу.

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