XY Graph замедляет всю систему

[jane_wild]

Здравствуйте всем. Столкнулась с проблемой обновления XY Graph. Когда количество точек превышает 100000, начинается притормаживание, и чем больше точек, тем оно сильнее.
Samling rate 1000, нужно минимум 100 секунд. Итого получается 100000, но отображать нужно 2 плота - четыре массива по 100000 Как следствие после секунд 50-ти начинается притормаживание...
О структуре программы. Actor Framework. DAQ непрерывно шлет 2D DBL Array. На приемной стороне из этого массива выделяются необходимые четыре 1D массива и накапливаются в FGV с последующим отображением на XY
Т.е. прилетели четыре порции по 100 точек каждая, добавились в FGV к уже имеющимся и вывелись на график. Как только длина масива достигла 100000 в FGV убираются первые 100 точек.
Помимо XY Graph на панели еще с десяток других индикаторов, которые также вместе с графиком начинают скачкообразно обновлятся. Значения как графика, так и индикаторов обновляю используя Set Control Values by Index
Недавно на форуме проскакивала тема, где упоминалась эта функция - решила попробовать. Функция вызывается дважды, один раз для всех индикаторов, второй раз для графика.
Теперь что интересно. Когда начинает притормаживать, то притормаживает все! В том числе и DAQ Actor который шлет данные. Причем притормаживает именно само отображение (отрисовка). iteration индикатор в while loop DAQ (Actor core) наглядно это показывает - вначале обновляется 10 раз в секунду показывая каждую циферку, затем синхронно с графиком и всеми индикаторами начинает обновлятся скачкообразно, скажем раз в пол секунды. Но! считает верно, перепрыгивая через значения значит сообщения посылаются, да и ошибки чтения (переполнения) нет. Если свернуть график в трей (основную фронтальную панель) индикатор снова работает плавно. Из чего я сделала вывод, что виновата именно отрисовка. Копаю дальше, ставлю Case structure с кнопкой на функцию Set Control Values by Index, ну типа обновлять - не обновлять и обнаруживаю, что это не работает! Т.е. я график не обновляю а оно всеравно тормозит. Вообщем мои размышления как учучшить производительность зашли в тупик. Может чего посоветуете?

[IvanLis]

Вообщем мои размышления как учучшить производительность зашли в тупик. Может чего посоветуете?

Смысл отображать 100000 точек на контроле размером (допустим) 1000 точек?
Путей несколько, я бы начал с изучения: viewtopic.php?t=10867

[jane_wild]

Смысл простой. Нужно "поймать" реакцию изменения одного сигнала при воздействии другого. Например медленно увеличивается давление, в какой то момент срабатывает pressure limit switch давая команду на закрытие входного серво клапана. Вот нужно измерить различные зависимости и скорость закрытия от приложенного тока, и время реакции switch, и давление от угла и т.д. и т.п.
Это происходит достаточно быстро, поэтому и sample rate 1000. А вот диапазон времени, когда это все произойдет, достаточно продолжительный, поэтому и 100 секунд. XY удобен тем что потом, нажав на паузу, можно увеличить именно ту область, которую нужно, отбросив все остальное и измерить курсорами все что необходимо

P.S. за ссылку спасибо буду разбираться, только мне кажется что проблема с обновлением (отрисовкой)XY, замеры времени на обработку данных вполне себе удовлетворительные. И почему с Chart таких проблем не наблюдается? Впольне себе выводит четыре канала по 200 тыс точек каждый и "не заикается"

[Artem.spb]

это не работает! Т.е. я график не обновляю а оно всеравно тормозит.

Это и наводит на мысль, что проблема не в рисовании, а в способе накопления массива.
Я не замечал тормоза на таких выборках, 100к = довольно скромное количество.

[Borjomy_1]

Я бы сделал следующим образом: закольцованный буфер предварительно выделенного и неизменяемого размера в 100к, где заменяется на каждой итерации только одна точка, а следующая за ней очищается (Nan), а также указатель на конец буфера. Незаполненная часть буфера NaN . И надо в конце физического буфера иметь дубликат значения 0 элемента, чтобы линия не прерывалась.
Также и для Y массива. Тогда из работы будет убрано копирование объемных массивов.

XY Grafh безразлично, в каком направлении будут отрисовываться тренды

[alerm]

И почему с Chart таких проблем не наблюдается? Впольне себе выводит четыре канала по 200 тыс точек каждый и "не заикается"

Просто вопрос: а на XY Graph точки отрисовываются?

[jane_wild]

это не работает! Т.е. я график не обновляю а оно всеравно тормозит.

Это и наводит на мысль, что проблема не в рисовании, а в способе накопления массива.
Я не замечал тормоза на таких выборках, 100к = довольно скромное количество.

Логически я согласна, но практика говорит что нет. Я наблюдаю выход кластера из FGV (тот который непосредственно подается на Set Control Value by Index) и который дергается синхронно с XY, причем без разницы добавляются новые данные в график или нет. Но стоит свернуть график, как все начинает работать плавно, обновляясь 10 раз в секунду, как и предполагалось. Может функция Set Control Value by Index как то не правильно работает, но переделывать весь проект, чтобы это проверить, особенного желания нет. Вообщем буду думать.

Просто вопрос: а на XY Graph точки отрисовываются?

Отрисовываются, только кусками, а не плавно

[alerm]

