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

Здравствуйте, L-CARD!

  Мы уже несколько лет используемваши ацп (E140) в нашей лаборатории. Недавно приобрели у вас небольшую партию ацп (E140, E440). Я в лаборатории занимаюсь написанием и сопровождением программы сбора данных, которая работает с этим модулем. Е440 пока не использовали, так что речь идет о E140.

  Чтобы была понятна проблема, я достаточно подробно опишу задачу.
  Программа написана на delphi 7
  Задача такая - программа осуществляет сбор данных понескольким физическим каналам и записывает информацию в файлы данных. Файл данных может содержать отодного до 16 каналов информации. Сбор данных должен производиться длительное время - речь идет о днях, неделях и так далее. Частота дискретизации задается в пределдах нескольких килогерц на канал - выбирается оператором программы. Как и количество активных каналов. Может быть как 1 так и 3, 4, 7... зависит от конкретной ситуации.
В процессе сбора данных программа также производит некоторую простую обработку данных прежде чем скинуть буфер в файл - коррекцию встроенными коэффициентами коррекции нуля и масштаба, перевод отсчетов в вольты, вывод на экран в виде осциллограммы и спектра. На диск информация записывается файлами фиксированной длительности, длительность выбирает оператор. Например, "записать 100 файлов по 1 час каждый".
Размер буфера в программе всегда кратный 32. Он выбирается оператором в настройках программы. Число, которое выбирает оператор всегда умножается на 32. Например 32*32 или 32*512. То есть оператор вводит только 512 а программа умножает на 32.

  В общем программа написана давно и работает, и все вроде бы устаривает, но есть одна очень неприятная проблема.
  Чтение данных из АЦП осуществляется как обычно - асинхронный режим, функция RedData(..) - WaitForSinglrObject(..)
  В случае, если размер буфера не кратен размеру кадра (количеству логических каналов) то отсчеты отдельных каналов в буфере распологаются в заданном мной порядке (1-2-3, в случае 3 каналов) только в буфере, полученном при самом первом после старта ацп запросе. Во буфере после второго запроса будет уже 2-3-1, потом 3-1-2 и так по кругу.

Это само по себе уже плохо. По идее, каналы всегда должны идти в том порядке, в каком я их задал в управляющей таблице. Ну, ладно. Я написал функцию которая постоянно отслеживает номер канала и решает этй проблему (работает с переменной FIrstInBufer, в которую помещает номер того канала, с которого начнется буфер после следующегго запроса - такой геморой)
  Это все РАБОТАЕТ, может работать пару дней непрерывно. Но иногда по какой-либо причине винда задумывается, напимер при каком-то событии в сети - а компьютер подключен в сеть - это необходимо) и ВСЕ! все каналы перепутываются, файл с данными, который записывался может час или два ИСПОРЧЕН.
Причем я никак не многу заставить программу отследить факт такой ошибки, так как для программы и для библиотеки никакой ошибки нет - все как бы работает как надо.

  Ну с этим как-то мирились - такие сбои происходили но не очень чвасто. тем не менее последнее время встал вопрос чтот надо что-то делать с этим.
  Переписал программу под новую библиотеку 3.3 и драйвер 5.0.0.0.

  В реководстве программиста LUSBAPI ясно сказано:
(стр32)
"... Полученные данные будут распологаться в буфере покадрово: 1 кадр, 2 кадр и тд. ПРИЧЕМ ПОЛОЖЕНИЕ ОТСЧЕТОВ В КАДРАХ БУДЕТ СОВПАДАТЬС ПОРЯДКОМ РАЗМЕЩЕНИЯ СООТВЕТСТВУЮЩИХ ЛОГИЧЕСКИХ КАНАЛОВ В УПРАВЛЯЮЩЕЙ ТАБЛИЦЕ ControlTable"

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

  Почему такое поведение никак не обозначено в руководстве?

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

С уважением
ТОИ ДВО РАН. Г. Владивосток

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

