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

Уточните, пожалуйста, какой именно файл нужно было взять и куда положить.

Сделано было следующее:

1. В директории dstr был запущен скрипт build, далее использовались получившиеся в результате модули .ko

2. Для компиляции моей программы была использована директория include, находящаяся внутри dstr

Достаточно ли этого или нужно ещё что-то сделать?

Исходный код и файл сейчас пришлю.

В папке distr\lcomp сама библиотека .so, в которой исправление и было.

Помогло. Спасибо!

Теперь вроде бы всё работает правильно.

Алексей, благодарим Вас за большую работу по тестированию и за большое потраченное время! Сообщайте о результатах эксплуатации E20-10 c новыми возможностями - будем рады узнать.
Если от Вас будет фото с кратким описанием решаемой задачи и с кратким описанием достигнутых результатов, будем рады оформить страницу Вашего проекта в нашем разделе http://www.lcard.ru/portfolio со ссылками на разработчиков и организацию. Материалы можно выслать на support@lcard.ru c темой письма "Для портфолио".

На всякий случай проверил - программное обеспечение с цифровыми каналами также работает правильно с другим устройством E20-10 (2014 года выпуска).

Спасибо, Алексей. Синхронные цифровые каналы обязаны работать (после обновления ПО) со всеми E20-10 ревизий B или B.01 любых лет выпуска и будут поддержаны в будущих программно совместимых ревизиях E20-10 - это один из важных мотивов того, что мы взялись за эту работу. L-Card - это производство, прежде всего. А значит, к совершенствованию своей серийной продукции у нас наивысший интерес. Вашу частную задачу удалось распространить на достаточно общий случай, интересный и другим пользователям, а значит, потенциально оправдать эту работу для производства L-Card.
Кстати, вообще, в истории серийной продукции предприятий довольно мало примеров того, что некая компания добавляет новый функционал в ранее выпущенные изделия. Но, это не первый такой случай у L-Card. Например, в 2014 г. в крейты LTR-EU постфактум был добавлен новый интерфейс IRIG-B с внешней системой единого времени - тогда тоже была разработана соответствующая прошивка FPGA и ПО. Любые изделия L-Card, содержащие FPGA, это всегда нечто большее, чем есть на сегодняшний день, поскольку разработчиком всегда закладывается потенциал для развития. А по поводу принципа этого развития я сказал выше.

Отредактировано Гарманов Александр (26.12.2018 23:08:37)

Большое спасибо за разработку!

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

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

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

Алексей. Разработанное техническое решение синхронных цифровых каналов позволяет получить непрерывные цифровые потоки с разрешением 16,7 нс (частота дискретизации до 60 МГц) на фоне сбора данных АЦП. Казалось бы, частота следования импульсов - это вторичная вычисляемая величина с использованием собранных данных, и эту частоту можно было бы вычислять на верхнем программном уровне, допустим, в LGraph2 с применением механизма плагинов. В этом смысле, вычисление частоты - эта вторичная задача, не совсем относящаяся к системе сбора данных E20-10, хотя в качестве дополнительного сервиса это рассматривать можно.
По поводу необходимой Вам частоты дискретизации я спросил Вас сразу и Ваше пожелание ("Чем больше, тем лучше в пределах заявленных 10 МГц") было выполнено с 6-кратным запасом (для 2-х каналов АЦП и двух цифровых - с 2-кратным запасом и более). Правда (ходят байки), что в теоретической фундаментальной физике ошибка теории по отношению к практике на три порядка - это вполне допустимо. Не знаю, относится ли это к Вашей области экспериментальной физики, но запас в три порядка разработчик заложить не смог.  
C другой стороны, Ваше замечание

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

Отредактировано Гарманов Александр (27.12.2018 09:11:01)

Даже внутри Вашей новой постановки задачи уже зарыты следующие противоречия:
1. Количество переключений в единицу времени - это величина, обратная удвоенной частоте, а не частоте.
2. Чтобы вычислять частоту, нужно всегда рассматривать смежные интервалы. Кстати, метод смежных интервалов был реализован в LTR51 для аналогичной задачи. Принцип описан в http://www.lcard.ru/download/ltr.pdf в п. 11.3.4 (начиная с 4-го абзаца).
3.  Меандр - это дискретный сигнал со скважностью 2. В этом общепринятом контексте в Вашей постановке задачи  "измерение частоты цифровых меандров" непонятно. Вам требуется из цифровой последовательности сначала отфильтровать сигнал со скважностью 2, а затем определить его частоту?

С другой стороны, я не отрицаю полезности добавления в E20-10 функций частотомера сигнала со входов SYNC и START на основе задействования новых логических каналов. Только, во-первых, требуется проработка полноценной концепции такого частотомера для охвата большого количества пользовательских задач. Во-вторых,  заняться этой задачей разработчик FPGA в ближайшие полгода (грубо говоря) вряд ли сможет - у нас есть более приоритетные задачи.

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

