Здравствуйте.
Реализую схему на Е20-10: 1-й канал - оцифровка, 2-й канал используется для синхронного запуска оцифровки (по фронту, по уровню - неважно).
Поясните пожалуйста:
1. Означает ли это, что 2-й канал должен быть внесен в управляющую таблицу логических каналов, т.е., например, устанавливать кадр (1,2)?
2. Какова синхронность запуска оцифровки по 1-му каналу с переходом через уровень сигнала, поданного на 2-й канал, - с точностью до периода АЦП, или до межкадрового интервала?

Заранее благодарен,
Алексей

Алексей. Я так понял, что Вы хотите использовать  один из режимов старта сбора данных в варианте аналоговой синхронизации по перепаду или уровню в выбранном канале АЦП.  В этом режиме номер канала АЦП, по которому будете синхронизировать, должен быть включён в управляющую таблицу. Когда Вы зарядите этот режим и дадите программный старт, E20-10 начнёт собирать данные внутри себя (согласно всем установленным параметрам кадра) и, как только выполнится условие синхронизации, E20-10 СО СЛЕДУЮЩЕГО КАДРА начнёт выдавать данные в ПК. См. http://www.lcard.ru/download/e20_10_users_guide.pdf,  Рис. 5-3 (нижняя диаграмма с пояснениями в ней).

Но есть и другой режим старта E20-10 - по цифровому сигналу START. В этом режиме начало самого кадра данных привязано к моменту синхронизации  (Рис. 5-3, верхняя диаграмма), если дополнительные условия старта не задействовать. В данном случае канал синхронизации отсутствует в управляющей таблице.

Спасибо.
Можно ещё ряд вопросов:
1. StopAfterNKadrs значение 0 в режиме синхронного старта запустит оцифровку только одного кадра? Если это так, то встаёт вопрос как заставить после старта оцифовывать АЦП бесконечно.
2. Заправка конечного значения StopAfterNKadrs прекращает работу АЦП, но компьтер об этом не знает, функция ReadData тоже не сообщает, что АЦП остановлено.
Что делать? Подгадывать размер буфера для считывания кратным StopAfterNKadrs, чтобы сделать ровное число запросов ReadData, не всегда возможно.
Вываливаться из опроса по тайм-ауту не хорошо - достаточно большая задержка (может быть ситуация, что надо срочно запустить новое измерение), да и нужен дополнительный анализ - по какой причине вывалились.
Я отслеживаю последний запрос ReadData и сокращаю размер буфера.
Т.е. приходится огород городить - очень некрасиво. Предложение - не может ли ReadData возвращать, например, фактический размер запроса, но с учётом возможного окончания по StopAfterNKadrs. Либо возвращать не bool, а константы, по которым можно разобраться, запрос последний и АЦП после данного запроса остановится. Либо может есть ещё какие-то варианты узнать, что АЦП остановлено, а не ждет поступления данных.
Извините за назойливость,
Алексей