"Но иногда по какой-либо причине винда задумывается, например, при каком-то событии в сети - а компьютер подключен в сеть - это необходимо) и ВСЕ! все каналы перепутываются, файл с данными, который записывался может час или два ИСПОРЧЕН..."
Чтобы этого не было запросы RedData(..) необходимо ставить в очередь, как это описано в руководстве пользователя http://www.lcard.ru/download/e14_140_pr … guide.pdf. Смотри  про асинхронный режим работы в п.4.5.6 "Получение массива данных с АЦП". Использование очереди асинхронных запросов можно посмотреть в примерах программирования, например, в директории X://L-CDROM//USB//Lusbapi//E14-140//Examples//Borland C++ 5.02//ReadData//ReadData.cpp.

К сожалению, обеспечить расположение первого канала всегда в начале массива при непрерывном сборе при произвольном значении числа каналов невозможно теоретически.
Представим, что число каналов  3, размер массива 8. При втором заполнении массива первый канал при всем желании никак не сможет попасть на первое место.

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

Олег, спасибо за описание, но я немного не понял, что же Вы такое делаете...
Давайте рассмотрим поток данных от модуля как непрерывную последовательность 16-битных отсчетов. Они идут именно в соответствии с номерами логических каналов в кадре, т.е. 123123123123... от start_adc до stop_adc. А блоки (буферы) - это просто порции, которыми данные передаются в программу. Модуль вообще не знает о них, кроме разве что размера блока USB в 64 байта (отсюда требование кратности количества отсчетов 32).

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

Касаемо /'винда задумывается/' и очереди асинхронных запросов Сергей Вам ответил. Популярно смысл этого подхода в том, чтобы хотя бы одна незавершенная ReadData висела постоянно, т.е. не было дыр во времени, когда АЦП запущен, а к драйверу нет запросов на чтение.
Это обычно делается с помощью массива на 2 элемента и индексом, переключаемым между 0 и 1 по принципу /'первый готов, второй пошел/'. В начале работы запускается сразу ДВА запроса на чтение (один до цикла, второй в цикле).
Все это Вы увидите в примерах.

>Чтобы этого не было запросы RedData(..) >необходимо ставить в очередь, как это описано в >руководстве пользователя http://www.lcard.ru/>download/e14_140_programmers_guide.pdf. Смотри >про асинхронный режим работы в п.4.5

  Да, все правильно. Я так и делаю. Я уже почти наизусть выучил это руководство

Сделал сбор данных как в консольном примере с диска к АЦП. Я уже говорил, что вызов справки однозначно приводит к потере данных. Поэтому использую для тестирования - разблокировал кнопку ХЭЛП. размер буфера пока не трогаю - как есть. В данном случае 32*768 слов. Выбрано просто из удобства развертки сигнала на экране программы. Частота 50 кГц.
  Процедуру которая отслеживает номер канала с кот. начинается буфер отключил.
Выставляю 2, 4, 8 каналов одновременно, включаю сбор данных, работает. вызываю справку - происходит кратковременная потеря данных, но это не страшно. Каналы на месте. Все ок. выставляю 3 или 7 каналов - номера каналов путаются и с каждым новым буфером информация скачет по каналам по кольцу - ну так и должно быть, так работает процедура RedData - размер не кратен Ну ладно. Выставляю 6 каналов - все ок, но до тех пор пока не произошел сбой по вызову справки. После сбоя номера каналов поменялись и регистрация идет  дальше.
  Поймите, для нашей задачи в общем не страшен факт потери данных, тем более это случается редко.
Речь идет об одном сбое в сутки или даже в неделю.
Плохо что после этого сбоя премешиваются номера каналов.
  Скажите, можно ли как-то отследить факт такого сбоя? Я бы мог просто прекратить запись текущего файла и начать следующий. При этом все встает на место.

   По поводу очереди. Может быть имеет смысл предварительно выставить не один запрос, а больше - 10, 20? Поможет ди это?

Спасибо за ответ! Вы писали:

