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

Здравствуйте!

Подскажите, пожалуйста, возможно ли в LTR-35 добавить функционал, позволяющий интерактивно подбирать форму генерируемого сигнала под условия эксперимента?

Алгоритм может быть такой (но в принципе годится и любая эквивалентная по возможностям реализация):

1. Воспроизводить сигнал в режиме двух страниц буфера по данным из одной из этих страниц.

2. Анализировать состояние цифрового входа 1.
2.1. Если ==0, то дополнительно ничего не делать.
2.2. Если ==1, то анализировать состояние цифрового входа 2.
2.2.1. Если ==1, то значение в ячейке второй страницы буфера, имеющей тот же адрес, что и адрес ячейки в первой странице буфера, которая сейчас проигрывается, увеличить на 1.
2.2.2. Если ==0, то значение в ячейке второй страницы буфера, имеющей тот же адрес, что и адрес ячейки в первой странице буфера, которая сейчас проигрывается, уменьшить на 1.

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

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

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

Здравствуйте, Алексей.
Если отбросить детали, то общий смысл этой задачи приблизительно понятен. Также понятно, что по ресурсам FPGA в LTR35 это задача реализуемая. А Вы можете для начала сформулировать:
1. Если "на пальцах", то в какой области применения данный функционал востребован?
2. Какие потенциальные потребности в модулях LTR35 (в шт.) с данным функционалом?
3. Сформулируйте, пожалуйста, необходимые рабочие диапазоны всех численных параметров этой задачи, чтобы она была однозначно определена (количество каналов, частота преобразования, выходной диапазон напряжения сигнала,  количество точек циклического воспроизведения сигнала, необходимая форма воспроизведения сигнала, максимальная скорость нарастания напряжения на выходе, и т.д.). Кстати, Вас не смущает, что приращение на +-1  для 24 битного отсчёта ЦАП (если отсчёт рассматривать как целое число со знаком) будет слишком малым? Цель этого приращения именно в "маркировке" отсчёта (чтобы отсчёт логически обнаружить после скачивания сигнала назад)? Или в том, чтобы, например, прирастить это значение на, максимум, N единиц за N последовательных циклов воспроизведения сигнала, чтобы непосредственно подрегулировать сам цифровой сигнал (в неактивной странице) за N циклов воспроизведения?

Данный функционал востребован практически везде, где есть в том или ином виде периодическое сканирование с помощью развёрток. Лично мне он бы пригодился и упростил жизнь достаточно большое количество раз в самых разных ситуациях. Кроме собственно моей области (электронная дифрактометрия) это может быть растровая электронная микроскопия (развёртка электронного пучка магнитным полем), контактная микроскопия (перемещение зонда), ПЦР — что сейчас особенно популярно в связи с эпидемией — там нужна развёртка по температуре. Развёртка по температуре с прецизионной точностью также нужна при выращивании кристаллов. Скорее всего аналогичные задачи есть и в других областях.

Общая постановка задачи — требуется подобрать такое управляющее воздействие развёртки, которое после преобразований в экспериментальной установке обеспечивает нахождение объекта в заданном коридоре параметров (в заданном месте, при заданной температуре, под воздействием не более чем допустимого уровня вибрации и т. п.).

Когда управляющее воздействие (в нашем случае — массив данных для циклического проигрывания на LTR-35) в основном подобрано, но в какие-то моменты цикла параметры «вылезают» за допустимый диапазон, возникает задача понять причину и исправить. Для этого полезно понимать, на каком конкретно значении буфера ЦАП эта проблема начинается (всегда, или иногда, и как часто). Тогда появится возможность начать модификацию проигрываемой последовательности именно с этого места и оценить результат. И так, последовательно продвигаясь мелкими шагами, устранить проблему полностью.

Если такой возможности нет, то приходится действовать косвенными методами. Строить калибровочную кривую (которая может быть и не однозначной — это будет калибровочный коридор) между поведением объекта и данными в буфере ЦАПа и по ней примерно прикидывать локализацию проблемы. То есть действовать частично вслепую, в результате чего результат получается существенно дольше и хуже.

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

Речь в моём случае идёт только о маркировке. Последующую работу по корректировке сигнала предполагается выполнять на управляющем компьютере автоматически или при взаимодействии с оператором. Программировать эти алгоритмы на FPGA LTR-35 скорее всего не целесообразно.

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

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

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

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

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

