Здравствуйте
При эксплуатации оборудования столкнулся с
заполнением буфера LTR-34-8 и LTR-42

Крейт LTR-8/16 EU
Конфигурация:
LTR212 - 10 шт.
LTR11 - 2 шт.
LTR34-8 - 1 шт.
LTR41 - 1 шт.
LTR42 - 1 шт.

Причины заполняемости буферов 212 и 11 понятны: скорость чтения с крейта < скорость записи в крейт. Но за счет чего происходит заполнение буферов LTR-34 и LTR-42?
P.S. При увеличении частоты отдачи данных на конечное устройство (на LTR-34) скорость заполнения буфера растет, хотя предполагался обратный эффект...

Можно более подробно, что именно Вы подразумеваете под "скоростью заполнения буфера", где Вы ее смотрите, и вообще что Вы собственно с модулем делаете?..

Вообще если буфер АЦП в норме почти пуст (и процесс нарушается при его переполнении), то буфер ЦАП, наоборот, в норме почти полон (и процесс нарушается при его опустошении).

Эти буферы нужны для компенсации кратковременных провалов скорости приемника (АЦП) или источника (ЦАП) данных -- "компьютер задумался и пропустил полсекунды". При этом пропускная способность приемника/источника должна быть выше скорости потока данных, чтобы быть в состоянии "рассосать" эти всплески на фоне продолжающегося процесса.

Можно наглядно представить себе процесс в виде конвейера и робота, который кладет на поднос (АЦП) или снимает с него (ЦАП) детали со строго определенным интервалом времени. А забираю или подаю детали я, причем я могу чихнуть или отвлечься. Значит, если робот АЦП, то я должен стараться забирать каждую деталь сразу, тогда в случае чего у меня времени чихать - целый поднос. А если робот - ЦАП, то наоборот, я должен стараться набросать ему полный поднос деталей и подкладывать до полного, как только освободится место.

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

LTR34 способен работать как в синхронном режиме (когда опустошение внутреннего буфера 8 MB не допускается), так и в асинхронном (когда буфер LTR34, как правило, пуст, а его "редко кормят" одиночными отсчётами, которые сразу попадают на вывод, не залёживаясь в буфере). Выход LTR34 всегда удерживает последнее выведенное значение напряжения.

Спасибо.
А как задается синхронный/асинхронный режим работы LTR-34? В руководстве не могу найти ничего про этот момент.

Проблема возникла в связи с постепенным замедлением системы (увеличением времени между выдачами импульсов на конечные устройства). Первое на что подумали - заполнение буфера в сервере.

Ну специально настройки такой нет. Есть настройка потоковый режим и циклический.

Так вот, в потоковом режиме, Вы реально можете либо постоянно записывать данные в буфер ЦАП через Send() (и они будут выдаваться с заданной частотой на выходы). Либо вы можете посылать данные только тогда, когда Вам реально нужно изменить значение на выходах. Тогда потока данных штатно не будет, а при вызове Send() указанное значение установится на выходах с какой-то асинхронной задержкой (время передачи команды по всем интерфейсам и т.п.)

В общем тут зависит от Вашей задачи...

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

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

Ну в таком варианте буфер может расти только если при каждом измерении Вы записываете данных больше, чем может выдавать LTR34 за интервал между измерениями... в противном случае не понятно как буфер может расти, если Вы в него ничего не пишете

Так не должно быть. Разве что возвращается мусор в переменной, индицирующей состояние буфера, но мне сейчас не на чем проверить.
Вообще то, что показывает LTR-server в "Состоянии аппаратного FIFO", это справочная информация, она сообщается самим модулем, формат этого слова описан в ltr.pdf таблица 12-4 (STATUS_PERIOD):
бит 20 (0x100000) - флаг опустошения
бит 16 (0x010000) - флаг переполнения
биты 15..0 - количество килосэмплов в буфере.

А может быть, Вы видите просто 0x100000, то есть буфер пуст + флаг опустошения? Это по идее и должно иметь место при таком программировании (вывод редко меняющихся данных по одному отсчету), ведь этот режим - в некотором смысле "хак", нетипичное использование потокового режима, и буфер все время находится в состоянии "ошибки" опустошения.

