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

Здравствуйте,
Простите пожалуйста, что дублирую вопрос, и выношу его в отдельную тему.

Возникла ошибка работы программы Oscillograph.vi с модулем E14-140M.
Первый запуск – все нормально данные считываются (Начинается синхронный ввод). Нажимаем кнопку “STOP”, останавливается сбор данных, появляется кнопка “RUN”. Нажимаем “RUN” – сбор данных не возобновляется, программа виснет.
Т.е. после остановки синхронного ввода к модулю можно обратиться только выполнив «LVCloseModule.vi» и дальше через новое подключение.
В программу изменений я не вносил.
Проверил: версия прошивки модуля и драйвера соответствуют последней версии.
Вроде на форуме была похожая тема 2014 года, с ходу не нашел, но я так и не понял, чем там все тогда кончилось.

При нажатии “RUN” пишет “Can’t read ADC data” и при повторном запуске программы зависает.
С модулем E502 и его примерами на LabView проблем нет, запускаешь сбор, останавливаешь, и снова вновь запускаешь.

Как я понял, грубо говоря, программа заключается в следующем:
1. LV_OpenModule.vi – открываем библиотеку
2. LV_CreateChannel.vi -
3. LV_E140_SetAdcSyncReadParame.vi – выставляем конфигурацию
4. LV_StartRealTimeAdcSampling.vi – запуск сбора данных
Цикл
5. LV_GetAdcRealTimeData.vi – сбор данных, преобразование, вывод на график
6. По “STOP” - LV_StopRealTimeAdcSampling.vi – останавливаем сбор и ждем
7. По “Run” - LV_StartRealTimeAdcSampling.vi – запуск сбора данных, идем на шаг 5
8. По “Power” – цикл останавливается.
Конец цикла
8. LV_StopRealTimeAdcSampling.vi – останавливаем сбор
9. LV_CloseModule.vi – закрываем  библиотеку
10. Конец программы
Ошибка: при нажатии “STOP” и выполнения LV_StopRealTimeAdcSampling.vi невозможно выполнить ни конфигурацию (шаг3), ни запуск сбора данных (шаг 4 или 5). И дело тут не в паузе.
Можно только выполнить шаг 9 и начать все сначала.
Каким образом периодический останавливать и возобновлять сбор?
Пожалуйста, помогите решить эту проблему.

Да, и еще вопрос, где найти пример сортировки массива по каналам, получаемого LV_GetAdcRealTimeData.vi.
Когда выполнен LV_StartRealTimeAdcSampling.vi, запущен сбор данных. А при выполнении LV_GetAdcRealTimeData.vi данные в массиве каждый раз начинаются не с первого канала, а с произвольного.

Например, запущен сбор с 3-х каналов с частотой 40 кГц. При первом выполнении LV_GetAdcRealTimeData.vi, я получаю из буфера массив: c11, c12, c13, с21, с22, с23, и т.д. до конца буфера.
cij, где i – номер измерения, а j – номер канала.
При следующем заполнении буфера Я получаю массив вида: (начало значений со второго канала, а может с 1 или 3-го) c12, c13, с21, с22, с23, и т.д. до конца буфера.

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

По поводу зависания:
Какая у вас версия labview?

По поводу разделения массива по каналам:
Посмотрите, как сделано в примере осциллографа: с выхода LV_GetAdcRealTimeData.vi количество данных
всегда кратно количеству каналов, далее с помощью Decimate 1D Array производится поканальное разделение исходного массива данных.
Можно еще придумать вариант с использованием промежуточного  буфера.
Вообще, Labview имеет множество встроенных функций для работы с массивами. Подробней, например, тут: http://www.picad.com.ua/lessons/1_2009.pdf

Версия 12.
Меня интересует не столько зависание, сколько почему после остановки сбора, сбор не возобновляется.

Да, согласен, количество принятых данных всегда кратно количеству каналов. Но в полученном массиве данных всегда ли первый элемент соответствует первому каналу?

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

Спасибо. Изучу.

Простите, неточно сформулировал:

Количество принятых данных всегда кратно количеству каналов. Но в полученном из буфера массиве данных всегда ли первый элемент соответствует первому каналу? При первом запуске LV_StartRealTimeAdcSampling.vi, и последующем первом запуске LV_GetAdcRealTimeData.vi да - соответствует и сортировка не вызывает проблем. При последующих запусках LV_GetAdcRealTimeData.vi не всегда. После остановки сбора и повторном LV_GetAdcRealTimeData.vi и возобновлении с помощью LV_StartRealTimeAdcSampling.vi, первый элемент в массиве будет вновь соответствовать первому каналу.

Разбить по каналам я могу, нет проблем, но понять где первый, а где второй, в где третий, и т.д. не получается, т.к. сигнал на каналах в моей задаче меняется.
Есть "колхозный" вариант, подать на один из каналов фиксированное напряжение например с ЦАП2 и использовать его как опорный.  Но хотелось бы понять, разобраться, и сделать как следует.

Еще раз спасибо за ответы.

Уточните еще название ОС.
Библиотека lview.dll самая свежая?

Если есть возможность, попробуйте запустить пример осциллографа на более старой версии labview.
Я проверял работу примеров под labview 7.1, 8.5, 2011. 12-й версии сейчас нет под рукой.
В какой - то версии labview была ошибка выделения памяти при работе с массивами - может это ваш вариант.

Данные внутри библиотеки lview.dll между вызовами LV_GetAdcRealTimeData.vi буферизируются, поэтому
если они своевременно откачиваются(т.е переполнения буфера не происходит) порциями кратными количеству каналов,
то первый отсчет будет всегда соответствовать первому включенному каналу. Именно так и сделано в примере осциллографа.