Обновлённое руководство пользователя LTR предполагается выложить на следующей неделе. Там, в т.ч, более подробно будут описаны реализованные функции цифрового ввода-вывода LTR35. Сейчас в реализованном (только в потоковом режиме) синхронном цифровом вводе, время первого введённого бита выравнено на время первого отсчёта на выходе ЦАП после запуска потока ввода-вывода. Как объяснил выше коллега, такую же идею нам было бы совсем логично реализовать и для циклического режима - это развитие LTR35 и было запланировано, мы ждём сформулированной потребности от пользователей.

Оба предложенных способа для моих целей годятся.

Для способа с синхронным вводом цифровых входов тогда нужен точный алгоритм сопоставления введённых битов и соответствующего места в буфере с учётом всех задержек внутри LTR-35. Также нужен способ узнавать о том, что было переполнение и/или исчерпание какого-либо буфера и данные «съехали», сделав этот алгоритм неактуальным. При этом не страшно, если ввод цифровых данных начнётся ранее вывода аналоговых, но нужно не допустить обратной ситуации. Также нужно учесть в алгоритме сопоставления моменты смены страниц буфера, а для этого получать информацию о таких моментах.

По поводу способа с посылкой номера отсчёта в циклическом буфере в ответ на внешний сигнал. Будет ли достаточно пропускной способности для генерируемого объёма информации, если внешние сигналы будут активны длительное время (если предполагается слать данные при наличии логической 1) или если внешние сигналы будут часто меняться (если предполагается слать данные в ответ на изменение состояния сигнала с 0 на 1 и наоборот)? Если пропускной способности достаточно, то такой вариант также годится.

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

Ещё прошу уточнить про алгоритм смены активной страницы буфера циклического воспроизведения. Возможны ли такие варианты?

1. поменять страницы как можно скорее после полной загрузки данных в неактивную страницу
2. поменять страницы как можно скорее, используя уже загруженные в неактивную страницу данные
3. дождаться очередного воспроизведения семпла с указанным номером в буфере и поменять страницы в этот момент
4. аналогично п. 3, но перед сменой страниц пропустить заданное количество циклов

Возможно ли будет по потоку цифровых данных понять, на каких битах эти данных произошла смена страницы?

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

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

В реализованном в настоящее время циклическом режиме LTR35 смена страниц памяти воспроизведения сигнала происходит  "по границам циклических записей" - после того, как с верхнего программного уровня придёт асинхронная команда на смену страниц. Причем, размер новой циклической записи может не совпадать с предыдущей. Но во всех каналах размер цикла должен быть одинаков. Всего в страницу можно записать до 4 Мотсчётов. Всего каналов - девять: восемь - для ЦАП, девятый - для синхронного  цифрового вывода. Понятно, что циклические сигналы для каналов ЦАП следует подготавливать соответствующим образом, чтобы для обеспечения "гладкой сшивки"  не было разрыва фазы от конца к началу текущего и следующего сигнала.
Выше мы пришли к тому, что в данном циклическом режиме LTR35 не хватает синхронного цифрового ввода - с этим мы согласились, поскольку это укладывается в концепцию развития LTR35.

Но хотелось бы понять:
- Устраивает ли, с Вашей точки зрения, данный функционал для решения сформулированного выше класса задач?
- Если не устраивает, то какие именно проблемы (ограничения) возникают?
- Отдельно прошу сформулировать: cинхронизации каких именно процессов не хватает в реализованном функционале? И какие именно количественные временны'е требования для этой синхронизации? (Простите, но не количественное требование "как можно скорее" в рассмотрение приниматься не может).

Замечу, что данное обсуждение с техподдержкой на форуме идёт в контексте развития LTR35 как серийного изделия общего применения. И в этом контексте, естественно, следует отталкиваться от того, что реализовано...

Отредактировано Инженер (07.11.2020 11:08:23)

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

Тогда остаются 2 вопроса:

1. Контроль за сменой страниц. В частности, как узнать, когда произошла смена страниц (сколько полных циклов было воспроизведено до смены)? Можно ли это будет сделать, анализируя индексную часть данных битового потока с цифровых входов (о чём шла речь выше)? Можно ли посылать следующую команду на смену страницы, не дожидаясь выполнения предыдущей (с целью гарантировать воспроизведение страницы строго 1 раз и после этого — смену страниц)?