Что самое интересное:
Флаг опустошения - 0x100000. Значит, буфер пуст.
А процент заполнения буфера растет. Значит буфер не пуст?

Похоже, что мусор. Но этот мусор увеличивается, дорастает до 100%, а потом переменная, отвечающая за размер, начинает увеличиваться и у модуля LTR-42.

Флаги Empty и Full означают "было за интервал выдачи статуса", т.е. за последние 1024 отсчета, кажется. То есть если Вы видите что-то типа 0x10DEAD, то это значит "тут недавно буфер опустошался, а теперь опять почти полон".

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

Если скорость записи в ЦАП явно всюду меньше частоты дискретизации, то буфер просто обязан быть пуст.
Но если, например, где-то в программе вдруг происходит подряд запись большого количества данных ("разом густо - разом пусто"), то могут быть такие эффекты. У Вас в программе нигде нет каких-нибудь циклов с условями типа "если X, то записать в LTR34 слово N", не ограниченных по частоте срабатывания (если событие X держится постоянно или возникает пачками из-за какого-нибудь дребезга)?

Запись происходит только по изменению сигналов (если полученный сигнал не равен предыдущему). Так что возможны "наплывы"

Скорость передачи данных - 11,7 слов/с.
Скорость приема данных - 15289,3 слов/с. (средние).
Что он может принимать? Подтверждения?
Биты 0..15 стабильно нулевые.

>Что он может принимать? Подтверждения?
В обычном режиме посылаются подтверждения каждых 1024 отсчетов, и сервер прибавляет к счетчику принятых слов 1024, так что это могут быть и "виртуальные" данные.
А еще у LTR34 есть режим подтверждения каждого отсчета, тогда на каждое слово, ушедшее в ЦАП, будет приходить слово-отклик. Это скорее тестовый режим, и тогда по-хорошему надо вычитывать эти данные через LTR34_Recv.

Кстати, какая установлена частота дискретизации?

>Биты 0..15 стабильно нулевые.
Э... а тогда что вы называете "процент заполнения буфера растет"? Я-то думал, что вот по этому слову состояния Вы и смотрите.

>(если полученный сигнал не равен предыдущему). Так что возможны "наплывы"

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

То есть, допустим, если частота дискретизации ЦАП >= частоте сравнений "полученный сигнал не равен предыдущему", и производительность системы достаточна для случая "всегда не равен" (будет поток на ЦАП с той же частотой), то можно ничего не делать. А если частота ЦАП ниже частоты анализа, тогда надо ограничивать, иначе ЦАП начнет отставать, разгребая эти буферы.

Если сказать точнее, то режим подтверждения каждого отсчета - это когда на каждый отсчёт, установленный на выходе ЦАП, LTR34 высылает слово-подтверждение. Т.е. слова подтверждения LTR34 высылает в темпе выдачи отсчётов на выход ЦАП.

А какая у Вас все же скорость вывода на ЦАП (какое значение устанавливаете для поля FrequencyDiviser)?

Значение FreqDiv по умолчанию ставим 40.
Пробовали и 0 и 60 - проблема с заполнением буфера осталась.

http://file.qip.ru/photo/S5AKWr_F/%D0%9 … %B917.html
Скриншот с тем, как это выглядит.

Заполнение буфера в сервере - 1,12%
Состояние аппаратного FIFO - 100000

Ах, "заполнение буфера в сервере", я и забыл про него. Это буфер приема, для LTR34 там будут данные, если включен режим подтверждения каждого отсчета, и по идее ничего, если он не включен (потому что маркеры по 1024 отсчета сервер съедает).

Синхрометки еще, если они включены. Может быть, это просто синхрометки.

Но вычитывать этот буфер программа не обязана, его заполнение не влияет на работу ЦАП.

Я думаю, что стоит вернуться к из начальному вопросу: что работает не так и как с этим бороться.
Непохоже, что буфер приема LTR34 имеет к этому какое-то отношение.