cDAQ Проблема с аналоговым выходом

Простейшие вопросы в области инженерной разработки
Аватара пользователя
jane_wild
professional
professional
Сообщения: 356
Зарегистрирован: 30 июн 2016, 02:11
Версия LabVIEW: 2020
Благодарил (а): 51 раз
Поблагодарили: 4 раза
Контактная информация:

Re: cDAQ Проблема с аналоговым выходом

Сообщение jane_wild »

Снова возвращаюсь к данной проблеме, я имею ввиду большую задержку между установкой новых параметров генерируемого сигнала и физическом появлении его на выходе. Наткнулась на информацию, что если свойство Data Transfer Request Condition установить в Onboard Memory Empty, то измененный сигнал должен появлятся немедленно, уже обрадовалась, но в реальности разницы не заметила. Почему так? Работаю над проектом, где минимальная задержка является необходимым условием.
Скриншоты ниже это скомпилированное приложение, физический cDAQ с модулем NI9263 и четыре сигнала. Индикатор разницы между текущей позицией и количеством сгенерированных точек "скачет" возле указанной цифры (761844)
Diff.PNG
Diff.PNG (3.19 КБ) 273 просмотра
Graph.PNG
При sample rate 100kHz (количество генерируемых точек 8192) сигнал появляется на выходе через 7-8 секунд после изменения. Как указывал Borjomy_1 эту задержку можно уменьшить, если прекращать записывать в буфер при достижении какого то лимита, что я и сделала в предыдущем проекте, добившись задержки в пол секунды.
Но это много, для текущего. При попытке уменьшения лимита, начинает возникать Error -200018. DAC conversion attempted before data to be converted was available.
Откуда (как рассчитывается) берется такой огромный буфер в 761844 точки и как его можно уменьшить? Посоветуйте каким образом можно решить поставленную задачу, которая сводится к следующему. Цикл в котором генерируется сигнал 100mS, задержка между записью и появлением на физическом выходе не более 200mS.
Artem.spb

Activity Автор
doctor
doctor
Сообщения: 2899
Зарегистрирован: 31 июл 2011, 23:05
Награды: 2
Версия LabVIEW: 12-18
Благодарил (а): 27 раз
Поблагодарили: 117 раз
Контактная информация:

Re: cDAQ Проблема с аналоговым выходом

Сообщение Artem.spb »

Буфер странный, в вашем случае почти 8сек. Вы его точно настраиваете?
А про время, равное 0,09с. Вы уверены, что это не то время, что нужно вашей программе чтобы осуществить все операции? Если у вас период 100мс, то вполне себе один такт.
Примерно так:
- система сделала всё и ждёт 100мс, допустим, на это ушло 20мс. Значит, 80 мс она ничего не делает.
- самом начале этого ожидания что-то меняется.
- новый такт - надо всё переделать, на это уходит 20 мс. Как бы 20, но с учётом простоя <=80 мс, получаются все 100
Аватара пользователя
jane_wild
professional
professional
Сообщения: 356
Зарегистрирован: 30 июн 2016, 02:11
Версия LabVIEW: 2020
Благодарил (а): 51 раз
Поблагодарили: 4 раза
Контактная информация:

Re: cDAQ Проблема с аналоговым выходом

Сообщение jane_wild »

Вот и я о том же, только эта скорее очередь, а не буффер. Выходной буффер, согласно ссылке которую Вы приводили ранее How Is Buffer Size Determined?
Output Tasks
For generations, the amount of data you write before starting a generation determines the size of the buffer. The first call to a Multiple Samples version of the Write function/VI creates a buffer and determines its size.