>Олег, спасибо за описание, но я немного не >понял, что же Вы такое делаете...
>Давайте рассмотрим поток данных от модуля как >непрерывную последовательность 16-битных >отсчетов. Они идут именно в соответствии с >номерами логических каналов в кадре, т.е. >123123123123... от start_adc до stop_adc. А >блоки (буферы) - это просто порции, которыми >данные передаются в программу. Модуль вообще не >знает о них, кроме разве что размера блока USB в >64 байта (отсюда требование кратности количества >отсчетов 32).

   Попрбую объяснить что я делаю. В кратце - есть некий буфер в памяти куда поступает очередная порция информации "из" функции ReadData. Как только порция поступила, поток сбора данных отправляет эту порцию - буфер в основное приложение, которое производит обработку данных, а см (поток) выставляет следующий запрос. Пока выполняется следующий запрос приложение успевает поработать с предыдущей порцией - выводит один экран осциллограммы (он всегда равен одному буферу ниформации), производит коррекцию данных, и в итоге записыват эту порцию-буфер в файл данных. Это все происходит во время обработки следующего запроса. Потом все повторяется до тех пор пока оператор не остановит процесс вручную либо он не закончится автоматически после записи требуемого количества файлов.
   Да, все правильно, в ПОТОКЕ отсчеты идут один за другим- 1-2-3-1-2-3-1-2... Но при определенном отношении размера буфера и числа каналов в кадре получается так что в каждой новой порции данных порядок будет напрмер 2-3-1-2-3-1...  А мне нужно при записи порции в файл чтоб в файле каналы всегда распологались 123123123. ОНО ТАК И ЕСТЬ, ЭТО ОЧЕВИДНО. НО!!! только до сбоя. После Сбоя в приеме данных по USB, процесс сбора данных продолжается, но в файл отсчеты уже записываются (и выводятся на "осциллограф") в неправильном порядке.

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

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

Навскидку, очередь из двух запросов помогает если компьютер притормозил на время порядка 300 мс. Если больше - следует попробовать очередь из большего кол-во запросов.

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

10, 20 запросов выставить можно. С другой стороны, можно просто увеличить размер буфера.

Пример readdata.cpp слегка упрощен: в нем после Wait следующая ReadData идет не сразу, а после записи на диск. Предполагается, что это время прикрывает оставшийся один запрос на чтение, но если и он завершится, то плохо.
Может быть, надежнее сделать кольцевой буфер с массивом указателей (элемент кольца = 1 блок чтения) и переключать их (WaitFor, пометить блок как готовый, пометить следующий свободный как в-процессе-сбора и скорее ReadData в него). В такой схеме легко вписать и N запросов в начале.

С вызовом help не очень понимаю. Чтение - это отдельный thread? Можно приоритет ему поставить high, кстати.
Проверьте логику программы на предмет количества запущенных запросов ReadData() в каждый момент времени - может, все-таки есть дыры? Если нет, то тут вопрос уже в реакции ядра и размере буферов. Конфигурация системы какая (cpu, ram, версия ОС)?

Буфер USB 64 байта, так что при потере данных теряется кратно 32 отсчетам. Если число каналов в кадре - делитель 32, то потеряете целое число кадров...
Но все-таки лучше попробовать добиться стабильной работы, если позволяет машина.