И ещё предложение - сейчас на сайте Lcard информация про цифровые каналы E20-10 опубликована, но нигде не указаны два важных обстоятельства, до которых пользователю догадаться весьма непросто. Предлагаю опубликовать недостающую информацию.

1. В Руководстве пользователя указано, что сдвиговые регистры цифровых каналов выполняют сдвиг с частотой (60 МГц)/m. В опубликованном примере программы для linux за эту частоту сдвига отвечает параметр adcPar.t2.DigRate. Но нигде не указано, что m = adcPar.t2.DigRate + 1.

2. Для возможности использования на цифровых каналах каких-либо параметров m, кроме значения по умолчанию m=1, на ранее выпущенных устройствах E20-10 требуется перепрошивка AVR. Но про это нигде не написано (ни что перепрошивка требуется, ни как выполнить перепрошивку, ни где взять подходящий для этой цели файл прошивки).

В процессе эксплуатации E20-10 с цифровыми каналами выяснилась особенность. Был проведён эксперимент, построенный следующим образом. К E20-10 было подключено 2 аналоговых сигнала и 1 цифровой. Управляющая таблица состояла из 4 полей/ Попеременно считывались каждый из аналоговых сигналов и цифровой в промежутке между ними. Таким образом осуществлялся сбор непрерывного потока битов цифрового сигнала на фоне регистрации двух аналоговых сигналов. То есть на кадр с частотой 10 МГц регистрировалось по 24 бита с частотой 60 МГц. (Самый свежий бит каждого кадра имеет номер 0, самый старый - номер 23.)

Источником цифрового сигнала было ФЭУ, каждому срабатыванию которого соответствовал 1 регистрируемый бит (очень редко - 2 бита или больше). Поскольку ни само ФЭУ, ни регистрируемый им физический процесс не имеют никаких механизмов внутренней или внешней синхронизации, естественно было бы ожидать равномерного срабатывания битов в пределах статистической погрешности.

Однако в реальности оказалось, что частотности срабатывания битов различаются. Ниже приводится статистика за час наблюдений, хотя тенденция прослеживается как минимум на интервалах секундной длительности (10000 кадров). Логично предположить, что такой эффект может быть связан с внутренними механизмами работы E20-10 - переключением кадров, переключением каналов внутри кадра и т. п., что могло бы приводить к различным условиям детектирования битов в разных местах временной диаграммы одного кадра и/или "плаванию" частоты синхронизации сдвигового регистра на цифровом канале (в результате чего на разные биты приходятся разные по длительности интервалы времени).

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

№ бита / количество 1 / отн. смещение количества 1 от среднего значения по кадру
0 126339901   +0.000113325
1 126289957   -0.000282035
2 126416587   +0.000720375
3 126214183   -0.000881866
4 126452544   +0.00100501
5 126131338   -0.00153767
6 126312163   -0.000106251
7 126255215   -0.000557054
8 126375679   +0.000396545
9 126261478   -0.000507476
10 126590773   +0.00209924
11 126181389   -0.00114146
12 126210195   -0.000913435
13 126438877   +0.000896824
14 126330621   +0.000039863
15 126299269   -0.00020832
16 126600224   +0.00217406
17 126235045   -0.000716721
18 126249325   -0.00060368
19 126338499   +0.000102226
20 126354845   +0.000231622
21 126274558   -0.000403934
22 126538395   +0.00168461
23 126122985   -0.00160379

Всего прочитано битов: 213960818688
Всего прочитано 1:     3031814045
Доля 1:                0.0141699

Фрагмент программы, отвечающий за настройку АЦП:

adcPar.t2.s_Type = L_ADC_PARAM;
adcPar.t2.AutoInit = 1;
adcPar.t2.dRate = 10000.0;
adcPar.t2.dKadr = 0.0;

adcPar.t2.SynchroType = INT_START;

adcPar.t2.SynchroSrc = INT_CLK;
adcPar.t2.AdcIMask = SIG_0|SIG_1|SIG_2|GND_3;

adcPar.t2.DigRate = 0;

adcPar.t2.NCh = 4;
adcPar.t2.Chn[0] = 2; // BNC3 (Y)
adcPar.t2.Chn[1] = 5; // DI16/START (FEU)
adcPar.t2.Chn[2] = 1; // BNC2 (X)
adcPar.t2.Chn[3] = 5; // DI16/START (FEU)

adcPar.t2.FIFO = 32768;
adcPar.t2.IrqStep = 32768;
adcPar.t2.Pages = 8;
adcPar.t2.IrqEna = 1;
adcPar.t2.AdcEna = 1;

