Разделение цикла опроса модулей и UI

Захват, обработка и генерирование сигнала
Sergey Puzanov
assistant
assistant
Сообщения: 113
Зарегистрирован: 05 ноя 2020, 08:26
Версия LabVIEW: 18, 20.0f1
Благодарил (а): 23 раза
Поблагодарили: 3 раза
Контактная информация:

Разделение цикла опроса модулей и UI

Сообщение Sergey Puzanov »

Добрый день. Имеется State Machine с несколькими параллельными циклами, два из которых - работа всех кнопок/редактора/интерфейса в целом, и второй для опроса модулей. Опрос необходимо проводить достаточно часто (не реже каждых 10мс). Но случайно было замечено, что при определённом действии с Front Panel (переключение вкладок таба, открытие вкладки с разным количеством индикаторов или кнопок, изменение размеров окна, работа с редактором и прочее) начинаются изменения, и цикл опроса может существенно затормозиться. Каким способом можно разделить опрос, может как-то вывести в отдельный VI, чтобы он не зависел от других действий программы, а из него передавать данные в основную. Если так можно, подскажите, как это реализуется, спасибо.
rushonda
developer
developer
Сообщения: 289
Зарегистрирован: 26 фев 2016, 06:31
Версия LabVIEW: 18-20
Благодарил (а): 6 раз
Поблагодарили: 7 раз
Контактная информация:

Re: Разделение цикла опроса модулей и UI

Сообщение rushonda »

Без примерного кода не понять...
Аватара пользователя
dadreamer

Activity Professionalism Автор
professor
professor
Сообщения: 3926
Зарегистрирован: 17 фев 2013, 16:33
Награды: 4
Версия LabVIEW: 2.5 — 2022
Благодарил (а): 11 раз
Поблагодарили: 126 раз
Контактная информация:

Re: Разделение цикла опроса модулей и UI

Сообщение dadreamer »

Наверно, в цикле опроса есть вызовы каких-то Property/Invoke Nodes? Их нужно убрать (переместить в цикл обработки UI) или заменить на аналоги (локалки, очереди, уведомители и т.п.). Если есть вызовы DLL, нужно перевести все CLFN в Any Thread (жёлтый цвет). Если всё сделать правильно, то параллельный цикл не будет тормозиться при взаимодействии с панелью.
Sergey Puzanov
assistant
assistant
Сообщения: 113
Зарегистрирован: 05 ноя 2020, 08:26
Версия LabVIEW: 18, 20.0f1
Благодарил (а): 23 раза
Поблагодарили: 3 раза
Контактная информация:

Re: Разделение цикла опроса модулей и UI

Сообщение Sergey Puzanov »

rushonda писал(а): 17 дек 2021, 10:33 Без примерного кода не понять...
Прикрепил часть кода, версия LV2018. Опрос в синем цикле "Цикл обработки событий измерений с модулей"
dadreamer писал(а): 17 дек 2021, 10:37 Наверно, в цикле опроса есть вызовы каких-то Property/Invoke Nodes? Их нужно убрать (переместить в цикл обработки UI) или заменить на аналоги (локалки, очереди, уведомители и т.п.). Если есть вызовы DLL, нужно перевести все CLFN в Any Thread (жёлтый цвет). Если всё сделать правильно, то параллельный цикл не будет тормозиться при взаимодействии с панелью.
Ничего не вызывается, и Any Thread тоже установлен (хотя UI Thread более жёлтый даже, я же не путаю?).
Вот примеры задержек:
1)Начальный экран в среднем 2-3мс.
изображение_2021-12-17_124050.png
2) На этой вкладке уже стабильно 3мс, хотя никаких обновлений даже тут не происходит.
изображение_2021-12-17_124249.png
При масштабировании случайные моменты времени может и до 100мс+ скакнуть
Вложения
main.vi
(1.01 МБ) 57 скачиваний
Аватара пользователя
dadreamer

Activity Professionalism Автор
professor
professor
Сообщения: 3926
Зарегистрирован: 17 фев 2013, 16:33
Награды: 4
Версия LabVIEW: 2.5 — 2022
Благодарил (а): 11 раз
Поблагодарили: 126 раз
Контактная информация:

Re: Разделение цикла опроса модулей и UI

