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

Здравствуйте. Подскажите пожалуйста, почему возникает ошибка -140 при вызове функции X502_ProcessData(), при чем характер возникновения, не регулярный. Т. е. может обработать 1 блок и выдать ошибку, а может и 12к блоков обработать. Исходный код взят из примера  x502_stream_read без изменений.

Добрый день.
Для начала на всякий случай проверьте версии прошивок ARM (последняя 1.0.20) и ПЛИС (из последнего sdk с сайта). По крайней мере на последних версиях такого быть не должно.

Если обновление не поможет, тогда видимо нужно будет сохранять в файл поток из Recv до ProcessData, чтобы увидеть, как выглядит нарушение данных. Работаете по USB или Ethernet? В примере сами настройки сбора данных изменяли или вообще никаких правок не было?

Какой дистрибутив Linux используете?

Алексей, здравствуйте.
Версии прошивок: fpga=0.14, plda=2,mcu_firmware=1.0.20.0.
АЦП подключен по USB. В примере никаких настроек не менял. Изменил цикл с for на while. Для написания программ пользуюсь Code::Blocks IDE.
OS Raspbian 9.

При просмотре сохраненного буфера, выяснилось что потеряна часть отсчетов. В OS Ubuntu 16.04 такой проблемы нет, от слова совсем. Тестировал в течении трёх недель. Я так понимаю данная проблема связана с самой OS Raspbian. Подскажите пожалуйста как с этим справиться.

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

Здравствуйте Алексей. Потерю отсчетов выявил просматривая проблемную часть буфера, оказалась нарушена последовательность  нумерации каналов. Также мне пришлось немного переписать код. (-- -- 00 D0 -- -- 00 D1 -- -- 00 D2 -- -- 00 D3 -- -- 00 D1 -- -- 00 D3). Плюс размер буфера был меньше заданного (timout установил заведомо большим). Отключение цифровых входов и изменение частоты не как не влияет на возникновение данной ошибки. Что как мне кажется указывает на причастность OS к данной проблеме.

В смысле Recv вернул меньше, чем запрашивали? При этом именно на том блоке, где ошибка (или сперва блок меньше размером, а в следующем ошибка)?
Cбой последовательности при этом именно в принятой части (т.е. в отсчетах с номером до того, что вернула Recv())? Время выполнения функции при этом соответствует таймауту? Т.е. Recv именно подвисает на время таймаута, что Вы задали, или по каким то причинам выходит раньше?
Если после этого сделать еще Recv(), несмотря на ошибку, то данные какие-то придут или после этого вообще прием останавливается?
Если перед Recv() буфер явно обнулить все данные, то на данные это как-то повлияет на выходе (т.е. это именно разрыв в новых данных или может он по каким-то причинам не заполнил часть буфера и это остались данные от старого цикла в буфере)?
И это реальный пример, что разрыв по сути 2 раза через одно слово (нет D0 перед D1 и D2 после D1)?

И под размером буфера Вы имеете ввиду значение, которое вернула Recv или уже размер обработанных данных, который вернула функция ProcessData?

Здравствуйте, Алексей. Постараюсь ответить на все вопросы.

Параметры READ_BLOCK_SIZE=131072  и READ_TIMEOUT=600. Как я понял размер буфера возвращаемого Recv() равен 131072 значений, при этом функция вернёт эти данные не дожидаясь таймаута, согласно руководству программиста. Далее.  Да, функция возвращает блок меньшим размером чем запрашиваемый и соответственно последующий вызов функции ProcessData() возвращает ошибку.

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

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

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

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

И ещё просмотр логов системы не дал ни каких результатов.

А можно несколько примеров возвращаемого значения функцией Recv, когда оно не совпадает с запрошенным 131072 (в примере значение переменной rcv_size), чтобы понять порядок отличия. И это различие всегда разное?
Частота АЦП у Вас при этом 2 МГц?
Ну 600 мс не такой большой таймаут, визуально задержку одного Recv на это время может быть не так просто заметить, или как Вы проверяете, что таймаут не истек?
Можете программно засечь время выполнения Recv, а то что-то не вижу способа выйти из этой функции, кроме как по ошибке, таймауту или приему всех данных.

Здравствуйте, Алексей.

READ_BLOCK_SIZE = 131072 -- rcv_size =12367
READ_BLOCK_SIZE = 131072 -- rcv_size =131070
Из проведённых тестов могу сказать что всегда разное, один раз попалось отличие в один отсчет.

Да частота выставлена 2 МГц.

Вы абсолютно правы, Алексей. Измерение выполнения функции Recv(), подтвердило выход по тайм ауту.
Т.е., если при нормальном выполнении функции время колеблется в пределах 440 - 460 мс, то при ошибке равно тайм ауту. Увеличил  тайм аут до 1000.
время выполнения функции составило 914 мс.
READ_BLOCK_SIZE = 131072 -- rcv_size =131072
ОШИБКА -140, по прежнему на месте.
Думал что симптомы похожи на отключения портов при нехватке питания но замена блока питания на 5V 3.5 А не помогла. Всё по прежнему.

Здравствуйте, Алексей.
Разобрался с проблемой. Как говорится "дело было не в бобине...". Проблема с приёмом данных возникала в буфере USB HUB, драйвер dwc_otg по умолчанию использует быстрые прерывания (fiq) и обработчик fiq_fsm. Который, как раз и теряет буфер хаба. Чтобы избавится от данной проблемы нужно в "/boot/cmdline.txt" добавить несколько  параметров старта ядра:
dwc_otg.fiq_enable=0   -для отключения использования fiq
dwc_otg.fiq_fsm_enable=0  -если не отключить  fiq_fsm то kernell всё равно запустит fiq а следом и fiq_fsm.
dwc_otg.nak_holoff=0   -для отключения задержки между повторными прерываниями.
И всё работает, уже в течении суток.
Алексей, благодарю за помощь. Всего наилучшего.

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

День добрый!
Не подскажите, заводится ли LGraph2 на малинке через вайн? Работает ли считывание данных в ней? У самого 14-440 еще на юзб 1.1) Рассматриваем различные варианты сейчас, для создания измерительного стенда и хотим избавиться из цепочки из ноутбука и попробовать на замену малину, чтобы сделать более мобильный вариант установки.

Добрый день.
К сожалению нет. Во первых, LGraph2 собран для архитектуры x86, а на малине у Вас ARM (ARMv7-A  или ARMv8-A в зависимости от версии). Для запуска под wine нужно, чтобы целевая архитектура процессора была той же (ну или могла аппаратна эмулировать другую), т.к. wine по сути реализует winapi в linux в нативном виде, а не является виртуальной машиной.
Во вторых в любом случае драйвера для нестандартных устройств разные для linux и windows, а wine может эмулировать winapi только для пользовательского кода, поэтому даже под x86 L-Graph не увидит устройства в linux (за исключением разве что модулей LTR, т.к. там идет работа через отдельную службу, которая есть под linux).

Так что тут скорее всего понадобится уже непосредственно linux-приложение собранное под нужную архитектуру.

А какие возможности используете в LGraph и когдие у Вас сроки создания стенда?

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

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