Какого размера циклический FIFO у LTR114? И если он будет переполнен, то есть пойдет запись по второму кругу, адрес чтения тоже будет двигаться или останется указывать на начало FIFO?

В руководстве пользователя есть небольшая неточность, если Вы про FIFO из описания LTR114_Recv(). Там имеется ввиду буфер LTR-сервера, а не самого модуля (в модуле специального буфера нет). Этот буфер на 256 КСлов на каждый модуль. При переполнении, слова для которых не найдется место в буфере будут отброшены и перетирание уже принятых данных произойти не должно. Соответственно, при такой ситуации в конце очереди будет разрыв данных. При приеме блока данных в котором есть разрыв из-за переполнения будет установлен флаг FLAG_RBUF_OVF в поле Channel.flags

Есть еще буфер в крейте на несколько мегабайт, который общий на все модули. Так как сервер постоянно читает данные, то при наличие надежного соединения с крейтом с достаточной скоростью передачи данных этот буфер переполняться не должен.

Очень и очень жаль В чем же тогда закольцованность буфера? Или тоже неточность описания?

А что конкретно жаль и для какой задачи Вам не подходит такое поведение буфера?

Нам необходимо было непрерывно оцифровывать данные, а по внешнему синхросигналу останавливать и вычитывать последние данные. Это хорошо бы работало, если бы был циклический буфер. В принципе мы можем запускать внешнее тактирование АЦП по дополнительному внешнему запуску, который бы предшествовал основному, но не факт, что у нас бдет этот дополнительный запуск. А насколько вам трудно по нашему заказу модифицировать ПО АЦП? А именно, добавить небольшой циклический буфер (можно не более 128 слов) и сделать внешний запуск у АЦП, то есть при внутреннем тактировании сбор данных запускался по сигналу на ножках DIO?

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

Привязать то конечно можно, но это означает постоянное вычитывание данных на верхнем уровне. Тогда как фактически данные (100 мс) могут понадобится раз в несколько минут. При постоянном вычитывании наверх данных эта синхрометка и не нужна, так  как можно привязаться к окончанию оцифровки данных (это при использовании внешнего тактирования). Все же, возможны ли модификации ПО для АЦП? Ну или (если я правильно понял) я могу сам организовать в контроллере крейта этот циклический буфер для данного АЦП, так как исходники вы предоставляете?

Алексей, а чем Вас не устраивает постоянное вычитывание данных на верхнем уровне? От LTR114 трафик совсем не велик (по сравнению с LTR11, LTR22, например). Когда не приводите веских аргументов, из-за которых штатное решение Вам не подходит, все идеи по поводу вмешательства внутрь LTR как-то всерьёз не воспринимаются, поскольку подобная заказная работа обычно непроста (и для заказчика обходится недёшево). Опишите, пожалуйста, полностью Вашу конфигурацию аппаратуры LTR и максимально подробно (!) саму задачу - тогда, возможно, у нас найдутся другие штатные решения или варианты, как сделать это с наименьшими трудозатратами. Опишите требуемый процесс синхронизации во времени. Какая точность синхронизации по времени нужна?