И в моем случае он равен 8192 по количеству точек необходимых для записи. И это не смотря на то, что я записываю 4 канала. По логике должно быть 8192*4..
При чтении AI сигнала все понятно - при частоте дискритизации в 10000Hz, 1000 точек будет читаться 100mS. Это правило не работает при записи! DAQmx Write.vi записывает куда то, пусть будет буффер, практически мгновенно, без всяких задержек, а драйвер уже выдает на выход согласно параметрам частота/количество точек. Вот и получается что while loop очень быстро заполняет этот буфер, до непонятно как вычисленного значения (7ххххх) более семисот тысяч, а затем начинает работать как и положено с задержкой 8192 / 100000Hz = 82 mS.
Только сигнал, после изменения, на выходе появляется через 761844 / 100000Hz = 7.6 секунды.
Вот чтобы он появился раньше Borjomy_1 предложил:
Решается эта задача контролем количества сгенерированных ЦАПом значений. И добавлением в буфер только когда остаток в нем будет меньше какого-то порога. Это и будет являться временем реакции на изменение сигнала
Именно по этому DAQmx Write.vi находится в Case structure и добавляет точки, если количество оставшихся для записи точек меньше установленного порога. Поэтому время цикла в основном определяется задержкой в Case = True (количество точек превышает лимит) Я поставила 80 mS.
Ну вот почти сама себя убедила, что имено так это все и работает :) Осталось понять откуда, как и почему такой большой по размеру буфер и возможно ли его уменьшить...

P.S. Кстати при симуляции такое поведение не наблюдается, работает как и полагается и разница между Current write position и Total Samples Per Chanel Generated "скачет" около 8192 и нет никаких "более семиста тысяч" и естественно Case = True никогда не случается...
Artem.spb

Activity Автор
doctor
doctor
Сообщения: 2899
Зарегистрирован: 31 июл 2011, 23:05
Награды: 2
Версия LabVIEW: 12-18
Благодарил (а): 27 раз
Поблагодарили: 117 раз
Контактная информация:

Re: cDAQ Проблема с аналоговым выходом

Сообщение Artem.spb »

В написанном ничего подозрительного не нашёл, всё так и должно быть.
Единственное, что я бы предложил всё же руками задать буфер при создании задачи.
Ну и можно ради интереса вывести на график два параметра, что у вас на скрине, посмотреть, как они меняются.
jane_wild писал(а): 21 июн 2022, 22:18 P.S. Кстати при симуляции такое поведение не наблюдается, работает как и полагается и разница между Current write position и Total Samples Per Chanel Generated "скачет" около 8192 и нет никаких "более семиста тысяч" и естественно Case = True никогда не случается...
Что-то подобное было у меня несколько лет назад с qDAQ. Буфер рос без всяких ограничений, пришлось руками контролировать сгенерированное. Но вот я как-то успешно решил эту задачу, так что метод рабочий и надо смотреть, где у вас может быть ошибка. Самое популярное у меня - перепутать местами T/F, тогда буфер будет разрастаться
Аватара пользователя
taras_33

Activity
professional
professional
Сообщения: 367
Зарегистрирован: 31 окт 2009, 18:25
Награды: 1
Версия LabVIEW: 2019
Поблагодарили: 9 раз
Контактная информация:

Re: cDAQ Проблема с аналоговым выходом

Сообщение taras_33 »

jane_wild писал(а): 21 июн 2022, 15:41 Цикл в котором генерируется сигнал 100mS, задержка между записью и появлением на физическом выходе не более 200mS.
Любопытные параметры. Неужто сигнал требует изменения десять раз в секунду? Или пытаетесть соорудить генератор сигналов произвольной формы?
Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots.
So far, the Universe is winning!
Аватара пользователя
jane_wild
professional
professional
Сообщения: 356
Зарегистрирован: 30 июн 2016, 02:11
Версия LabVIEW: 2020
Благодарил (а): 51 раз
Поблагодарили: 4 раза
Контактная информация:

Re: cDAQ Проблема с аналоговым выходом

Сообщение jane_wild »

