Подбираю АЦП низкочастотное

[Pavel Krivozubov]

Требования 16 бит, 250 Кс/c (ну или чуть меньше), два канала.
И самое главное чтобы она как можно быстрее принимала и обрабатывала данные.
Допустим чтобы оцифровка одного фрейма была бы порядка 10 мс. В принципе подошла бы и звуковая карта, но как известно, у них с оцифровкой фреймов менее 100 мс начинается беда прямо, так что ЗК не подходит.
Общий алгоритм работы будет заключаться в следующем:
оцифровка, анализ, потом перестройка частоты генератора, установка частоты в линии, потом опять оцифровка, анализ, перестройка и т.д.
Т.е. суммарное время всего анализа будет складываться из маленьких кусочков времени на каждую итерацию.

вот подобрал эту карточку
http://sine.ni.com/nips/cds/view/p/lang/en/nid/203223
Но в NI сказали что у подобного типа устройств принцип работы несколько другой, там буфер накапливается и я могу единовременно только взять из него определённое количество отсчётов, но это будут отсчёты из непонятно какого момента времени. И для того, что бы осуществить вышесказанный алгоритм с помощью этой карточки необходимо начать измерение и остановить измерение каждый раз за каждый фрейм, а на это уйдет порядка 100 мс так же, что не подходит так как мне тогда проще использовать ЗК.
А мне же нужно чтобы была прямая аналогия – снял точки и ты точно знаешь, что это временные отсчёты того момента времени когда началось снятие данных.
.

А вопросы следующие:
1) Использовал ли кто-нибудь девайсы которые это позволяют?
2) Есть ли у NI такие технологии (мне тут советовали Flex RIO, но это не подходит (габариты, цена).
3) Можно ли все-таки с устройствами DAQ реализовать алгоритм, описанный выше?
Я знаю можно на некоторых картах использовать начало измерений по синхроимпульсу, но для начала хотелось бы понять – есть ли такие девайсы, которые без синхронизации могут это делать (по аналогии с ЗК).

[Andrew Lunev]

Получить фрейм в 10 мс не проблема на любой карточке, ставь просто выборку в 2500 точек и будет синхронизация сбора данных по получению нужного количества данных в буфере.
Тут все упирается во время обработки этой выборки чтобы обработка и перестройка частоты происходили за такое-же время боюсь без ПЛИС не обойтись, ну или в крайнем случае без RT, конечно же плата должна быть PCI/PXI, но ни как не USB.
Если время обработки фрейма не критично, то можно получить выборку в 2500 точек и затем ее обрабатывать, потом получить следующую порцию точек. Для того, чтобы не останавливать и не перезапускать задачу сбора данных есть метод управления сбором с помощью счетчиков в этой же плате. Сигнал со счетчика передается в качестве опорного генератора для задачи сбора данных. Называется сбор данных с перезапуском. В счетчике надо просто задать генерацию 2500 импульсов с частотой 250 кГц, данные соберутся, и сразу же передатутся через DMA в буфер, там они обработаются, а чтобы получить еще одну порцию данных надо снова запустить генерацию 2500 импульсов по событию. Так как задача DAQmx не перезапускается 100 мс на это не тратится. Данные будут всегда самые последние, но скорость всего цикла сбора данных будет определяться вычислительной мощностью всей системы.

[mzu2006]

Это какой-то низкочастотный АПЧ?

Andrew Lunev, а почему не проходит самое простое решение:
6210 в режиме Continuous Acquisition. Синхронизовать программу хоть и по user-event о заполненности буфера, хоть по прочтении определенного количества данных. Прочитали - обработали - поправили частоту дальше работаем.

(USB 6210 - USB 2.0; 10ms соответствуют 100KS/s*2~3.2Mbit/s <<480Mbit/s.)

Если не нужно гарантированное время реакции на изменение сигнала, если можно пропустить пару точек, которые не успел обработать ...
Где здесь засада?