Сообщение dadreamer »

Sergey Puzanov писал(а): 17 дек 2021, 12:44хотя UI Thread более жёлтый даже, я же не путаю?
Оранжевый
Оранжевый
UI Thread.jpg (13.1 КБ) 1788 просмотров
Жёлтый
Жёлтый
Any Thread.jpg (12.4 КБ) 1788 просмотров
Sergey Puzanov писал(а): 17 дек 2021, 12:44Ничего не вызывается
И тем не менее в каждом цикле один-два Property Node да имеются. Какой из циклов на БД - цикл опроса?
Sergey Puzanov
assistant
assistant
Сообщения: 113
Зарегистрирован: 05 ноя 2020, 08:26
Версия LabVIEW: 18, 20.0f1
Благодарил (а): 23 раза
Поблагодарили: 3 раза
Контактная информация:

Re: Разделение цикла опроса модулей и UI

Сообщение Sergey Puzanov »

dadreamer писал(а): 17 дек 2021, 15:28 И тем не менее в каждом цикле один-два Property Node да имеются. Какой из циклов на БД - цикл опроса?
Sergey Puzanov писал(а): 17 дек 2021, 12:44 Прикрепил часть кода, версия LV2018. Опрос в синем цикле "Цикл обработки событий измерений с модулей"
Artem.spb

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

Re: Разделение цикла опроса модулей и UI

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

Sergey Puzanov писал(а): 17 дек 2021, 12:44 Прикрепил часть кода, версия LV2018. Опрос в синем цикле "Цикл обработки событий измерений с модулей"
Вот это пугает.
001.png
И это тоже. У вас как бы цикл записи в файл, но он как бы работает с UI. Это как раз надо разделить, и все запросы на изменение состояний элементов интерфейса обрабатывать в одном цикле.
02.PNG
dadreamer писал(а): 17 дек 2021, 10:37 Наверно, в цикле опроса есть вызовы каких-то Property/Invoke Nodes?
Ничего не вызывается
Ну это как сказать. То, что в цикле напрямую нет элементов PN вовсе не говорит, что цикл отвязан от UI, Потому что сам цикл работает в потоке UI.
Что могу рекомендовать
1) все циклы, не связанные с UI полностью освободить от обращения к элементам интерфейса. Да придётся добавить пересылку информации между циклами, но раз скорость критична, придётся "усложнять"
2) все такие циклы оформить в виде :vi: и в настройках задать другие потоки исполнения.
03.png
Аватара пользователя
dadreamer

Activity Professionalism Автор
professor
professor
Сообщения: 3926
Зарегистрирован: 17 фев 2013, 16:33
Награды: 4
Версия LabVIEW: 2.5 — 2022
Благодарил (а): 11 раз
Поблагодарили: 126 раз
Контактная информация:

Re: Разделение цикла опроса модулей и UI

Сообщение dadreamer »

Ещё бы SubVI где-то взять, а то одни знаки вопроса...
Вложения
2021-12-17_17-44-15.jpg
Аватара пользователя
dadreamer

Activity Professionalism Автор
professor
professor
Сообщения: 3926
Зарегистрирован: 17 фев 2013, 16:33
Награды: 4
Версия LabVIEW: 2.5 — 2022
Благодарил (а): 11 раз
Поблагодарили: 126 раз
Контактная информация:

Re: Разделение цикла опроса модулей и UI

Сообщение dadreamer »

Забыл упомянуть ранее, есть вот такой простой тест от Андрея, я им иногда пользуюсь. Позволяет проверить, встанет ли цикл, если заблокировать UI-поток. Попробуйте проверить таким способом свои циклы.
Вложения
UI Test.vi
lv2018
(8.11 КБ) 56 скачиваний
Sergey Puzanov
assistant
assistant
Сообщения: 113
Зарегистрирован: 05 ноя 2020, 08:26
Версия LabVIEW: 18, 20.0f1
Благодарил (а): 23 раза
Поблагодарили: 3 раза
Контактная информация:

Re: Разделение цикла опроса модулей и UI

Сообщение Sergey Puzanov »

Спасибо, на новой рабочей неделе всё испытаю и отпишусь.
ujin1
adviser
adviser
Сообщения: 231
Зарегистрирован: 06 ноя 2020, 15:37
Версия LabVIEW: 19
Благодарил (а): 18 раз
Поблагодарили: 37 раз
Контактная информация:

