Разделение цикла опроса модулей и UI
-
- assistant
- Сообщения: 113
- Зарегистрирован: 05 ноя 2020, 08:26
- Версия LabVIEW: 18, 20.0f1
- Благодарил (а): 23 раза
- Поблагодарили: 3 раза
- Контактная информация:
Разделение цикла опроса модулей и UI
Добрый день. Имеется State Machine с несколькими параллельными циклами, два из которых - работа всех кнопок/редактора/интерфейса в целом, и второй для опроса модулей. Опрос необходимо проводить достаточно часто (не реже каждых 10мс). Но случайно было замечено, что при определённом действии с Front Panel (переключение вкладок таба, открытие вкладки с разным количеством индикаторов или кнопок, изменение размеров окна, работа с редактором и прочее) начинаются изменения, и цикл опроса может существенно затормозиться. Каким способом можно разделить опрос, может как-то вывести в отдельный VI, чтобы он не зависел от других действий программы, а из него передавать данные в основную. Если так можно, подскажите, как это реализуется, спасибо.
-
dadreamer
- professor
- Сообщения: 3926
- Зарегистрирован: 17 фев 2013, 16:33
- Награды: 4
- Версия LabVIEW: 2.5 — 2022
- Благодарил (а): 11 раз
- Поблагодарили: 126 раз
- Контактная информация:
Re: Разделение цикла опроса модулей и UI
Наверно, в цикле опроса есть вызовы каких-то Property/Invoke Nodes? Их нужно убрать (переместить в цикл обработки UI) или заменить на аналоги (локалки, очереди, уведомители и т.п.). Если есть вызовы DLL, нужно перевести все CLFN в Any Thread (жёлтый цвет). Если всё сделать правильно, то параллельный цикл не будет тормозиться при взаимодействии с панелью.
-
- assistant
- Сообщения: 113
- Зарегистрирован: 05 ноя 2020, 08:26
- Версия LabVIEW: 18, 20.0f1
- Благодарил (а): 23 раза
- Поблагодарили: 3 раза
- Контактная информация:
Re: Разделение цикла опроса модулей и UI
Прикрепил часть кода, версия LV2018. Опрос в синем цикле "Цикл обработки событий измерений с модулей"
Ничего не вызывается, и Any Thread тоже установлен (хотя UI Thread более жёлтый даже, я же не путаю?).dadreamer писал(а): ↑17 дек 2021, 10:37 Наверно, в цикле опроса есть вызовы каких-то Property/Invoke Nodes? Их нужно убрать (переместить в цикл обработки UI) или заменить на аналоги (локалки, очереди, уведомители и т.п.). Если есть вызовы DLL, нужно перевести все CLFN в Any Thread (жёлтый цвет). Если всё сделать правильно, то параллельный цикл не будет тормозиться при взаимодействии с панелью.
Вот примеры задержек:
1)Начальный экран в среднем 2-3мс. 2) На этой вкладке уже стабильно 3мс, хотя никаких обновлений даже тут не происходит. При масштабировании случайные моменты времени может и до 100мс+ скакнуть
- Вложения
-
- main.vi
- (1.01 МБ) 57 скачиваний
-
dadreamer
- professor
- Сообщения: 3926
- Зарегистрирован: 17 фев 2013, 16:33
- Награды: 4
- Версия LabVIEW: 2.5 — 2022
- Благодарил (а): 11 раз
- Поблагодарили: 126 раз
- Контактная информация:
Re: Разделение цикла опроса модулей и UI
И тем не менее в каждом цикле один-два Property Node да имеются. Какой из циклов на БД - цикл опроса?
-
- assistant
- Сообщения: 113
- Зарегистрирован: 05 ноя 2020, 08:26
- Версия LabVIEW: 18, 20.0f1
- Благодарил (а): 23 раза
- Поблагодарили: 3 раза
- Контактная информация:
Re: Разделение цикла опроса модулей и UI
Sergey Puzanov писал(а): ↑17 дек 2021, 12:44 Прикрепил часть кода, версия LV2018. Опрос в синем цикле "Цикл обработки событий измерений с модулей"
-
- professor
- Сообщения: 3394
- Зарегистрирован: 31 июл 2011, 23:05
- Награды: 2
- Версия LabVIEW: 12-18
- Благодарил (а): 49 раз
- Поблагодарили: 172 раза
- Контактная информация:
Re: Разделение цикла опроса модулей и UI
Вот это пугает. И это тоже. У вас как бы цикл записи в файл, но он как бы работает с UI. Это как раз надо разделить, и все запросы на изменение состояний элементов интерфейса обрабатывать в одном цикле.Sergey Puzanov писал(а): ↑17 дек 2021, 12:44 Прикрепил часть кода, версия LV2018. Опрос в синем цикле "Цикл обработки событий измерений с модулей"
Ну это как сказать. То, что в цикле напрямую нет элементов PN вовсе не говорит, что цикл отвязан от UI, Потому что сам цикл работает в потоке UI.
Что могу рекомендовать
1) все циклы, не связанные с UI полностью освободить от обращения к элементам интерфейса. Да придётся добавить пересылку информации между циклами, но раз скорость критична, придётся "усложнять"
2) все такие циклы оформить в виде и в настройках задать другие потоки исполнения.
-
dadreamer
- professor
- Сообщения: 3926
- Зарегистрирован: 17 фев 2013, 16:33
- Награды: 4
- Версия LabVIEW: 2.5 — 2022
- Благодарил (а): 11 раз
- Поблагодарили: 126 раз
- Контактная информация:
-
dadreamer
- professor
- Сообщения: 3926
- Зарегистрирован: 17 фев 2013, 16:33
- Награды: 4
- Версия LabVIEW: 2.5 — 2022
- Благодарил (а): 11 раз
- Поблагодарили: 126 раз
- Контактная информация:
Re: Разделение цикла опроса модулей и UI
Забыл упомянуть ранее, есть вот такой простой тест от Андрея, я им иногда пользуюсь. Позволяет проверить, встанет ли цикл, если заблокировать UI-поток. Попробуйте проверить таким способом свои циклы.
- Вложения
-
- UI Test.vi
- lv2018
- (8.11 КБ) 56 скачиваний
-
- assistant
- Сообщения: 113
- Зарегистрирован: 05 ноя 2020, 08:26
- Версия LabVIEW: 18, 20.0f1
- Благодарил (а): 23 раза
- Поблагодарили: 3 раза
- Контактная информация:
-
- adviser
- Сообщения: 231
- Зарегистрирован: 06 ноя 2020, 15:37
- Версия LabVIEW: 19
- Благодарил (а): 18 раз
- Поблагодарили: 37 раз
- Контактная информация:
Re: Разделение цикла опроса модулей и UI
Проводим простейший тест. Как видно нет ничего лишнего, только добавление данных в массив.Sergey Puzanov писал(а): ↑17 дек 2021, 08:26 Добрый день. Имеется State Machine с несколькими параллельными циклами, два из которых - работа всех кнопок/редактора/интерфейса в целом, и второй для опроса модулей. Опрос необходимо проводить достаточно часто (не реже каждых 10мс). Но случайно было замечено, что при определённом действии с Front Panel (переключение вкладок таба, открытие вкладки с разным количеством индикаторов или кнопок, изменение размеров окна, работа с редактором и прочее) начинаются изменения, и цикл опроса может существенно затормозиться. Каким способом можно разделить опрос, может как-то вывести в отдельный VI, чтобы он не зависел от других действий программы, а из него передавать данные в основную. Если так можно, подскажите, как это реализуется, спасибо.
Далее начинаем интенсивно водить мышкой, двигать окно, двигать другое окно не относящееся к 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).
-
- professor
- Сообщения: 3394
- Зарегистрирован: 31 июл 2011, 23:05
- Награды: 2
- Версия LabVIEW: 12-18
- Благодарил (а): 49 раз
- Поблагодарили: 172 раза
- Контактная информация:
Re: Разделение цикла опроса модулей и UI
Интересный тест, но ваши результаты я не смог воспроизвести.
Несомненно, винда не RT система, но у меня дребезг гораздо меньше.
Сначала просто жду секунд 10. Потом активно двигаю окно программы. Потом активно двигаю окно другой программы. На всех участках графики одинаковые
4 цикла:
- цикл в основном
- цикл в subVI в том же потоке
- цикл в subVI в потоке standart (т.е любой не UI)
- цикл в subVI в nhtnmtv потоке с Timed loop
-
- adviser
- Сообщения: 231
- Зарегистрирован: 06 ноя 2020, 15:37
- Версия LabVIEW: 19
- Благодарил (а): 18 раз
- Поблагодарили: 37 раз
- Контактная информация:
Re: Разделение цикла опроса модулей и UI
Пункт 1 из возможных действий - более мощный компьютер с большим количеством ядер и оперативной памяти.
И так же одна из рекомендаций по тестированию от NI - протестировать на более слабом железе. Так как часто компьютер разработчика более мощный, скорее даже как правило более мощный.
Первый тест был на слабом железе хотя и 2 ядерном. Тест на железе посильнее Гораздо лучше. Однако опять нет полной гарантии выполнение цикла. И обратите внимание на размер массива. В Timed Loop размер массива больше на слабом железе существенно а на более сильном на 5 единиц. Т.е. 5 значений точно потеряно.
Теперь тот же тест на NILinuxRT. Одноядерный процессор Intel Atom 1.4 ГГц. Оперативной памяти 4Гб Запускаем из проекта некомпилированная версия. Так же двигаем окна. Подключаемся по ssh к компьютеру (контроллеру). Запускаем htop. При запуске htop производительность = 100% в нормальном режиме 6% Но тем не менее ни одного цикла не потеряно. Джиттер в обоих циклах 1 (10%) но это младший значащий разряд. Для правильности нужно заменить таймер
High Resolution Relative Seconds для данного железа недоступен. Ставим Get Date/Time In Seconds
Джиттер для Timed Loop меньше и составляет 2,5*10-5 с или 0,25%
-
- professor
- Сообщения: 3394
- Зарегистрирован: 31 июл 2011, 23:05
- Награды: 2
- Версия LabVIEW: 12-18
- Благодарил (а): 49 раз
- Поблагодарили: 172 раза
- Контактная информация:
Re: Разделение цикла опроса модулей и UI
Потому мне и интересно посмотреть результаты на вашей машине. Вы оба цикла в UI потоке гоняете. Что будет при работе с другими потоками?
-
- adviser
- Сообщения: 231
- Зарегистрирован: 06 ноя 2020, 15:37
- Версия LabVIEW: 19
- Благодарил (а): 18 раз
- Поблагодарили: 37 раз
- Контактная информация:
Re: Разделение цикла опроса модулей и UI
Сейчас прогнал на рабочей машине один цикл в обычном потоке, subvi в other1.
Запустил программу. Хаотично подвигал окном. Запустил google chrome, хаотично подвигал его окном. Запустил синхронизацию с облаком.
В итоге все действия могут повлиять на цикл в той или иной степени. И более сильно это проявляется когда процессор приближается к 70%.
В данном случае до 70% не дошло, но на слабой машине такое было.
Причем поток выполнения, приоритет не заметно чтобы учитывались ОС. В LABView очевидно поток и приоритет влияние имеет.
-
- Похожие темы
- Ответы
- Просмотры
- Последнее сообщение