>Может быть, надежнее сделать кольцевой буфер с >массивом указателей (элемент кольца = 1 блок >чтения) и переключать их (WaitFor, пометить блок

Вот сейчас как раз сделал массив из 100 элементов, В начале отправляю 10 запросов на чтение. Потом в процессе сбора идет по кольцу по всем 100 элементам.

   В общем все работает. У меня тут 4 разных компьютера - от пентиума 3 1200 мгц с 512 памяти (на нем сейчас пишу программу)до 4-ядерного с 4 гигабайтами. Еще 2 ноутбука. Везде стоит одна и та же XP SP3.

  Во время сбора данных с записью в файл загрузка процессора - от 8 до 13 процентов - это на старом PIII-1120. при этом программа еще рисует осциллограммы сигнала по двум любым каналам и вычисляет БПФ с выводом на экран. 

  Да, чтение - отдельный thread. Приоритет выставлен высокий. Буфер - ссылка на первый элемент глобальной переменной-массива.

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

  Что-то с вызовом справки (она в общем не очень нужна, но надо разобраться). Не пойму. В моент вызова справки загрузка процессора почти 100 процентов на время около пол-секунды. В этот момент и происходит сбой. Ывзов справки обычный стандартный средствами Делфы.
  Нужно сказать, что сейчас сбой в этот момент тоже происходит, но где-то в одном случае из 6-10 или реже. На старой версии это вызывало гарантированное перебрасывание каналов. Причем при открытии справочной системы ДРУГИХ приложений ничего не происходит. Странно.

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

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

Сейчас посмотрел - при вызове справки программ "замирает" на целую секунду... Странно

Функция ReadData() при работе в асинхронный режиме выставляет запрос системе и тут же возвращает управление приложению. При этом собственно сама передача данных может ещё и не начаться.

>Функция ReadData() при работе в асинхронный >режиме выставляет запрос системе и тут же >возвращает управление приложению. При этом >собственно сама передача данных может ещё и не >начаться.

Да это так. Я думал про функцию
GetOverlappedResult
  Я использую ее в процедуре чтения. Функция ведь возвращает количество переданных клиентом байтов.

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

Но ведь я же знаю сколько отсчетов я хочу передать - я заполняю поле NumberOfWordsToPass в структуре IO_REQUEST_LUSBAPI

  Предположим, что по окончании ввода порции данных GetOverlappedResult() вернула количество переданных байтов меньше чем NumberOfWordsToPass в байтовом выражении. Значит произошел сбой.
Или не получится?

GetOverlappedResult() в любом случае вернет "правильное" количество байтов даже если реально придет меньше информации из-за сбоя?

Получается замкнутый круг. Тогда отследить такой сбой можно только аппаратным способом...

Ну да, ведь потерянные данные НЕ ПРИШЛИ в драйвер, ReadData() попросту дождется следующих. Оборванная передача (размером меньше, чем запрошено) могла бы быть, если бы устройство специально оборвало передачу. Или по таймауту.

Разбирайтесь со справкой, почему на секунду система встает. Что-то не так.
Попробуйте для теста сделать размер одного реквеста ReadData() на много секунд (скажем,  мегабайт). В этом случае тоже оторвется?

Нормальная винда имеет право задумываться миллисекунд на 10-20, ну на 30, но никак ни на секунду. Может вирусы живут?

Секундные замирания ОС разве что E20-10 или
LTR-(E)U-2/8/16 смогут выдержать без сбоя на относительно небольших частотах сбора данных (там внутренние буфера от 8 до 32 MB)...

Я тут почитал все...есть несколько советов. Возможно приоритет потоку сбора нужно оставить нормальный. Ну или +1 к нормальному. Иногда черезмерный подъем приоритетов приводит к блокировке фоновых процессов которые потом лавинно в систему вваливаются вместо равномерного воздействия. И потом логику программы надо посмотреть на предмет межпроцессного взаимодействия с помощью сообщений. Запуск хелпа может сообщения подзадержать прилично и если это в логике критично то будут сбои. Взаимодействие все должно быть на настоящих евентах мутексах  и прочем..... Буфер 32*768 не сказать чтобы большой...

>Попробуйте для теста сделать размер одного >реквеста ReadData() на много секунд (скажем, >мегабайт). В этом случае тоже оторвется?

да, попробую сегодня.

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

  Похоже в голове прояснилось... Если ОС тормознет а уровне ЯДРА и несколько 64 байтных блоков потеряются на шине USB то сколько бы я не выставлял предварительных запросов с ReadData, хоть 1000, - ничего не поможет.

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

В случае если в блок из 32 слов помещается целое количество кадров (если число каналов 1,2,4,8 или 16) то после любой потери данных переброса каналов не происходит, так как теряется всегда целое количество кадров.

   Я несколько лет назад писал программу для модуля E24 на COM порт. Там все было очень удобно. Вместе с отсчетом канала передавался и его номер. Это позволяло при любых потерях данных всегда знать какому каналу пренадлежат данные.

Сейчас установил такие параметры:

Число каналов в кадре - 3
частота АЦП - 20 килогерц
соответственно частота опроса канала около 6.6 кгц

Размер буфера 32*2043=65376 слов (кратно числу каналов -трем)

  Зпрос длтся больше 2 секунд.

  Вызов справки БОЛЬШЕ НЕ ВЫЗЫВАЕТ ПОТЕРЮ ДПННЫХ!!
УРА!!

  Вызвать потерю данных удалось запуском все той же программы "Карта владивостока". Она тормозит систему при загрузке секнд на 8 на данном компьютере.