Re: Разделение цикла опроса модулей и UI

Сообщение ujin1 »

Sergey Puzanov писал(а): 17 дек 2021, 08:26 Добрый день. Имеется State Machine с несколькими параллельными циклами, два из которых - работа всех кнопок/редактора/интерфейса в целом, и второй для опроса модулей. Опрос необходимо проводить достаточно часто (не реже каждых 10мс). Но случайно было замечено, что при определённом действии с Front Panel (переключение вкладок таба, открытие вкладки с разным количеством индикаторов или кнопок, изменение размеров окна, работа с редактором и прочее) начинаются изменения, и цикл опроса может существенно затормозиться. Каким способом можно разделить опрос, может как-то вывести в отдельный VI, чтобы он не зависел от других действий программы, а из него передавать данные в основную. Если так можно, подскажите, как это реализуется, спасибо.
Проводим простейший тест.
тест времени цикла.png
тест времени цикла диаграмма.png
Как видно нет ничего лишнего, только добавление данных в массив.
Далее начинаем интенсивно водить мышкой, двигать окно, двигать другое окно не относящееся к LABView совсем.
Во всех случаях есть задержки времени цикла. Чем слабее комп, чем меньше ядер тем лучше этот эффект проявляется. На Линукс та же картина.
Windows не система реального времени и тем более жесткого реального времени.
В Windows и Decktop версиях линукс никаким образом не возможно гарантировать выполнение цикла или реакцию на события в строго определенное время.
В программе LABView есть способ некоторого выделения приоритетов в настройках SubVi и в Timed Structures.
Timed Loop имеет более высокий приоритет над обычными While Loop (но не над Winows).
Можно выполнить следующие шаги по повышению детерминизма по времени выполнения.
1. Заменить компьютер на более мощный с большим количеством ядер, с большей памятью. NI это первым делом рекомендует
2. Применить Timed Loop (по одному на ядро)
3. Выделить критичные циклы в subvi с приоритетом above normal или time critical (Timed Loop не работают с таким приоритетом)
4. Заменить ОС на Windows POSReady2009, Windows7 Embedded, Windows IoT. Предназначена для теминалов, встроенных систем. С этим сейчас проблема. Ранее нам удалось купить по 10 лицензий POSReady2009, Windows7 Embedded - меньше не продавали. Сейчас продают только производителям терминалов и устройств.
5. Запустить программу в скомпилированном виде.
6. Разделить программу на 2 части и два устройства. Сбор информации и управление на ОС Windows POSReady2009, Windows7 Embedded, Windows IoT. Интерфейс на обычных ОС.
7. Сбор информации и управление выполнить на серверной версии линукс без графической подсистемы. программу на LABView скомпилировать в виде динамической библиотеки под Linux и запустить ее как службу с высоким приоритетом.
8. Сбор информации и управление на NILinuxRT интерфейс на обычных.
9. Сбор информации и управление перенести на CompactRIO.
Если не вдаваться в подробности приемлемый результат для цикла 100 мс я получил только в варианте службы для консольной линукс и NILinuxRT. Приемлемый - это отсутствие пропусков и максимальный джиттер не более 40% от времени цикла (иначе циклы будут перекрываться).
Насколько я понимаю Вы используете dll. Следовательно можете попробовать только первые 5 пунктов (кроме мероприятий по использованию dll).
Изображение
Artem.spb

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

Re: Разделение цикла опроса модулей и UI

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

ujin1 писал(а): 19 дек 2021, 15:02 Проводим простейший тест.
Интересный тест, но ваши результаты я не смог воспроизвести.
Несомненно, винда не RT система, но у меня дребезг гораздо меньше.
Сначала просто жду секунд 10. Потом активно двигаю окно программы. Потом активно двигаю окно другой программы. На всех участках графики одинаковые
4 цикла:
  • цикл в основном :vi:
  • цикл в subVI в том же потоке
  • цикл в subVI в потоке standart (т.е любой не UI)
  • цикл в subVI в nhtnmtv потоке с Timed loop
