128 фильтров

[Artem.spb]

Система собирает данные со 128 каналов.
Заказчик хочет их фильтровать.
И надо бы сделать по-человечески, с сохранением истории (без перезапуска фильтра перед каждым циклом).
Фильтры сами по себе клонируемые, но вот как сделать 128 копий "автоматом" я не придумал, только руками разделить массив на 128 элементов, каждый элемент (канал) отфильтровать, и собрать всё обратно.
Есть ли более человечный способ? В голове крутится вариант запустить 128 клонов, каждому по собственной очереди выделить. И туда по каналу отправлять, ну и обратно всё собирать. Но тоже так себе вариант, особенно в плане отладки.
Ну и вероятность промахнуться в одном из 128 проводов - элементарно.

filters.PNG (6.66 КБ) 1534 просмотра

[Kosist]

У вас массив кластеров - прогоните его через For Loop, и для For Loop установите For Loop Iteration Parallelism. Если потоков мало будет, то тогда можно несколько таких циклов сделать, и для каждого выделить свой массив данных (например, с 32 каналов).

[Artem.spb]

У вас массив кластеров - прогоните его через For Loop, и для For Loop установите For Loop Iteration Parallelism. Если потоков мало будет, то тогда можно несколько таких циклов сделать, и для каждого выделить свой массив данных (например, с 32 каналов).

Проверил, так не работает. Цикл всё же не запоминает, где какой экземпляр вызывался.

Придумал и реализовал промежуточное решение - клонируемый , в котором 8 параллельных фильтров. А на входе тот самый массив и стартовый индекс.
На тесте такое решение работает, с фильтрами ещё в деле не проверял.

[Artem.spb]

Дополнение. Что-то схема с клонами не работает

[Borjomy_1]

У каждого фильтра есть свои коэффициенты (статические и динамические) . Поэтому надо залезть внутрь фильтра и переделать его, модифицировав под N каналов, вместо одного. Сделайте копию VI и модифицируйте под свои нужды. Там все открыто. Только учтите, что для разных частотных параметров количество коэффициентов может отличаться. Особенно это касается фильтров с бесконечной импульсной характеристикой.

[toshas]

У вас массив кластеров - прогоните его через For Loop, и для For Loop установите For Loop Iteration Parallelism. Если потоков мало будет, то тогда можно несколько таких циклов сделать, и для каждого выделить свой массив данных (например, с 32 каналов).

Проверил, так не работает. Цикл всё же не запоминает, где какой экземпляр вызывался.

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

[Artem.spb]

У каждого фильтра есть свои коэффициенты (статические и динамические) . Поэтому надо залезть внутрь фильтра и переделать его, модифицировав под N каналов, вместо одного. Сделайте копию VI и модифицируйте под свои нужды. Там все открыто. Только учтите, что для разных частотных параметров количество коэффициентов может отличаться. Особенно это касается фильтров с бесконечной импульсной характеристикой.

Спасибо за наводку.
Посмотрел всяких эллиптических чебышевых. Всё сводится к IIR фильтру. А для него есть готовая многоканальная версия, буду её тестировать.
Хотя, не понятно, почему клонирование готовых функция даёт такой результат.

[Artem.spb]

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

Разбирать что? Проблема не в разборе, а в том что фильтр хранит своё предыдущее состояние, на основе которого считает дальше. И в цикле это уползает.

[Juri]

например так

[Juri]

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

[Artem.spb]

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

Не-не, плохой вариант. Вызов по ссылке - очень медленная процедура. По крайней мере по моим тестам несколько лет назад

[IvanLis]

"Дело было вечером, делать было нечего..."
Сделал на AF, при необходимости можно модифицировать под свои нужды, масштабировать, уйти от констант и т.д.

Filtered Actor.7z

lv2015

(153.79 КБ) 59 скачиваний

[taras_33]

Хороший и наглядный пример работы фильтра.
Только Stop UsEv не обязательно передавать в nested actor при их запуске, потому как при завершении работы, main посылает stop всем nested actors, которые запустил, а сгенерировать Stop Event и остановить While loop можно уже в Stop Core.vi .
Только нужно не забывать соединять выход Launch Nested Actor.vi иначе не работает. Посмотрите отличие Launch Filtered.vi от Вашего.

[IvanLis]

Только Stop UsEv не обязательно передавать в nested actor при их запуске, потому как при завершении работы, main посылает stop всем nested actors

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

Только нужно не забывать соединять выход Launch Nested Actor.vi иначе не работает.

Посмотрел, не понимаю....
1. у меня все работает
2. мы ссылку на "родителя" передаем, что бы актор-"потомок" знал кто его запустил, а для этого не обязательно гонять все в цикле.

Тут может быть влияет именно "стиль программирования", но это дело вкуса.
Я зачастую указатель на User Event через сдвиговый регистр гоняю по привычке (хотя на работу никак не влияет), раньше писали, что это позволяет избежать утечек памяти, но я никогда не замечал этого.

Но например с чем недавно столкнулся при использовании акторов, это что после длительной работы (более суток), "сборщик мусора" убивал UserEvent, созданный в методе Pre Launch Init, ссылка на который использовалась внутри Core. Долго искал причину, пока не дошел до того, что перенес создание Event внутрь Core. Я больше практик, но теоретики пояснили, что логику работы "сборщика мусора" толком никто не понимает, а он спустя сутки после закрытия функции (метода) может посчитать, что это "мусор" и подчистить его

[taras_33]

Версия первая - рабочая. Запускаем Launcher, открываются четыре окошка. Закрываем main и он автоматом закрывает три nested

Версия вторая - не рабочая. Убираем сдвиговой регистр, остальное в проекте ничего не меняем. Запускаем Launcher, открываются четыре окошка. Закрываем main и
три nested остаются висеть. Собственно я это имел ввиду.

2. мы ссылку на "родителя" передаем, что бы актор-"потомок" знал кто его запустил, а для этого не обязательно гонять все в цикле.

А вот здесь уже я не понял, в Вашем проекте вроде как main и Filtered скорее братья, один из которых старшой

Но например с чем недавно столкнулся при использовании акторов, это что после длительной работы (более суток), "сборщик мусора" убивал UserEvent, созданный в методе Pre Launch Init, ссылка на который использовалась внутри Core. Долго искал причину, пока не дошел до того, что перенес создание Event внутрь Core. Я больше практик, но теоретики пояснили, что логику работы "сборщика мусора" толком никто не понимает, а он спустя сутки после закрытия функции (метода) может посчитать, что это "мусор" и подчистить его

Интересная информация, не сталкивался нужно будет потестить. Я часто создаю Event-ы в Pre Launch Init а уничтожаю в Stop Core.