С помощью программы UTS Pro контролировался промежуток времени от подачи логической 1 на вход одного из каналов LTR43. При частоте потокового ввода 100 Гц, запаздывание достигало нескольких секунд, при вводе с частотой 10кГц, не более 1 секунды. Хотелось бы понять причину задержки. Крейт LTR EU16(LTR51+4*LTR43+8*LTR42). При выводе управляющих слов в LTR42 заметных задержек не обнаружено.

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

Похожий вопрос обсуждался на днях в вот в этой ветке:
http://www.lcard.ru/forumthreads/10645

Для точного измерения интервалов времени надо синхронизировать пуск средствами синхронизации крейта или модуля или подавать какой-нибудь опорный сигнал на входы устройства, потому что компьютер - не устройство реального времени, т.е. временем наблюдаемого процесса является порядковый номер отсчета в потоке данных, деленный на частоту дискретизации, а не время по часам ПК.

Указанную ветку посмотрел. Остались вопросы:
1.Можно узнать размер буфера, чтобы выбрать нужную частоту дискретизации
2.Именно по отсчетам и была выявлена первоначально задержка (порядка 1 секунды) в изменении состояния  входов LTR43, речь не о точной синхронизации, а хотя  бы о возможности управления с точностью около 100 миллисекунд.
3.Задержки в изменении аналоговых сигналов (LTR27), связанных с дискретными устройствами и выдаче команд через LTR42 если и существуют, то они значительно меньше(команда на открытие клапана, видим клапан не открылся а давление растет)Измерение аналоговых сигналов через другой крейт, но преобразование первым запускается на
LTR43

В тестовом варианте настройки АЦП LTR27 10 Гц, LTR43 потоковый ввод 100 Гц, данные выбираются примерно через 100 +/- 1.5 мсек (контроль промежутков времени через команды процессора) Что мы не учитываем?

1) У UTS есть параметр "количество пар слов в порции дынных" - думаю, что это оно.

2) Задержка, если я правильно понял ситуацию, не в изменении состояния входов, а в *обнаружении программой* этого факта.

Попробуйте поставить частоту повыше, покрутить настройки UTS... Можете попробовать еше LGraph, у него другой принцип сбора данных.

А если написать свою собственную программу, тогда, конечно, можно выбрать размер буфера под задачу. Или использовать функцию однократного чтения LTR43_ReadPort - по идее она должна обладать временнЫми характеристиками, схожими с записью в LTR42.

3) LTR42 работает не в потоковом режиме, а каждую команду выполняет отдельно. Задержки там получатся неравномерные, но зато небольшие.
У LTR27 поток, но, видимо, другие настройки буферов.

При написании программы использовалась штатная библиотека под LTR-сервер.
Функции получения данных, вызываемые  10 раз в сек, показывают правильное количество принятых данных
(и не ошибки). Все таки почему нет соответствия между отсчетами данных, казалось бы оно должно иметься в пределах одного дискрета

Если Вы говорите о синхронизации между модулями и крейтами, тогда посмотрите главу 4.6 ltr.pdf - Принципы синхронизации сбора данных в системе LTR.

Если бы стояла задача только измерений, все было довольно просто, но необходимо выдавать управляющие команды как в заранее заданные моменты времени, так и на основе измерений с частотой примерно 10 раз в секунду. Программировать процессор крейта вряд ли возможно так как параметры измеряются на разных крейтах (небольшая часть на том где есть LTR42) да и  алгоритмы управления часто меняются. Так что синхронизация зарегистрированных данных не единственная задача, нужно вовремя реагировать на процесс.
Кое что удалось сделать путем полной выборки данных из программного сервера по всем модулям без остановки сбора данных.
Появился еще вопрос: если брать сырые данные на входе в ltr-сервер, эти взятые порции сервером будут обрабатываться или нет?

1) В теме, на которую я давал ссылку, как раз обсуждался вопрос применимости ltr для систем с обратной связью. 10 раз в секунду - вроде не слишком быстро, попробуйте читать порциями поменьше.

2) Что такое сырые данные? Если GetCrateRawData, то будут - это копия потока. Правда, функция предназначена для тестирования, не знаю, хорошо ли она подойдет.

В теме по ссылке имеется ввиду временные характеристики USB? Опытным путем кажется определили источник больших задержек в данных от LTR43. Похоже, после включения потокового ввода (а старт LTR43 был первым) пока запускались АЦП LTR27 и LTR51 (выполнение функций API библиотеки) LTR43 успевал намолотить "лишних" данных примерно на секунду. Поскольку временные метки данных не контролировались ошибочно определялась последняя порция данных от LTR43. Очистка буферов после запуска всех АЦП позволила уменьшить задержку до 400 - 450 мсек, из них на LTR (и аппаратную и программную) приходится примерно 200 - 250 мсек.
Спасибо за ответы, попробуем GetCrateRawDat вместо чистки буферов может что то и улучшится.

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

А в той теме обсуждали не только временные характеристики USB, а в большей степени - принципиальную недетерминированность времени между физическим явлением (импульс на входе) и моментом времени, в котороый программа, исполняющаяся на ПК, обработает соответствующий ему отсчет - грубо говоря, когда произойдет переход по if (adc_buf[i] > c).
На это влияет буферизация, USB, операционная система и переключение задач на ПК, еще раз буферизация и т.д.

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

По-настоящему о временнОй привязке стоит говорить, если время отсчитывать по номеру отсчета АЦП или по синхрометкам, а не по часам ПК.

Вообще говоря, в крейтах LTR-EU используется мощный процессор Blackfin, и есть принципиальная возможность своими силами перепрограммировать его под свои нужды, отказавшись от штатного софта, и вообще не использовать компьютер или использовать его только для регистрации данных.

А GetCrateRawData не советую. Это тестовая функция, она работает через управляющий канал, и потом Вы замучаетесь разбирать поток данных по слотам - половину функциональности ltrserver придется реализовывать руками. Если уж на то пошло, тогда можно без сервера работать - прямо через USB драйвер, чтобы подбирать размеры буферов под задачу и убрать лишние накладные расходы. Но это много кода писать.