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

Алексей. Я не утверждал, что этот бит должен отсутствовать, я только прокомментировал для чего его можно (нужно) использовать.

Правильно ли я понимаю, что в случае переполнения буфера его состояние может стать неопределённым, и для надёжности все данные из буфера нужно вычитать и  проигнорировать, дождавшись его заполнения новыми (валидными) данными?

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

Отредактировано Инженер (25.04.2020 16:14:26)

"Такая задача у нас никогда не решалась" - поскольку большого смысла нет в решении этой задачи. Проще сбор данных перезапустить.

Спасибо, понятно.

А можно ещё уточнить про появление бита 14 в данных цифрового канала:

1. Свидетельствует ли появление этого бита об ошибке (нештатной ситуации) в случае, когда внешняя синхронизация не используется и признака переполнения нет?

2. Известен ли алгоритм появления этого бита при таких условиях? Или же его появление следует считать случайным (и никаких выводов из этого делать не следует)?

По поведению бита 14 прошу ответить наших программистов. Оно точно не случайно.

Алексей, обратите, пожалуйста, внимание, что, исходя из архитектуры E20-10, он не успевать не может! Аппаратно гарантированная собственная пропускная способность E20-10 передачи по каналу USB BULK - выше 20 МB/s. Но E20-10 здесь выполняет функцию SLAVE - данные забирает компьютер. Буфер FIFO в E20-10 сделан для того, чтобы постоянно были готовы данные на передачу, и это действительно так!
Налицо проблема с пониженной пропускной способности откачки данных по BULK USB у Вашего ПК. Нужно искать причину.

По руководству https://www.lcard.ru/download/e20_10_users_guide.pdf  условия п. 6.5.1. "Подключения к USB" у Вас соблюдены?

У E20-10 рев.С буфер FIFO вдвое больше (16 МB), чем у рев.B (8 МВ). - При прочих равных это может сильно снизить вероятность переполнения из-за притормаживания ОС Вашего компьютера.
Притормаживание ОС может быть по банальным причинам (своппинг содержимого ОЗУ на диск, активность антивируса, почтовых программ, сетевых приложений, автообновление какого-нибудь ПО). В конце концов, Ваше ПО может быть так написано (об этом я судить не могу). Может, приоритеты процессов стоят как-то неоптимально. Нужно смотреть системную статистику: что происходит в системе при возникновения переполнения E20-10?  Наверняка при этом в системе какое-нибудь грандиозное событие началось (пиковая загрузка процессора, пиковое использование ОЗУ, своппинг, тяжеловесный процесс начал грузить...)

Да, условия подключения из п. 6.5.1 соблюдены. Использован разъём USB3.0 на системной плате (не выносной). К другим разъёмам этого же контроллера USB ничего не подключено. USB-кабель - из комплекта E20-10. ПО написано мною самостоятельно. За основу взят пример из документации lcomp. ПО по сути дела занимается только записью получаемых данных E20-10 на диск (через дополнительный программный буфер большого размера, который задействуется при необходимости - переполнений этого буфера не наблюдалось). Плюс в отдельном потоке осуществляется графичесчкая визуализация - данные для неё берутся из дополнительного буфера, не блокируя основной поток, а также подгрузка данных в модуль LTR34 через другой контроллер USB.

Значит, остаются системные причины. E20-10 не успевать не может - из этого нужно исходить, прежде всего.

Драйвера материнской платы установлены? Сообщите тип материнской платы.

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

Персональный компьютер в составе: (Корпус InWin EAR-013 Black
ATX 500W (USB3.0, Audio), процессор S1151 Intel Xeon E3-1240 v6
OEM (3.7 ГГц, Quad Core, Kaby Lake), купер Arctic Cooling Alpine 11
PLUS (S755/1155/1156, TDP100W, 11-24dB,
600/2500rpm), вентилятор Arctic Cooling F12 PWM v2, материнская
плата ASUS S1151 P10S-X, оперативная память DDR4 8Gb
2400MHz PC-19200 Kingston ECC (KVR24E17S8/8) х2шт, привод
DVD-RW ASUS DRW-24D5MT "SATA" Black OEM, жесткий диск
HDD 2000Gb SATA-Ill WD Gold [WD2005FBYZ, 7200rpm, 128Mb] x 2шт

Данные операционной системы:

uname -a
Linux emr102 4.15.0-96-generic #97-Ubuntu SMP Wed Apr 1 03:25:46 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

1. Например, возникла ситуация задействования большого программого буфера. Он в физическое ОЗУ у Вас  полностью и всегда помещается при реальной работе системы? Если нет, то своппинг будет между ОЗУ и диском, который и есть причина притормаживания.
2. Этот физический диск и системный диск - это разные физические устройства?

Температура процессора не приближается к установленным в BIOS штатным пределам? Если приближается, то это может быть причиной притормаживания.

Ничего подозрительного из вышеперечисленного не замечено. Для записи данных установлен отдельный диск (точнее, raid из двух дисков). Свободной ОЗУ в процессе работы было с большим избытком. Штатные средства контроля температуры элементов системной платы установлены, с их стороны никаких аварийных сигналов не наблюдалось (они записываются в лог-файл).

Я попрошу наших программистов устроить, как минимум, суточное тестирование E20-10 рев.В под LCOMP в технологическом режиме с замещением данных АЦП счётчиком. О результатах сообщу.

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

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

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

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

Нет, с цифровыми каналами ресурсов, наоборот, стало использоваться меньше.

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

С цифровыми каналами всё уже есть в готовом виде. Требуется только подсчёт битов и/или переключений битов. Это существенно меньшее количество операций.

Ну и в том, и в другом случае - это фактически складирование на диск. Обработка онлайн проводится в минимальном объёме для целей визуализации и управления экспериментом, это не занимает много ресурсов. Основная обработка проводится после измерений по записанным данным.

Посмотрел. Вся логика буферизации данных в FPGA идентична.

Изучили более внимательно характер повторов. Привожу краткое описание (возможно, оно поможет разобраться в сути проблемы).

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

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

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

Алексей, а светодиод на модуле был в каком состоянии?
Если зелёным мигал, - это нормальный режим.
Если красным и зелёным попеременно подмигивал после первого возникшего переполнения до остановки сбора данных ( https://www.lcard.ru/download/e2010_pro … _guide.pdf , стр. 42 ) - по сути, это - индикация нештатного режима.