Отрисовываются, только кусками, а не плавно

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

[IvanLis]

Логически я согласна, но практика говорит что нет.

А Performance and Memory что показывает, наверняка там по разным методам (SubVI) раскидано накопление и отрисовка (если нет, то разнести)?
Можно посмотреть, где именно "тормоз" идет...

[ujin1]

У меня на графике 4-5 значений секундных за 24 часа. Это 432000. Каждую секунду делается запрос к базе данных и добавляются новые значения, старые убираются. Кольцевой буфер. Этот буфер подключен к XY Graf. Т.е данных новых 5-10 значений. График работает 24/7 неделями. Таких TrendViewer обычно включено 2-3. Задержки с течением времени не наблюдаются.
Т.е сам XY Graf с течением времени ресурсов больше не потребляет.
Точки не включены.

[jane_wild]

Нашла бяку виновата функция Set Control Value by Index, вернее мои кривые руки и не правильное ее применение. Хотела ее попробовать, ведь help обещает бОльшую производительность, но в моем случае получилось почему то наоборот. Потратила пару часов и переделала проект. Теперь при инициализации программы вместо индексов контролов собрала в массив их references. Индикаторы обновляются по старинке в for loop. И все заработало без всяких тормозов. В оригинальном проекте функция вызывалась трижды в двух override vi, обновление цифровых, аналоговых индикаторов и собственно XY Graph... Видимо есть какие то тонкости ее использования в Actor Frameworks, пишу так, потому что пыталась повторить "тормоза" в обычном VI - Не получилось работает плавно. Я тут нагородила чтобы XY не казался "мертвым"

Размер самого VI большой из за константы с 100000 точек из реального проета, поэтоу катринка

[IvanLis]

Я стараюсь писать "быстрые" данные в индикаторах использую UserEvent.
В любом случае все индикаторы располагаются в TopLevel.vi (Core.vi) и на самом деле требующих быстрого обновления не так много.
Для каждого такого индикатора создаю отдельный UserEvent, а из методов уже пишу в него.
При этом нет необходимости дергать "Свойства" этого индикатора для обновления данных из метода, что позволяет не блокировать им UI поток.

Стараюсь, но не всегда получается

[jane_wild]

Если я правильно поняла, то упрощенно это должно выглядеть так.
Собрать в определенном порядке массив из созданных UE для индикаторов. Далее прилетел от DAQ 2D массив, где я точно знаю в какой последовательности расположены данные и этот порядок должен совпадать с порядком массива из UE. Произвести обработку данных (Filter - RMS - Mean) вообщем кому что нужно... Ну и с помощью for loop генерировать UE для каждого индикатора. Так?
Обновление по индексу мне понравилось тем, что таская саму панель, либо другие окна и это не влияет на обновление - индикаторы не "замерзают" . Согласно Вашему сообщению такой же положительный эффект будет и при использовании UE. Правильно?

[taras_33]

Ну и с помощью for loop генерировать UE для каждого индикатора.

Зачем же для каждого? Можно и одно. После обработки данных соберите обратно в массив - вот его и передавайте - генерируя событие , а в обработчике разбросайте этом масив по индикаторам.

[IvanLis]

Правильно?

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

Я собираю все UserEvent в отдельный кластер TypeDef, ну и стараюсь группировать хоть как-то все (кластер Ref на элементы панели, кластер Ref на SubPanel и т.д.), так проще поддерживать и модифицировать.
Вот например TopLevel Core (main) и часть его свойств, думаю принцип группировки элементов в свойствах понятен.
Панель имеет только индикатор времени и кнопка для вкл/выкл всплывающих подсказок.
Каждый квадратик пустой это SubPanel. При запуске main запускаются куча Акторов и встраивают свои панели в main.

Реально здесь 5 разных типов Акторов:
1. Connection - коммуникация и работа с ModBus.
2. Logger - отображение лога событий пользователю.
3. Sound - управление звуковыми событиями.
4. Object - восемь экземпляров.
5. Ping - восемь экземпляров.

Вот например FP Актора который работает с ModBus и встраивается в main (место его думаю понятно).

На нем отображаются "Состояние соединения" и "Значения на входе", остальное - управление.
При инициализации Актора создаем соответствующие события UserEvent.

В процессе работы, Актор читает данные с устройства и в случае их изменения (это тоже позволяет не дергать лишний раз GUI), отправляет в UserEvent.

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

В Actor Core все необходимые события регистрируются и обрабатываются. Тут обновляем значения индикатора отображающего состояния DI, остальное аналогично.

А при остановке Актора, все чистим естественно.

Получается, что я не обновляю значения индикаторов через их свойства, а делаю это напрямую, непосредственно в Core.
Не всегда так получается, например в этом же проекте приходится менять цвет индикатора Description в Акторах Object и Ping через свойства (а его значение через UserEvent), но цвет меняется значительно реже, чем обновляется значение. Да и по другому этого не сделать.

Кроме всего прочего, UserEvent имеет функцию Flush Event и при запаздывании GUI позволяет фильтровать события, например отбросить все предыдущие и отобразить только последние актуальные данные. Но для обработки таких событий, которые могут тормозить все остальное в Actor Core желательно создавать отдельный цикл обработки.
Вот например Object Core, что бы интерфейс не блокировался при вызове меню пользователя, обработка разных событий и меню, разнесены по разным параллельным циклам.

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