Сначала просто замена элемента в массиве
replace.PNG
Потом build (в разумных пределах, но без проверки размера). Всплески до 17 мс - это я диспетчер задач открыл. Да, 70% - перебор.
buildArray.PNG
Так выглядит программа:
LV.png
ujin1
adviser
adviser
Сообщения: 231
Зарегистрирован: 06 ноя 2020, 15:37
Версия LabVIEW: 19
Благодарил (а): 18 раз
Поблагодарили: 37 раз
Контактная информация:

Re: Разделение цикла опроса модулей и UI

Сообщение ujin1 »

Artem.spb писал(а): 19 дек 2021, 19:16 Интересный тест, но ваши результаты я не смог воспроизвести.
Несомненно, винда не RT система, но у меня дребезг гораздо меньше.
Пункт 1 из возможных действий - более мощный компьютер с большим количеством ядер и оперативной памяти.
И так же одна из рекомендаций по тестированию от NI - протестировать на более слабом железе. Так как часто компьютер разработчика более мощный, скорее даже как правило более мощный.
Первый тест был на слабом железе хотя и 2 ядерном.
Характеристики компьютера.png
Характеристики компьютера.png (9.63 КБ) 1597 просмотров
Тест на железе посильнее
тест времени цикла 2.png
Характеристики компьютера 2.png
Характеристики компьютера 2.png (10.94 КБ) 1597 просмотров
Гораздо лучше. Однако опять нет полной гарантии выполнение цикла. И обратите внимание на размер массива. В Timed Loop размер массива больше на слабом железе существенно а на более сильном на 5 единиц. Т.е. 5 значений точно потеряно.
Теперь тот же тест на NILinuxRT. Одноядерный процессор Intel Atom 1.4 ГГц. Оперативной памяти 4Гб
Характеристики компьютера 3.png
Запускаем из проекта некомпилированная версия. Так же двигаем окна. Подключаемся по ssh к компьютеру (контроллеру). Запускаем htop. При запуске htop производительность = 100% в нормальном режиме 6%
тест времени цикла 3.png
Но тем не менее ни одного цикла не потеряно. Джиттер в обоих циклах 1 (10%) но это младший значащий разряд. Для правильности нужно заменить таймер
High Resolution Relative Seconds для данного железа недоступен. Ставим Get Date/Time In Seconds
Джиттер для Timed Loop меньше и составляет 2,5*10-5 с или 0,25%
тест времени цикла 4.png
Изображение
Artem.spb

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

Re: Разделение цикла опроса модулей и UI

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

ujin1 писал(а): 20 дек 2021, 05:07 Пункт 1 из возможных действий - более мощный компьютер с большим количеством ядер и оперативной памяти.
Потому мне и интересно посмотреть результаты на вашей машине. Вы оба цикла в UI потоке гоняете. Что будет при работе с другими потоками?
ujin1
adviser
adviser
Сообщения: 231
Зарегистрирован: 06 ноя 2020, 15:37
Версия LabVIEW: 19
Благодарил (а): 18 раз
Поблагодарили: 37 раз
Контактная информация:

Re: Разделение цикла опроса модулей и UI

Сообщение ujin1 »

Artem.spb писал(а): 20 дек 2021, 09:01
ujin1 писал(а): 20 дек 2021, 05:07 Пункт 1 из возможных действий - более мощный компьютер с большим количеством ядер и оперативной памяти.
Потому мне и интересно посмотреть результаты на вашей машине. Вы оба цикла в UI потоке гоняете. Что будет при работе с другими потоками?
Сейчас прогнал на рабочей машине один цикл в обычном потоке, subvi в other1.
Запустил программу. Хаотично подвигал окном. Запустил google chrome, хаотично подвигал его окном. Запустил синхронизацию с облаком.
В итоге все действия могут повлиять на цикл в той или иной степени. И более сильно это проявляется когда процессор приближается к 70%.
В данном случае до 70% не дошло, но на слабой машине такое было.
Причем поток выполнения, приоритет не заметно чтобы учитывались ОС. В LABView очевидно поток и приоритет влияние имеет.
Вложения
Test with subvi.png
Test with subvi cpu load.png
Test with subvi results.png
Изображение
Ответить
  • Похожие темы
    Ответы
    Просмотры
    Последнее сообщение

Вернуться в «Обработка сигнала»