// extra sync mode
adcPar.t2.StartCnt = 0;
adcPar.t2.StopCnt = 0;
adcPar.t2.DM_Ena = 0;
adcPar.t2.SynchroMode = 0;
adcPar.t2.AdPorog = 0;

С моей точки зрения, естественно было бы это ожидать только в том случае, если с выхода ФЭУ импульсы имели бы равномерное распределение по времени, как у импульсного шумового процесса с полной корреляционной независимостью моментов времени возникновения соседних импульсов. У Вас имеются основания считать, что это так? Вы проверяли статистику процесса на выходе ФЭУ? Но если нет доказанных оснований считать, что импульсный процесс на выходе ФЭУ имеет равномерное распределение, то и бессмысленно ожидать равномерной статистики распределения значений битов 24-разрядного сдвигового регистра, в котором находятся эквидистантные дискретные отсчёты этого процесса.
С другой стороны, если появились какие-то сомнения в работе E20-10, то тестировать E20-10 ведь нужно, используя эталонный сигнал с заранее известными свойствами (или с контролируемыми свойствами эталонным Средством измерения)? Иначе, непонятно: каким образом техподдержке по E20-10 интерпретировать результаты экспериментов?
Также в подобных экспериментах переполнение внутреннего буфера E20-10 не должно возникать (ПК должен вовремя откачивать данные), иначе полученные данные нельзя считать непрерывными.

Отредактировано Гарманов Александр (06.01.2019 21:55:59)

В частности, к корреляционной взаимосвязи соседних цифровых отсчётов (и к искажению статистики вообще) могут приводить такие паразитные явления как: отражения в несогласованном кабеле, сквозные токи по экрану кабеля, вызывающие помехи, эффект метастабильности в триггерных схемах (формирователях сигнала с выхода ФЭУ), электромагнитные помехи, воздействующие на ФЭУ, физические "эффекты второго порядка" внутри ФЭУ, и т. д. - Это всё непосредственно относится к вопросу о статистических свойствах сигнала, который доходит до входа DI16/START E20-10.

С другой стороны, синхронный процесс в сдвиговый регистрах E20-10 управляется тем же генератором и той же системой синхронизации, которая используется в логике запуска АЦП E20-10 в рамках того же кадра сбора данных (генератор E20-10 в Ваших экспериментах - внутренний). В этой системе, величина фазового шума преобразования АЦП будет такого же порядка, что и фазовый шум синхронизации сдвигового регистра. Проверить величину фазового шума АЦП можно, например, по спектру поданного сигнала генератора (с известной низкой величиной фазового шума) - по ширине "расползания" спектральной линии. Но для этого спектр сигнала нужно получить со значительно большим разрешением по частоте (1/NT), где N-количество отсчётов и Т-период дискретизации, чем искомое "расползание" (и использовать взвешивание  "окном" с низким уровнем боковых лепестков спектральных линий). Вообще, метрологией фазовых шумов АЦП E20-10 мы никогда не занимались, с другой стороны, на повышенные фазовые шумы АЦП E20-10 никто ещё не жаловался, и такой проблемы замечено не было.
Аналогично можно проверить величину фазового шума цифрового синхронного канала, например, с использованием качественного TTL-сигнала от внешнего генератора с известной величиной фазового шума...

Данный эксперимент первоначально ставился с чисто физическими целями, без целей метрологии E20-10.
Целью было изучить статистику интервалов времени между последовательными (соседними) срабатываниями ФЭУ при различных условиях (условно называемых в тексте программы координатами X и Y, аналоговые каналы 3 и 2).

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

Времена срабатываний ФЭУ, конечно, нельзя считать полностью корреляционно независимыми, они зависят от наблюдаемого физического процесса (а также помех от рядом расположенного оборудования и т. п.).  Но если наблюдаемый эффект различной частотности битов отнести на счёт такой корреляционной зависимости, то кажется очень подозрительным, что возникшая в результате такой зависимости паразитная частота в точности совпала с частотой кадров 2,5 МГц (или была кратна этой частоте), а фаза такого паразитного периодического процесса оставалась стабильной (в пределах величины одного периода сдвигового регистра) более часа.

В любом случае спасибо за разъяснения. С учётом имеющейся информации мы продумаем и поставим корректный метрологический эксперимент.

Допустим, при некорректном сигнальном заземлении в системе Ваших приборов в спектре сквозного тока, протекающего по экрану кабеля цифровых сигналов, имеется составляющая кондуктивных помех от Е20…10 с частотами, кратными частоте кадров Е20-10.. Если к тому же фронты цифровых сигналов, доходящих до входа Е20–10, достаточно медленные, то это сочетание  эффектов даст фазовую модуляцию сигнала  с частотой кадров. Медленные  или немонотонные фронты могут быть по причине несогласованности кабеля. Полоса частот сигналов, имеющая отношение к данным эффектам, - сотни мегагерц, учитывая скорость цифровых фронтов. Вопросы качества согласования и заземления в такой системе - экстра важные, если  паразитные эффекты не должны влиять на большую статистику....
...Отдельная история - с помехами в системе, кратными частоте питающей сети...

