имеется крейт LTR-EU-2-5 с двумя платами LTR11.
Одна плата настроена на 16 котч/с другая на 32 котч/с. В двух разных потоках я читаю информацию с разных плат. Данные я читаю небольшими пакетами по 32*4 отсчета. Моя задача привязать значение ацп к координате.
Я столкнулся с проблемой,чтение идет рывками. Такое впечатление, что порядка 100 мс данные не приходят, после чего я сразу без задержки считываю несколько пакетов подряд.
Точную привязку без аппаратной поддержки мне не получить, получить хотя бы относительную привязку было бы достаточно, но для неё мне  нужно чтобы пакеты приходили примерно через равное время.
Как можно получить более постоянную задержку в получении данных.

Привязать значение АЦП к координате чего?
Подключение крейта по TCP/IP или по USB?

Вообще-то говорить о привязке момента обработки данных прикладной программой к физическому времени эксперимента не стоит. Операционная система на ПК - не реального времени, обмен данными с LTR реализован через сокеты, есть несколько уровней буферизации данных.

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

Синхронизация в крейтовой системе LTR поддерживается как раз аппаратно. В частности, LTR-EU имеет встроенные средства внутренней и внешней (с помощью разъема SYNC) синхронизации.
Вы можете запрограммировать систему так, чтобы в поток данных были включены так называемые секундные метки, по которым можно привязать отсчеты данных к реальному времени (например, стартовому синхроимпульсу) с точностью до периода дискретизации - т.е. будет видно, между какими двумя последовательными отсчетами сменился номер секунды.
Это все описано в руковолдстве.

Связь по tcp. Съём данных потоковый. Координату получаю от промышленного контролера через OPC Server, там тоже много буферизации, но воспроизводимость есть, задержка в пределах 10 мс, в то время как при съеме с LTR-EU речь идет о 100 мс. Раньше я имел дело с вашими PCI и USB платами, там такого поведения не встречал.
В той же системе стоит самодельный ацп который общается с компьютером через WiFi, там тоже такого поведения не наблюдается.

Я пытаюсь читать пакеты оцифровка которых занимает

20мс а данные поступают примерно так 100мс несколько пакетов подряд потом 100мс несколько пакетов подряд, может существует оптимальный размер пакета который надо запрашивать?

Лучше всего, конечно, аппаратную синхронизацию прикрутить. Есть возможность завести импульс по событию <<вот прямо сейчас была прочитана координата>> на разъем SYNC в качестве секундной метки? (Что период будет не 1 с, не беда - это просто некий счетчик). Тогда она будет видна в потоке данных от LTR аккурат напротив ближайшего отсчета АЦП. Не хотите попробовать?

Про размер пакета трудно сказать - думаю, это некоторое шаманство. Кстати, у Вас обновлена прошивка крейта? В последней версии сильно ускорен IP-стек (см. в библиотеке файлов http://www.lcard.ru/download/ )
Но вообще тут и алгортм Нагла может сказываться, и куча всего еще. Лучше уж тогда по USB подключиться...

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

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

Да, всё точно так. Если я правильно понял Павла, то данные-то, скорее всего, непрерывны, просто Павел параллельно получает на компьютер данные от другой части установки, минуя LTR, и пытается наложить их друг на друга по моменту поступления на вход программы. И наблюдает неравномерность поступления порций данных во времени ПО ЭТИМ ЧАСАМ, заметную на отрезках порядка 100 мс... По-моему, это просто не совсем то, на что рассчитана система LTR. Для нее временем надо считать порядковый номер отсчета данных, умноженный на период дискретизации, а не момент по часам на стене лаборатории, когда эти данные обрабатываются прикладной программой. Ну а чтобы привязать это время к внешнему событию, крайне желательна хотя бы одна аппаратная синхрометка - какой-нибудь провод между LTR и другой частью установки, минуя компьютер.

Замена прошивки решила проблему, спасибо.

Данные шли непрерывно, но рывками. Сейчас рывков не наблюдается. 
Я понимаю, что аппаратная синхронизация самый правильный вариант, но он влечет за собой сильное осложнение программы промышленного контроллера, а эти звери тоже не системы реального времени, тот вариант который работает сейчас не хуже, так как цикл пром контроллера тоже порядка 10-30 мс.

Здравствуйте. А исходные коды новой прошивки доступны?