Pavel Krivozubov, у меня есть под рукой 6210 - остатки от предыдущей автоматизации. Если закинешь прогу можно протестировать временные режимы. в неспешном порядке

[Andrew Lunev]

Andrew Lunev, а почему не проходит самое простое решение:
6210 в режиме Continuous Acquisition. Синхронизовать программу хоть и по user-event о заполненности буфера, хоть по прочтении определенного количества данных. Прочитали - обработали - поправили частоту дальше работаем.

Если не останавливать сбор данных, то в буфере окажутся данные до перестройки частоты, ведь пока идет обработка и перестройка частоты поступление новых значений в буфер не прекращается. Если их использовать в обработке, то результат получится неверным (в буфер запишется переходной процесс перестройки частоты, а не результат перестройки). Мы должны сначала закончить перестройку частоты, и только потом снять новую порцию данных для обработки. Поэтому нельзя использовать непрерывный сбор. К тому же, если обработка не успеет за 10 мс, то в буфере окажется больше 2500 точек, что приведет к росту и переполнению буфера, если выбирать каждый раз по 2500 точек. Или приведет к переменному числу точек для обработки, если выбирать каждый раз весь доступный буфер. Потом как-то программно придется удалять из фрейма неправильные данные.
Цитата Павла: "оцифровка, анализ, потом перестройка частоты генератора, установка частоты в линии, потом опять оцифровка, анализ, перестройка и т.д." Получается, что новая оцифровка должна начинаться только после завершения процесса перестройки частоты, а не идти параллельно этому процессу.

[mzu2006]

Andrew Lunev, Спасибо за ответ. И всё-таки...

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

К тому же, если обработка не успеет за 10 мс, то в буфере окажется больше 2500 точек

если можно пропустить пару точек, которые не успел обработать ...

да-да просто пропустить. 1 поток читает с DAQmx устройства, и передает данные второму потоку, только если тот готов. А не готов, так выбрасывает.
2 поток обрабатывает и выставляет частоту на генераторе, инструктируя первый поток выбрасывать все приходящие данные, пока не произойдет заранее заданная задержка
( возможно, придётся выбросить чуть больше, из-за сложности синхронизации). Конечно, гарантированного времени подстройки частоты мы, не добьемся без RT ...

Или я не вижу какого-то простого ограничения?

[Andrew Lunev]

Все правильно, можно и так и эдак. Делать аппаратную или программную синхронизацию это дело вкуса. :) Я просто считаю, что нет смысла нагружать процессор, если можно нагрузить плату. Да и зачем получать данные, которые надо выкидывать? К тому же, если не делать лишних манипуляций с данными: сбор, передача в буфер, обработка, отбрасывание лишних данных, то часть анализа и перестройки частоты будет выполняться быстрей. Я просто предложил всё управление сбором данных и получением нужного фрейма возложить на аппаратную часть платы, тем самым цикл сбора данных всего лишь ждет поступления нужного количества данных в буфер и тут же начинает их обработку. Это можно сделать останавливая задачу сбора данных на время обработки, но процесс перезапуска задачи достаточно долгий. Использование для тактирования счетчика снимает и эту проблему, а счетчики есть во всех универсальных платах сбора данных NI.

[grjgrj]

Мне кажется, Andrew Lunev, прав, лучше сделать аппаратно. Но я не уверен что получится уложится в 10 мс, все зависит от анализа и от того как происходит управление генератором. на RT или ПЛИС было бы конечно лучше, но жутко дорого.

[Pavel Krivozubov]

Андрей, Миша спасибо за развернутые ответы.

Но разве это не одно и то же? :

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

6210 в режиме Continuous Acquisition. Синхронизовать программу хоть и по user-event о заполненности буфера, хоть по прочтении определенного количества данных. Прочитали - обработали - поправили частоту дальше работаем.

В первом приближении вариант с программной синхронизацией более понятен, так как без платы я не знаю как организовать эти счетчики..

Pavel Krivozubov, у меня есть под рукой 6210 - остатки от предыдущей автоматизации. Если закинешь прогу можно протестировать временные режимы. в неспешном порядке