taras_33 писал(а): 22 июн 2022, 12:23 Любопытные параметры. Неужто сигнал требует изменения десять раз в секунду? Или пытаетесть соорудить генератор сигналов произвольной формы?
Дело в том, что в цикле записи происходит измерение фазы. Например мне необходимо подать синусоидальный сигнал на устройство, причем начиная от нуля нужно сделать 1/4 периода, т.е. остановить генерацию в самой верхней точке, когда фаза стала больше 90. Либо 3/4 периода и остановить в нижней, когда фаза стала больше 270. Частота небольшая 0.1 - 0.5Hz, но все равно хоть чуточку, но самый пик "пролетает". Именно поэтому, чем короче сгенерированные кусочки синусоиды и чаще проверка фазы, тем точнее.
Сигнал приводит в дейсвие механизм, положение которого подается на аналоговый вход. Выводя на XY Graph два сигнала сгенерированный и измеренный получаю петлю гистерезиса. Поэтому важна минимальная задержка между записанным в cDAQ и физическим выходом. Понимаю, что правильно было бы задействовать еще один вход и подать на него сигнал с физического выхода. Но в моем конкретном случае это делать нельзя по другим причинам.
Аватара пользователя
jane_wild
professional
professional
Сообщения: 356
Зарегистрирован: 30 июн 2016, 02:11
Версия LabVIEW: 2020
Благодарил (а): 51 раз
Поблагодарили: 4 раза
Контактная информация:

Re: cDAQ Проблема с аналоговым выходом

Сообщение jane_wild »

Artem.spb писал(а): 22 июн 2022, 00:31 Ну и можно ради интереса вывести на график два параметра, что у вас на скрине, посмотреть, как они меняются.
Так и сделала, убрала Case structure, позволив DAQmx Write.vi записывать каждую интерацию.
BD.PNG
BD.PNG (7.76 КБ) 189 просмотров
Вот это симуляция
Simulation.PNG
А вот это реальный cDAQ с модулем NI9263
1.PNG
По прошедсвии некоторого времени линии становятся паралельными и сдвиг между ними колеблется от 760000 до 763000.
2.PNG
Я так поняла, что это особенности драйвера и бороться с этим на "верхнем" уровне большого успеха не принесет.
Аватара пользователя
Andrew Lunev

Activity Professionalism
leader
leader
Сообщения: 921
Зарегистрирован: 11 дек 2010, 12:31
Награды: 2
Версия LabVIEW: 2014-2020
Откуда: Москва
Благодарил (а): 3 раза
Поблагодарили: 5 раз

Re: cDAQ Проблема с аналоговым выходом

Сообщение Andrew Lunev »

Для подобных задач конечно надо использовать cRIO. Там на FPGA можно сделать что угодно с сигналами и фазами и ловить любую точку хоть на частоте семплирования 1 МГц.
DAQmx всё таки для таких задач очень плохо подходит. Сделаете буфер большим, будут большие задержки при смене сигнала. Сделаете буфер маленьким, рано или поздно попадете на опустошение буфера.
Так еще и очень странное поведение реального устройства, судя по вашим графикам. А всего то надо переставить модуль NI-9263 из cDAQ в cRIO. Конечно, если cRIO есть в наличии...
Аватара пользователя
jane_wild
professional
professional
Сообщения: 356
Зарегистрирован: 30 июн 2016, 02:11
Версия LabVIEW: 2020
Благодарил (а): 51 раз
Поблагодарили: 4 раза
Контактная информация:

Re: cDAQ Проблема с аналоговым выходом

Сообщение jane_wild »

Andrew Lunev писал(а): 22 июн 2022, 20:52 Сделаете буфер большим, будут большие задержки при смене сигнала. Сделаете буфер маленьким, рано или поздно попадете на опустошение буфера.
Так оно и есть, как только пытаешься перетянуть окошко, уцепившись за его заголовок, сразу же ошибка 200018. Хотя это окошко диалоговое, запускается в другом потоке и отношения к аналоговой части не имеет... Видимо перетаскивание занимает достаточно много ресурсов PC. По поводу cRIO, буду пытаться убедить начальство о покупке...

P.S. Как можно отследить, что юзер тапнул на заголовке окна? В event структуре есть только событие Pane Mouse Down и оно не срабатывает, если кликнуть на заголовке... :shok:
Ответить

Вернуться в «Для чайников»