Один из примеров повышения качества передачи синхросигналов между разными E20-10 приведён в
http://www.lcard.ru/download/e20-10_conn_examples.pdf (п.9, стр. 6), который был с успехом проверен в сложном случае системной интеграции.
Фактически это переход с интерфейса TTL на МLVDS, который обеспечивает лучшее качество передачи сигнала (даже на фоне негативных факторов, перечисленных выше).
TTL - это ближний внутриблочный интерфейс, который хорошо работает только тогда, когда земли передатчика и приёмника эквипотенциальны в широкой полосе частот (сотни МГц). Это достижимо в пределах одного блока. Если соединение TTL- межблочное, то оно должно быть "кратчайшим путём", что и указано в Руководстве пользователя http://www.lcard.ru/download/e20_10_users_guide.pdf , п.6.5.5.
Ваши требованиях к качеству сигнала, подаваемого на синхронный цифровой вход E20-10, соответствует наивысшим требованиям к сигналам синхронизации (кстати, это не было очевидно в Вашей первоначальной постановке задачи). Это означает, что полуметровый кабель, сделанный под заказ для Вас, не соответствует техтребованиям задачи, поскольку эти техтребования ранее были неизвестны, в частности:

- отсюда совершенно не следовало, что Вы предъявляете экстра-требования к минимизации вносимых фазовых шумов при передаче "цифровых данных".

Отредактировано Гарманов Александр (07.01.2019 10:38:24)

Технически возможна разработка простой платы-переходника, размещающейся внутри кожуха кабельной части разъёма Digital модуля Е20-10. На такой плате может быть расположена пара  приемопередатчиков MLVDS (сигналов синхронизации и синхронного цифрового ввода)  c конфигурируемым направлением и отверстия под запайку проводов кабеля. Вероятно, эта же идея может быть реализована в варианте платы-переходника на винтовые или нажимные клеммники, где пайка проводов не потребуется.

Принципиально также то, что если устраивать метрологию фазовых шумов преобразователя Е20-10, то необходимо обеспечивать и контролировать характеристики фазового шума непосредственно на контактах разъема Е20-10.

А потребуются ли при таком варианте какие-либо действия на стороне ФЭУ? Сейчас из ФЭУ торчит "хвост" коаксиального кабеля 50 Ом примерно полметра с BNC-розеткой на конце. Укоротить кабель при необходимости труда не составит. Поскольку корпус ФЭУ монолитный неразборный, сделать что-либо со схемой ФЭУ практически нереально.

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

Вопрос касается предполагаемого использования технологии MLVDS (которую вы предложили использовать, а у меня нет опыта работы с ней). Какие проблемы из перечисленных выше она может решить? Правильно ли я понимаю, что кроме приёмника MLVDS на стороне E20-10 потребуется ещё и передатчик MLVDS на стороне ФЭУ, или же приёмник cможет осуществлять приём сигнала ФЭУ непосредственно?

Если речь идёт о сокращении расстояния (длины линии), то, видимо, это нецелесообразно, т. к. в самое близкое к ФЭУ место линии, куда технически возможно было бы поместить передатчик MLVDS, также возможно поместить и непосредственно сам модуль E20-10.

Если же речь идёт об использовании MLVDS в качестве гальванической изоляции между ФЭУ и E20-10 с целью устранения сквозных токов, то, возможно, такое решение поможет устранить проблему.

1. MLVDS предполагает передатчик и приёмник. Гальваноразвязку MLVDS не обеспечивает, но имеются решения и изолированного LVDS
https://www.analog.com/en/products/inte … mlvds.html
2. MLVDS позволяет передать с низким вносимым фазовым шумом на передаче.  Одну из возможных причин такого явления в TTL-интерфейсе я описал выше.
3. Я не предлагал Вам разработать конечный вариант применения MLVDS в Вашем случае. Я привёл пример решения проблемы качественной межблочной передачи синхросигнала (между разнесённых E20-10 на единицы метров), как альтернативу TTL (Пример общедоступен в документе Модуль E20-10. Типичные примеры подключения, п.9, стр. 6).
4. Если длину кабелей сильно сократите, то вносимый фазовый шум кабеля (при воздействии негативных факторов)  автоматически уменьшится, и MLVDS тогда не нужен.

Отредактировано Гарманов Александр (07.01.2019 17:20:12)

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

Отредактировано Гарманов Александр (08.01.2019 13:18:08)

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

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