Миш, ну у меня программы нет пока, так как плату еще не купили.
Не мог бы ты посмотреть может она вообще за 10 мс что то делать или там дольше на итерацию уходит.
На самом деле в принципе и 30 мс устроило бы даже.
И кстати судя по описанию Continuous Acquisition - разве это не аналогия прибора работающего с ЗК?
Там тоже идет сбор данных и никакой синхронизации не требуется..

[mzu2006]

Но разве это не одно и то же?

почти, с учетом того что Andrew Lunev сказал выше.

Не мог бы ты посмотреть может она вообще за 10 мс что то делать или там дольше на итерацию уходит.

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

И кстати судя по описанию Continuous Acquisition - разве это не аналогия прибора работающего с ЗК?

полная

[Select]

Как насчет применения modbus COM/USB, существует достаточно много шлюзовых ADC интерфейсов.

[Andrew Lunev]

Как насчет применения modbus COM/USB, существует достаточно много шлюзовых ADC интерфейсов.

Применение Modbus RTU для решения именно данной задачи? Вы серьезно?! Попробуйте сами разобраться в особенностях протокола Modbus RTU на RS-485 и ответить себе, почему данную задачу никак не решить на подобном оборудовании. Очень интересно услышать ваши идеи в защиту вашего решения и почему вы решили, что это вообще возможно.

[Kosist]

Select, 7 лет теме - как Вы ее нашли?
Я хоть и не электронщик, но поддерживаю Andrew Lunev - может, я и не прав, но кажись модбас 250 kS/s не вытащит...

[Select]

Kosist,
Пожалуй 250 kS/s не потянет.

[Andrew Lunev]

250 кГц точно ни один RS не потянет, но даже если бы потянул, то Modbus протокол не реального времени и позволяет получить только текущее значение регистра. В задаче требуется получить Waveform, для дальнейшего частотного анализа. То есть нельзя пропустить ни одного измерения и все измерения должны быть получены с одинаковым dt, иначе анализ не выполнить. Modbus работает только по запросам. Получается, что программа должна посылать 250 000 запросов в секунду с очень точным dt, затем получать результат и сохранять его. Если чуть опоздаете с запросом, то пропустите измерение, если чуть раньше запросите, то получите два раза одно измерение. А когда это измерение обновляется в регистре вы понятия не имеете. Я не встречал приборов Modbus, которые сохраняли в себе метку времени обновления регистра, так что вы даже не узнаете получили верные данные или нет. То есть даже для частоты опроса около 10 Гц нормально получить по Modbus данные типа Waveform не получится. Да и для более низких частот это не гарантируется протоколом.
Modbus прекрасно работает там, где надо собрать много данных с периодом опроса около 1 секунды и получить только текущие значения и применяется во многих проектах, но точно не для данной задачи.
Наверное можно спроектировать прибор с каким-то кольцевым буфером и меткой времени и обновлением данных в буфере только после вычитывания их Master-устройством, но для текущего уровня техники такое использование Modbus мне кажется большим извращением, уже существуют более подходящие протоколы обмена. Возможно лет 30 назад и были подобные устройства, но в новых системах использовать Modbus на RS мне кажется уже очень устаревшим решением. Лучше строить системы хотя бы на Modbus TCP, но опять же только не для систем реального времени.
По моему мнению Modbus RTU сейчас используется только потому что есть поддержка его во всех SCADA и есть множество систем, которые работают и требуют иногда частичной модернизации. Добавить в такую систему модули Modbus намного проще, чем переделывать всю систему.

[Select]

Andrew Lunev,
Еще как применяется и не только в закромах, там где не строят самолеты и медицинские приборы.
К примеру TCP в сетях контроля температуры и CO2, контроль качества на производствах, измерительных калибраторах, это далеко не полный список с которым я непосредственно сталкиваюсь и по сей день...
Та задача, которую здесь курят, действительно в modbus(ах) не прокатит, не те скоростя.