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

Красного свечения светодиода не наблюдалось. Зелёный светодиод мигал.

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

Значит, это - штатый режим E20-10. 
Коллега уже написал тест под lusbapi c Вашими настройками кадра, со счётчиком данных вместо АЦП. Первые часы работы не показали проблем. Подождём результатов при более длительной работе. В любом случае, сначала - длительное тестирование под lusbapi. Если проблем не будет выявлено, то следующий этап - длительное тестирование под lcomp. Используется счётчик по модулю 65535 (64K-1). Это позволит обнаружить потери или перестановки блоков данных по размеру, кратных степени 2.

Спасибо. Ждём результатов.

А бит 14 в цифровом канале Chn[1] у вас появляется?

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

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

По биту 14 пока только прокомментирую логику FPGA. Эта маркер первого сэмпла в кадре после выполнения любого условия старта сбора данных. Но этот маркер вставляется только в том случае, если включён режим маркера. Если режим маркера выключен, то бит 14 обязан быть нулевым в рабочем состоянии системы сбора данных. Режимом маркера (как и всеми остальными настройками) управляет AVR модуля E20-10, непосредственно осуществляющий программное управление модулем E20-10 по USB. При включённом режиме маркера, если условие старта выполнилось один раз (запущен непрерывный поток данных), то появление этого маркера не на позиции первого сэмпла - это аномалия. Аномалия могла бы быть объяснена переполнением буфера (нерабочим состоянием системы сбора данных), но состояние светодиода в Вашем случае свидетельствует о том, что события переполнения не было. О событии переполнения FPGA сигнализирует прерыванием AVRу.  AVR управляет светодиодом E20-10.

Отредактировано Инженер (02.05.2020 10:58:41)

Алексей, если по каналам АЦП в Вашей системе https://www.lcard.ru/sites/default/file … meter1.png идут периодические сигналы развёртки, то моменты "разрывов битового потока цифрового канала" как соотносятся с фазой сигналов развёртки?

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

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

1. По поводу переполнения внутренненго буфера модуля  E20-10...
Была написана консольная утилита на базе библиотеки Lusbapi, которая позволяет мониторить непрерывность  передаваемой модулем тестовой последовательности данных с периодической проверкой признака переполнения внутреннего буфера модуля. Сбор данных осуществляется на частоте 10 МГц, управляющая таблица взята из Вашего сообщения #1. Эта утилита была запущена на прогон под Windows'7 (64bit). После 12 часов работы никаких сбоёв в работе модуля не проявилось. Сегодня (2 мая) попробую запустить утилиту на гораздо более длительный прогон до 5 мая. По результатам отпишусь.
2. По поводу появления 14-ого бита в цифровом канале модуля  E20-10...
Само по себе состояние одного лишь 14-ого бита в слове данных ещё ни о чём не говорит. ВажнО только совокупное состояние двух старших битов <15..14>.
Если оба эти бита равны "0", то это означает, что в младших 14-ти битах содержится положительное число.
Если оба эти бита равны "1", то это означает, что в младших 14-ти битах содержится отрицательное число.
Если состояние этих битов равно "01", то это означает начало непрерывного блока данных (маркер), а в младших битах содержится 14-битное знаковое число.
Всё это безусловно верно для данных с аналоговых каналов. А вот для цифровых каналов я не знаю как именно расширяется условный знаковый бит (13-ый бит в слове данных) на состояние двух старших битов <15..14>. Подробнее смотри п.5.2.3. "Формат данных E20-10" руководства пользователя.
3. А как именно с помощью LComp программно фиксировался факт переполнения буфера FIFO E20-10?

По поводу поля <15..14>: выше я комментировал логику FPGA бита 14 - как она была задумана и описана в п.5.2.3 руководства пользователя. При создании прошивок FPGA 2.00.13 и 2.00.14 для отчёта данных синхронного цифрового канала значение поля <15..14> специально не отлаживалось и не проверялось. Сейчас по исходникам прошивок  2.00.13 и 2.00.14 я увидел, что в фазе передачи в USB данных цифрового канала значение поля <15..14> подставляется неверно. А именно, для данных цифровых каналов в прошивках  2.00.13 и 2.00.14 происходит так:
<15..14> = "01" в случае передачи маркера начала  первого сэмпла в кадре после выполнения любого условия старта сбора данных;
<15..14> = "00" в случае отсутствия передачи маркера начала первого сэмпла, если бит <13> текущего сэмпла равен "0";
<15..14> = "11" в случае отсутствия передачи маркера начала первого сэмпла, если бит <13> текущего сэмпла равен "1".
<15..14> = "10" логически недостижимое состояние (оно возможно только в случае какого-либо сбоя).

Сергею: В прошивках 2.00.13 и 2.00.14,  в случае тестового режима  (подстановки счётчика <15...0> вместо данных АЦП) данные цифрового ввода специально анализировать не нужно, смысла они не несут.

Никак не фиксировался. Сначала мы ошибочно воспринимали старшие биты 01 как начало непрерывного участка после переполнения буфера. Как выяснилось здесь в результате обсуждения - это было неверно.

Также выше было сказано, что после первого переполнения буфера и до конца сбора данных должна быть индикация красным светодиодом. Поскольку её не было - видимо, можно полагать, что переполнения буфера FIFO отсутствовали.

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

Алексей, еще раз констатируйте, пожалуйста, при работе с какой прошивкой FPGA, в каких данных (цифрового ввода или данных АЦП) Вы встречаете <15..14> = "01". Какой характер этих событий (как часто встречаются)? В первом отсчёте это событие есть?

Отредактировано Инженер (02.05.2020 13:38:49)

Прошивка - из нашего предыдущего заказа (когда были добавлены каналы цифрового ввода). Последний вариант прошивки, полученный от L-card по почте.
Структура кадра - как указано в первом сообщении.

