Наилучший способ передачи множества параметров в SubVI
Добавлено: 15 янв 2016, 23:02
Собственно, давно уже интересует наиболее оптимальный способ передать в подприбор кучу входных параметров. Знаю, что можно придумать массу вариантов. Но мне хотелось бы, чтобы это выглядело компактно на БД и в то же время позволяло загнать в SubVI стопицот параметров. До последнего использовал кластеры, но меня уже утомила их громоздкость в плане сборки/разборки:
Пробовал вообще не передавать в ВПП параметры, а внутри подприбора рекурсивно обойти панель основного VI и извлечь нужные контролы/индикаторы: При небольшом числе элементов на ЛП это работает в принципе нормально. Когда элементов уже много, перебор начинает занимать приличное время (доходило до сотен миллисекунд), что сказывается на общем времени работы алгоритма SubVI. Очевидно, что Property/Invoke Nodes задействуют UI поток, потому такой способ не подходит.
Из того, что на ум приходило:
- при инициализации создать кластер/массив во всеми элементами (ссылками) и в SubVI уже отправлять этот кластер;
- создать какое-то хранилище элементов типа уведомителя или DVR, к которому можно обращаться в каждом SubVI;
Но тут уже возникают задачи поиска нужного элемента в кластере/массиве (по первому подходу) или обновления хранилища (по второму подходу).
Не хотелось бы изобретать велосипед лишний раз. Вопрос, вроде как, лежит на поверхности.
В этом плане у текстовых языков программирования есть преимущество: в любой процедуре/функции можно обратиться к любому элементу формы как-то так: Form1.Edit1.Text
В этом маленьком примере сами индикаторы + Bundle занимают места больше раз в 10, чем сам SubVI. Когда в проекте очень много SubVI и контролов/индикаторов, диаграмма превращается в ад! А хотелось бы всё-таки достичь идеала - чтобы БД верхнего уровня помещалась на экран монитора.Пробовал вообще не передавать в ВПП параметры, а внутри подприбора рекурсивно обойти панель основного VI и извлечь нужные контролы/индикаторы: При небольшом числе элементов на ЛП это работает в принципе нормально. Когда элементов уже много, перебор начинает занимать приличное время (доходило до сотен миллисекунд), что сказывается на общем времени работы алгоритма SubVI. Очевидно, что Property/Invoke Nodes задействуют UI поток, потому такой способ не подходит.
Из того, что на ум приходило:
- при инициализации создать кластер/массив во всеми элементами (ссылками) и в SubVI уже отправлять этот кластер;
- создать какое-то хранилище элементов типа уведомителя или DVR, к которому можно обращаться в каждом SubVI;
Но тут уже возникают задачи поиска нужного элемента в кластере/массиве (по первому подходу) или обновления хранилища (по второму подходу).
Не хотелось бы изобретать велосипед лишний раз. Вопрос, вроде как, лежит на поверхности.
В этом плане у текстовых языков программирования есть преимущество: в любой процедуре/функции можно обратиться к любому элементу формы как-то так: Form1.Edit1.Text