WinXP SP3

Да, от 28.03.2019, размер 134603

Интересно.

Что значит своевременно? В случае двух каналов, как в примере как-то работает, а если больше.
Я запустил поток. Выполнил LV_GetAdcRealTimeData.vi, считал некоторое количество точек из буфера числом, кратным количеству каналов, т.е. в буфере что-то осталось.
Через 5 минут Выполнил LV_GetAdcRealTimeData.vi еще раз. В буфере, грубо, первая четверть точек соотв. предыдущему запросу, а им в конец дописаны новые точки, но начинаются они не с первого канал, а например с третьего. Перескок получается.

Попробовал в 11 на другом ПК, тоже самое "Can't read adc data".

Простите, а у Вас сейчас все работает для E14-140M, вы сейчас проверили или проверяли, но давно.

Действительно при частоте 100 кГц, Буфере равном 4194304 и пакете  4096 в LV_StartRealTimeAdcSampling.vi, соответственно, и при опросе нечетного числа каналов, например 5-ти, начинаются чудеса. При четном числе каналов, например 2, 4 или 6, чудес не наблюдается, массив отлично сортируется. Меня устраивает 4 или 6 каналов.
Поэтому, вопрос с разбиением массива по каналам, думаю, что снимается, Спасибо вам за ответы.

Остался вопрос с остановкой/запуском потока. Пожалуйста, если у Вас есть возможность, проверьте у себя работоспособность E14-140M, произведенной не старше 4 лет, в LabView.

Здесь следует заметить, что за всю историю производства E14-140-M не было каких-либо изменений в оборудовании и технологии производства этого модуля, чтобы имелось бы какое-то основание как-то различать E14-140-M в зависимости от года его производства. Исправные E14-140-M с идентичными прошивками, драйверами и ПО должны вести себя одинаково.

Хорошо. Простите, что усомнился.

Пожалуйста, найдите возможность проверить сейчас работоспособность Oscillograph.vi для E14-140M.
Я проверил на других ПК, правда в более новых версиях LV, - все тоже,  "Can't read adc data" после остановки и повторном запуске сбора.

Это значит, что не происходит переполнения буфера, размер которого задается
в ф-и LV_StartRealtimeAdcSampling.

При любом количестве каналов все должно работать.

Между вызовами LV_GetAdcRealTimeData сбор данных останавливается? Если нет, то за 5 минут буфер приема может вполне переполнится и произойти перескок. Если буфер не переполняется, никаких перескоков быть не должно.

Что-то вы не так делаете. При любом количестве каналов перескоков быть не должно.

По поводу выделения памяти внутри labview:

1. Why Does LabVIEW Crash When I Call My DLL?

http://digital.ni.com/public.nsf/allkb/ … 2F005AB672

2. Нюансы работы:

To help determine the cause of this error in your application, could you describe in general what your application is doing? Are you using any toolkits, hardware (DAQ, FPGA, cameras, etc.), external code (e.g. DLLs, ActiveX), etc? Is there a certain scenario when the crash is likely to happen? Are you having any memory usage issues, like an array getting bigger and bigger? It seems like it could be an memory issue since it runs fine for several days. You could use the Windows Task Manager to check out memory usage or the Windows Performance Monitor. The NI LabVIEW Desktop Execution Trace Toolkit is also available for tracking memory leaks and reference leaks. Or you could consider the file logging suggestion of the above post.

An Access Violation is a general Windows exception, so there can be a wide variety of root causes. There are other LabVIEW threads discussing some causes of this exception. This forum post is particularly helpful, as they list several scenarios and potential fixes:
upgrade to LabVIEW 2012 SP1. A couple threads said the upgrade fixed issues with the XY Graph that was causing this exception.
Initializing an array of known size and using Insert into Array instead of Build Array
Problems with call library function node and a fix
Having too many open references (hardware, file, etc)
There's another post about this error when using an FPGA.

As you can see there are a wide variety of causes, so more information about your application and the nature of the crash, including memory usage around the time of the crash, would be useful.
Taylor B.
National Instruments

3. Русскоязычные ресурсы по labview:

http://www.labviewportal.ru/viewtopic.p … ion#p64083

4. Ветка, где обсуждается проблема с нашей библиотекой:

http://www.labviewportal.ru/viewtopic.p … n&start=45

Решение: нужно было сделать Run in UI thread->Run in any thread.

Цитата:
All calls to LabVIEW-built shared libraries should specify Run in any thread. If you configure the Call Library Function Node using LabVIEW-built shared libraries and specify Run in UI thread, LabVIEW might hang and require you to restart.

На ваш e-mail указанный в профиле выслал для тестирования версию
lview.dll, в которой учтены некоторые особенности.

Большое вам спасибо.
Я проверил. Пример Oscillograph.vi работает и программа, которую я параллельно пишу под свою задачу, тоже работает. Сбор останавливается и возобновляется по команде. Думаю, что эта проблема решена.

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

Добрый день, столкнулся с такой же проблемой ошибки при повторном считывании данных из буфера  https://www.lcard.ru/forums/viewtopic.php?id=10264 на АЦП E14-440, кроме того у меня тоже наблюдается "перескакивание" канала. Не могли бы вы переслать мне новую версию lview.dll

Здравствуйте,
у меня аналогичная проблема
не могли бы Вы высылать мне новую версию lview.dll

Здравствуйте, у меня также возникла эта проблема, не могли бы вы прислать и мне рабочую версию .dll