Биты <15..14> = "01" встречаются в канале, задаваемом как adcPar.t2.Chn[1]=6. При этом в adcPar.t2.Chn[3]=6 такие биты не встречаются (там всегда <15..14> = "00").

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

Алексей, в первом отсчёте от E20-10 <15..14> = "01" ?

Нет, в первом отсчёте "00". (Посмотрел несколько десятков записей экспериментов, везде "00", ничего другого не нашлось).

Могу подвести промежуточной итог на основе сообщённых выше исходных данных:
По логике FPGA появление в данных значений  <15..14> = "01" было невозможно. Если такие данные появлялись, то возможны следующие аномальные варианты:
1. На E20-10 в данных условиях действуют специфические факторы ЭМС (внешние электромагнитные поля или кондуктивные помехи), которые вызывают сбой механизма буферизации в E20-10.
2. Попался экземпляр E20-10 с плавающей неисправностью по типу ненадёжного контакта, или неисправности, возникающей при нагреве (я предполагаю, что температура воздуха в лаборатории была не запредельной).
3. Имеется ранее незамеченная проблема в lcomp c целостностью передаваемых данных от E20-10 или с некорректной передачей настроек в E20-10.
4. В пользовательском ПО верхнего уровня имеется проблема с порчей памяти, или другая проблема, нарушающая целостность данных, записываемых на HDD.

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

Просмотрели большое количество записей экспериментов, сделанных в одинаковых условиях с одинаковым ПО.

Среди них обнаружились записи двух типов.
Тип 1. Биты <15..14> дублируют бит 13 - между ними имеется однозначная связь.
Тип 2. В битах <15..14> в первом считывании цифрового канала в кадре встречается комбинация "01"; логика её появления непонятна, взаимосвязи битов 15 и 14 с битом 13 не прослеживается (они ведут себя независимо).

Из вышеизложенного действительно логично предположить плавующую неисправность типа "плохой контакт".

Правда, непонятно, как всё это объясняет частичные повторы данных по 4 раза. ("Плохой контакт/бит" в каком-то адресном регистре?)

В нынешней ситуации мы не готовы прямо сейчас заказывать разработку средств отладки по ряду причин, в частности:
1. Непонятно, есть ли вообще смысл изучать проблемы E20-10 ревизии B, раз эта ревизия уже снята с производства. А в ревизии C этих проблем вполне может и не оказаться (проверить это до приостановки работы института в связи с коронавирусом мы не успели).
2. Сейчас невозможно включить эти работы в план финансирования и провести оплату.
3. Также невозможно в ближайшее (да и вообще непонятно какое) время возобновить эксперименты и применить всё это на практике.

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

PS.

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

А в данных АЦП тоже обнаружены повторы в тех же самых кадрах? Какое максимальное и минимальное время цикла при повторах Вы обнаружили (если время считать в кадрах)?

Да, под "повтором" имеется ввиду повтор всего кадра целиком, включающего данные АЦП и цифровых каналов, один в один.

Типичное "время корреляции": 8192 кадра. Выглядит это в типичной ситуации так, как уже было описано выше:

Идут нормальные данные. Затем последний кусок этих данных длиной точно 8192 кадра повторяется ещё 2 раза. Затем следует начальный фрагмент повторяемого куска (т. е. уже четвёртый экземпляр одних и тех же данных) длиной от нескольких десятков до примерно 200 кадров. Эта длина - переменная и каждый раз различна, но статистика таких длин носит волнообразный характер - короткие "хвосты" сменяются длинными, а затем обратно. "Период" такой волны - примерно 2400 вышеописанных ситуаций.

Затем возобновляется нормальный поток данных.

Кроме того, реже встречаются ситуации, когда идёт повтор не по 4, а только по 2 раза кусков, отстоящих друг от друга также на 8192 кадра. Длина таких кусков - от 1 кадра до примерно 200. Причём чем длиннее повторяющийся кусок, тем реже такое случается. Если повтор единичных кадров через 8192 кадра можно объяснить случайностью, то повтор куска из нескольких десятков кадров явно неслучаен.

Вы эти повторы видели в данных, полученных только от одного экземпляра E20-10?

Да, на данный момент все проанализированные на предмет указанных выше проблем записи относятся к одному экземпляру E20-10.

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

Серийный номер этого экземпляра: 6T366070.

А кстати какое значение IrqStep у Вас использовалось в настройках? Как изначально в примере 32768 (adcPar.t2.IrqStep = 32768;)?

Да, 32768.

Т.е., если я правильно понимаю, то период повторения данных у Вас равен шагу передачи данных по USB (8192 кадров по 4 канала в таблице = 32768 отсчетов).  Может быть совпадением (жаль у Вас нет сейчас возможности проверить с другим шагом), но нужно будет посмотреть в эту сторону...
А на других модулях с другой таблицей у Вас тоже была таблица на 4 канала? Если нет, то Вы проверяли повторы с шагом в 32768 отсчетов или 8192 кадров?

Я попутно замечу, что характерная цикличность данного эффекта -  32768 отчётов -  не является каким-то характерным размером, с точки зрения работы системы буферизации внутри E20-10.  Подобный эффект (со стойким размером 32768 отчётов) мог бы возникнуть внутри E20-10 разве что при очень экзотической неисправности, либо вследствие какой-то сильнейшей специфической направленной помехи (проблемы ЭМС). Замечу также, что логика системы буферизации в E20-10 (в которой потенциально могли бы возникнуть повторы 32768 отчётов) не зависит ни от настроек кадра сбора данных, ни от версии прошивки FPGA (это отработанная за много лет неизменная логическая часть проекта FPGA).

Отредактировано Инженер (04.05.2020 15:35:47)