Форум: Техническая поддержка

Доброго времени суток.
В процессе работы с модулем E14-440 через lusbapi были обнаружены следующие особенности:
1. Если после вызова метода ADC_START() вызвать метод _GET_ADC_PARAMS(), то таблица каналов будет заполнена "мусором", т.е. случайными значениями. Нормально ли такое поведение и можно ли вообще вызывать GET_ADC_PARAMS после вызова ADC_START() до ADC_STOP()?
2. При определенных условиях запись в режиме покадровой синхронизации начинает работать аналогично синхронизации старта - запись начинает производиться непрерывно, вне зависимости от поступления синхроимпульса на вход модуля. Собственно, условие синхронизации "выполняется" (не знаю, как по другому сказать) даже на модуле, который никуда не подключен вообще. В чем может быть дело, в какую сторону рыть?
Заранее спасибо за ответы.

1. Функция GET_ADC_PARAMS(), в случае успешного выполнения, всегда должна возвращать текущую таблицу каналов, вне зависимости вызвана эта функция до ADC_START(), после ADC_START()  или после ADC_STOP().
2. Каковы серийный номер и ревизия используемого модуля? Узнать эту информацию можно, например, с помощью утилиты    ModulesViewer (это самораспаковывающийся архив).
3. Какой версией Lusbapi пользуетесь?

1. Функция завершается успешно. Все остальные параметры, кроме таблицы каналов, правильные, включая те, которые расчитываются на основе других (межкадровая задержка на основе частоты, например).
2. Серийный номер не помню, ревизия платы "Е".
3. Lusbapi версии 3.4

Попробую сегодня в своих закромах найти модуль E14-440 Rev."E" и проверить на нём как таблицу каналов, так и по-кадровую синхронизацию.

Мне не удалось воспроизвести Вашу ситуацию на модуле Rev."E". У меня всё работает штатно. В таблице каналов после ADC_START() "мусора" нет. По-кадровая синхронизация на неподключённом модуле самопроизвольно не срабатывает.
Для демонстрации могу выслать консольный пример на Builder 6.0.

Доброго времени суток.
Код написан как раз на основе консольного примера. При этом проблема воспроизводится на трех модулях различных ревизий (D, E и F). В процессе отладки удалось выяснить, что:
1. Мусор в таблице каналов на прием данных, судя по всему, влияния не оказывает. Похоже, что драйвер использует ее только на чтение.
2. Проблема с покадровой синхронизацией срабатывает при двух условиях: первый импульс был получен штатным путем (потом кабель можно отъсоединять) и, что является определяющим, код соответствует  Вашему примеру - два буфера, циклическое отложенное (overlapped) чтение. Если использовать упрощенный код, при котором используется один буфер с отложенным чтением (бесконечный цикл, пока буфер не заполнится), то сбор данных проходит "на ура", вообще без каких-либо проблем.
Сложность в том, что, по условию ТЗ, я должен считать импульсы синхронизации в ручном режиме, отображая прогресс пользователю. Я знаю их изначальное количество, поэтому могу выделить буфер ровно под нужное количество отсчетов (их порядка 300-400), но вот прогресс в таком режиме я отображать не могу. При попытке многократно использовать один маленький буфер размером 0x80 слов (8 каналов, 16 отсчетов, грубый прогресс лучше, чем никакого) начинается неконтролируемый прием "синхроимпульса", даже если оборудование физически отключить от модуля АЦП.
Используемый мною код отличается от приведенного в примерах только размером буфера и количеством каналов. Ну и еще условием выхода из цикла (в примере счетчик в цикле for, у меня достижение определенного количества импульсов в while ).
Может быть у Вас имеется более актуальный пример кода (C++ Builder 2010 + lusbapi 3.4)?
Заранее спасибо за ответ.

1. USB драйвер используется исключительно в качестве трансляции запросов на уровень DSP модуля. Поэтому ф. GET_ADC_PARAMS() возвращает фактическое состояние ячеек памяти DSP, где хранится таблица каналов. Именно эти ячейки памяти реально используются управляющей программой DSP при своей работе.
2. Попробуйте задействовать консольную программу. Эта утилита выводит на экран текущую таблицу каналов как до выполнения ф. ADC_START(), так и после.  Кроме того в программе реализована по-кадровая синхронизация сбора данных с первых 32-х логических каналов. На каждый синхроимпульс программа получает 32 отсчёта данных, увеличивая экранный счётчик. Первый синхроимпульс можно считать подготовительным, а начиная со второго на каждый синхроимпульс должны поступать сами данные (порциями по 32 отсчётов). В качестве синхроимпульса обязательно нужно использовать только качественный TTL-сигнал, например,  с цифрового выхода другого модуля Е14-440. Категорически нельзя использовать разного рода аппаратные кнопки или тумблера.

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

Для надёжной работы синхроимпульс должен иметь не слишком затянутый фронт (TTL-совместимый сигнал) и не содержать помех или дребезга.

http://www.lcard.ru/lexicon/ttl_in_out