2. Что можно сделать в ситуации, когда в процессе длительного воспроизведения страницы (с большим объёмом данных и на маленькой частоте) возникла необходимость прекратить этот процесс досрочно? Желательное время реакции порядка секунды (десятые доли секунды — хорошо, 2-3 секунды — тоже годится).

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

Более того, если в потоковом режиме один из цифровых выходов LTR35 соединить с первым дискретным входом, то это позволит как угодно разметить входной поток относительно выходного со всеми нужными привязками. При этом, второй дискретный вход можно использовать для  разметки нужных мест в потоке внешним сигналом. -  2-канальный синхронный ввод уже реализован, и вообще, для этого уже у нас готов весь нужный функционал! А оставшиеся дискретные выходы LTR35 можно использовать как выходы строчных и кадровых синхроимпульсов, если речь идёт о задаче управления двумерной развёрткой.

Отредактировано Инженер (07.11.2020 16:23:49)

Такая мысль у меня возникала. Но есть большое подозрение, что при электрическом соединении цифрового входа и выхода будет набегать ошибка в пределах одного периода в обе стороны, причём неконтролируемая. Это создаст много проблем при конструировании и отладке сигнала развёртки с точностью до семпла.

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

В подобном "кольцевом" тесте цифровых выходов и входов (в потоковом режиме) мы проверяли LTR35 недавно. Точность привязки - до 1-го бита на скорости ввода 4,6 Мбод каждого канала в двухканальном режиме - это составляет очень малую величину относительно одного периода преобразования ЦАП (цифровые выходы обновляются с частотой преобразования ЦАП).

Отредактировано Инженер (07.11.2020 17:18:54)

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

Тогда, по всей видимости, LTR-35 удовлетворяет нашим потребностям без дополнительной доработки.

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

Цитирую выборочно ревизию 4.0.0 руководства пользователя, которая готовится к выходу:
17.4.4    Цифровой ввод-вывод в LTR35 – подробности.
17.4.4.1    Поведение цифровых линий DO и DI.
Когда воспроизведение данных не запущено, на выходах DO1 - DO8 присутствует 3-е состояние.
Когда воспроизведение данных запущено, выходы переходят в логическое состояние, в зависимости от данных, записанных в буфер LTR35. Программное управление  3 им состоянием – зависимое, одинаковое для всех выходов  DO1 - DO8.
....
17.4.4.2    Учёт задержки вывода на выходах OUT по отношению к  выходу DO.
Данная задержка, главным образом, определяется групповой задержкой PCM4104, равной 29-ти периодам преобразования ЦАП. Данная задержка компенсируется с помощью FPGA. Время задержки сигналов цифрового вывода выровнено по отношению к сигналам аналогового вывода с точностью до 1-го периода преобразования (Сноска: Параметр является типовым в нормальных условиях, без учёта влияния импеданса нагрузки выходов, и специально при производстве LTR35 не контролируется.) .
17.4.4.3    Задержка синхронного ввода данных через DI по отношению к синхронному выводу через DO.
Если выход DO соединить с входом DI, то старший бит первого слова, пришедшего от DI, будет соответствовать времени первого слова выданного на DO.
...
...На следующей неделе планируется выложить ревизию 4.0.0 руководства пользователя (вышеуказанные номера пунктов могут съехать, поскольку эта глава как раз дописывается).

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

И исходя из этого всё же остался вопрос, возможно ли сделать переключение страниц в заданных местах: указать, на каком месте одной страницы буфера воспроизведение закончить и с какого места другой страницы начать воспроизведение сразу после этого?

Алексей, Вы можете договариваться насчёт LTR35-1-8, LTR35-1-4 или LTR35-2-8 с нашим отделом продаж, сославшись на меня. Обеспечим Вам модуль в приоритетном порядке (срок уточню позже).

В потоковом режиме LTR35 только одна страница - это обычный буфер FIFO (до 8 Mотсч.). Вы хотите возвратиться к обсуждению возможного развития циклического режима?

Да, хочу понять, возможно ли будет в перспективе заказать такую доработку для циклического режима или же это технически невозможно?