Форум: Техническая поддержка

Добрый день.

Столкнулся с какой-то неисправностью или аномалией в генерации сигнала с п-ю LTR34-8.
Конфигурация по сути та же:
крейт LTR-EU-8-2, подключение к ПК по USB, несколько модулей (полный список виден на скриншоте с LTRTEST2, но используются не все).
https://www.lcard.ru/forums/img/members … -2_1_0.png
LTR34-8 управляю из LabVIEW (потоковый режим, как в ltr34_stream_fifo_ctl). Использую только 1 из 8 каналов. Частота ЦАП = 100 кГц. Генерирую сигнал прямоугольный формы. Период следования = 1 мс. Соот-но, импульс получается на 100 отсчетов. Блоки с отсчетами отправляю переменной длины в зависимости от условной заполненности. Макс. длина блока при такой частоте до 80 импульсов (мс), но обычно меньше.
И вот этот аналоговый сигнал проверяю параллельно на одном из LTR11 в LGraph2. Массив данных для ЦАП, подготовленный в LabVIEW, выглядит корректно - половина значений 3.0, а другая 0.0, и они чередуются пачками по 50. А в LGraph2 видно, как часть с 3В "растягивается" по времени на одном из импульсов. Длительность других импульсов в блоке остается корректной, как и их число. Поэтому из-за этого "зависания" общая длительность блока увеличивается на несколько мс (на 1-13 мс).
https://www.lcard.ru/forums/img/members … t_0001.png
Возникала мысль, что не очень правильно проверять модулем в том же крейте, что и ЦАП. Но потом проверил с п-ю внешнего модуля E20-10, который подключил к другому ПК, и он показывает такую же картину.

Также поначалу хотел написать, что еще несколько месяцев назад такого не было, но потом нашёл пару таких дефектов среди множества записей в LGraph2 (т.е. проявлялось значительно реже).

Есть какие-то соображения, что это может быть? Разрывы, по крайней мере, понятны (если не успевать вовремя докладывать данные), а тут совсем непонятно.

С уважением,
Павел

Добрый день. При опустошении внутреннего буфера данных LTR34 сохраняет на своём выходе последнее выведенное значение. Вы это учитываете?

Да. Упоминая разрывы, я именно это имел в виду. В тех блоках, что я загружаю/отправляю, последние значения - всегда нули. Соответственно, если бы это был тот случай, то выглядело бы оно иначе (растянулась бы нижняя часть). Поэтому я и разделил их, как две разные проблемы.

Но процесс подкачки данных в буфер LTR34 - это принципиально асинхронный процесс. Если, не прекращая процесса вывода, Вы переводите буфер LTR34 из состояния опустошения в заполненное состояние (и обратно), то из-за асинхронности подкачки данных в буфер могут возникнуть кратковременные промежуточные опустошения буфера, что приведёт к асинхронным моментам растягивания диаграммы на выходе LTR34. Чтобы гарантировать синхронность на выходе LTR34, следует не допускать опустошения буфера LTR34.

Отредактировано Инженер (13.10.2020 17:45:12)

Правильно ли я понимаю, что Вы изначально запускаете потоковый вывод и за этот вывод Вы можете посылать в произвольные моменты времени блоки прямоугольных импульсов произвольной длины (при этом сами моменты времени и длительности перед стартом вывода не известны и определяются уже по каким-то внешним условиям во время работы)?
По Вашему описанию при этом не очень понятно, как организован вывод между посылками блоков? посылаете ли Вы нулевые данные между блоками или у Вас в этот момент не посылается ничего, т.е. посылки данных идут с разрывами?
Для гарантии непрерывного вывода Вам нужно обеспечивать всегда заполненность буфера сигналом, время которого не меньше времени макс. задержки "прием-реакция программы-передача", т.е. если ориентироваться на пример ltr34_stream_fifo_ctl, то Вы должны постоянно слать нулевые данные, обеспечивая заполненность буфера, а в нужный момент подменять в отсылаемом массиве нужную часть нулевых отсчетов на Вашу последовательность импульсов. При такой организации должно быть возможно достичь непрерывного вывода при тех же условиях, что и для оригинальной версии ltr34_stream_fifo_ctl (время общей задержки не превышает времени подкачиваемого за один блок сигнала).
А так при передаче нет гарантий, что даже посылаемый за один Send блок дойдет также непрерывным блоком до модуля, т.к. данные за путь от Send до модуля этот блок может биться на более мелкие блоки между которыми могут быть различные задержки. И если Вы у Вас между посылками идет опустошение буфера, то вполне может получится, что сперва придет первая часть посылки и выведется сразу, а вторая только с задержкой, в результате чего возникнет разрыв.

С LTR34 работаю в отдельном цикле и на каждой итерации отправляю по блоку данных. Цикл крутится как бы с одной и той же скоростью, но с погрешностью в несколько мс (что-то где-то задержалось, Recv приходится вычитывать больше отсчетов и отрабатывает она дольше и т.д.). Именно поэтому приходится корректировать длину блоков.
На 1-й итерации закидываю большой блок данных. На всех последующих итерациях я вызываю LTR34_Recv c timeout=0, чтобы узнать, сколько за время с прошлой итерации было воспроизведено отсчетов. Зная, сколько при этом я отправил отсчетов с п-ю LTR34_Send, у меня складывается представление о заполненности буфера модуля. Всё это лишь примерно, поэтому тут я закладываю некий запас по времени (отправляю больше отсчетов).

Соответственно, если я кладу мало данных и/или не успеваю вовремя положить, то да, возникает вот такой разрыв:
https://www.lcard.ru/forums/img/members … _break.png

А то, что я показал в пред. скриншоте выглядит немного иначе и это меня смутило.

Задача усложняется тем, что от меня требуется изменять сигнал (скважность) гораздо чаще, чем в примере, где блок = 250 мс. И возникает устойчивое ощущение, что с условным "буфером" в десятки мс проблематично добиться стабильной работы. А если, как Вы говорите, блок, отправленный за раз LTR34_Send-ом так же может разбиться, то тогда вообще всё сложно получается..

Тут вопрос скорее не столько в том, насколько часто нужно изменять сигнал, а скорее в том, какая допустима минимальная задержка между определением события изменения и формирования сигнала до собственно изменения сигнала на выходе. Если сигнал менять нужно часто, но допустимо, что вся диаграмма задержена на фиксированное время, например T=200-250мс, то  Вы можете посылать и меньшими порциями, главное изначально заслать данных на T + запас и когда невыведенных слов меньше T снова подкачивать данные, пусть и меньшими порциями.
Если вообще время реакции на событие требуется в пределах десятков мс, то выглядит сомнительным возможность реализации такой стабильной работы на ПК под ОС общего назначения