Наилучший способ передачи множества параметров в SubVI

Обсуждение, связанное с разработкой ПО верхнего уровня

Наилучший способ передачи множества параметров в SubVI

Postby dadreamer on 15 Jan 2016, 23:02

Собственно, давно уже интересует наиболее оптимальный способ передать в подприбор кучу входных параметров. Знаю, что можно придумать массу вариантов. Но мне хотелось бы, чтобы это выглядело компактно на БД и в то же время позволяло загнать в SubVI стопицот параметров. До последнего использовал кластеры, но меня уже утомила их громоздкость в плане сборки/разборки:
2016-01-16_0-32-41.jpg
2016-01-16_0-32-41.jpg (75.63 KiB) Viewed 7484 times

В этом маленьком примере сами индикаторы + Bundle занимают места больше раз в 10, чем сам SubVI. Когда в проекте очень много SubVI и контролов/индикаторов, диаграмма превращается в ад! А хотелось бы всё-таки достичь идеала - чтобы БД верхнего уровня помещалась на экран монитора.

Пробовал вообще не передавать в ВПП параметры, а внутри подприбора рекурсивно обойти панель основного VI и извлечь нужные контролы/индикаторы:
Snippet.png

При небольшом числе элементов на ЛП это работает в принципе нормально. Когда элементов уже много, перебор начинает занимать приличное время (доходило до сотен миллисекунд), что сказывается на общем времени работы алгоритма SubVI. Очевидно, что Property/Invoke Nodes задействуют UI поток, потому такой способ не подходит.

Из того, что на ум приходило:
- при инициализации создать кластер/массив во всеми элементами (ссылками) и в SubVI уже отправлять этот кластер;
- создать какое-то хранилище элементов типа уведомителя или DVR, к которому можно обращаться в каждом SubVI;

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

В этом плане у текстовых языков программирования есть преимущество: в любой процедуре/функции можно обратиться к любому элементу формы как-то так: Form1.Edit1.Text
User avatar
dadreamer
professor
professor
 
Posts: 3117
Joined: 17 Feb 2013, 16:33
Medals: 4
Activity (1) Professionalism (1) Автор (2)
LabVIEW Version: 2.5 — 2018
Karma: 789
I/O VIP vision internet

Re: Наилучший способ передачи множества параметров в SubVI

Postby IvanLis on 15 Jan 2016, 23:42

dadreamer wrote:Не хотелось бы изобретать велосипед лишний раз. Вопрос, вроде как, лежит на поверхности.


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

Правда тут нужно "отделить зерна от плевел".
Тема сформулирована:
Наилучший способ передачи множества параметров в SubVI

Но судя из рассуждений, вопрос больше касается работы с лицевой панелью:
В этом плане у текстовых языков программирования есть преимущество: в любой процедуре/функции можно обратиться к любому элементу формы как-то так: Form1.Edit1.Text


Что касается передачи "кучи" переменных в SubVI. Это аналог функции (процедуры) в текстовых языках программирования, раз уж о них заговорили. Я много всего перепробовал, но не встречал функций, которые бы принимали больше 10-15 параметров. Это парадигма структурного программирования.

Что касается обращения к лицевой панели VI более высокого уровня из SubVI, на мой взгляд это крайне неверно и противоречит парадигме функционального программирования, да и вообще понятию "функция" (по крайней мере, как я себе представляю):
- Повышение надёжности
- Модульное тестирование
- Оптимизация
- Параллелизм

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

---------------------
Конечно и в моей практике были большие программы, в которых приходилось гонять много данных, я поступал следующим образом. Создавал кластер (TypeDef), в него скидывал все "общие" переменные. Потом гнал этот кластер от функции к функции. В каждой функции выделялись необходимые переменные и считывались, а после перезаписывались на новые. Получается, что на входе и выходе всех функций один и тот же кластер, только значения изменяются.

А что касается подхода: одна VI - один экран. Это далеко не панацея, да и экраны у всех разные :wink: .
User avatar
IvanLis
professor
professor
 
Posts: 4626
Joined: 02 Dec 2009, 17:44
Location: СССР
Medals: 7
Activity (2) Professionalism (1) Tutorials (1) Gold (1) Man of the year 2012 (1)
Автор (1)
LabVIEW Version: 2010
Karma: 727
hardware VIP bloggers teachers

Re: Наилучший способ передачи множества параметров в SubVI

Postby Borjomy_1 on 16 Jan 2016, 01:23

Когда в проекте очень много SubVI и контролов/индикаторов, диаграмма превращается в ад!

Надо сокращать количество контролов и индикаторов...
Borjomy_1
expert
expert
 
Posts: 1822
Joined: 28 Jun 2012, 09:32
Location: город семи холмов
Medals: 3
Activity (1) Professionalism (1) Silver (1)
LabVIEW Version: 4-8.6,9-14
Karma: 319
VIP

Re: Наилучший способ передачи множества параметров в SubVI

Postby dadreamer on 16 Jan 2016, 15:22

IvanLis wrote:Но судя из рассуждений, вопрос больше касается работы с лицевой панелью:

Вопрос, скорее, на стыке двух областей. Просто способ чтения контролов/индикаторов напрямую с панели - это как один из вариантов получить недостающие параметры внутри SubVI. То есть, если бы эти параметры были введены в SubVI, то не было бы нужды читать панель.
IvanLis wrote:Я много всего перепробовал, но не встречал функций, которые бы принимали больше 10-15 параметров.

Ну, обычно, не требуется передавать в функцию более 15 параметров. Но возможность такая есть: например, в С функция sprintf может принять бесчисленное множество параметров:
Code: Select all
int sprintf ( char * str, const char * format, ... );

И, как я уже писал, в процедурах и функциях текстовых языков есть возможность чтения данных с формы, потому можно передать в функцию несколько основных параметров и не париться.
IvanLis wrote:Что касается обращения к лицевой панели VI более высокого уровня из SubVI, на мой взгляд это крайне неверно и противоречит парадигме функционального программирования, да и вообще понятию "функция" (по крайней мере, как я себе представляю):
- Повышение надёжности
- Модульное тестирование
- Оптимизация
- Параллелизм

Ну, я не думаю, что чтение панели из подпрограммы нарушает хоть один из этих пунктов. Я ничего не говорил о записи из SubVI, и не рассматриваю этот момент. Это примерно то же, что в основном VI записать параметры в файл, а в SubVI прочитать их из файла. Но я с этим не стал связываться, т.к. оказывается вовлечён фактор работы с файловой системой, что вносит лишнюю задержку времени выполнения кода. Да и, на самом деле, я также отказался и от чтения панели в SubVI, т.к. это тоже довольно инерционный подход. Потому, следует поискать иные варианты.
IvanLis wrote:Да и сложно себе представить лицевую панель программы, которая содержит несколько сотен различных элементов (контрол/индикатор), но это уже больше вопросы эргономики.

Несколько - вряд ли. Но сотня порой набирается. Обычно всё это дело разнесено по вкладкам Tab Control'а и не мешает друг другу. На ЛП всё компактно и органично, хотелось бы и на БД сделать так же.
Конечно и в моей практике были большие программы, в которых приходилось гонять много данных, я поступал следующим образом. Создавал кластер (TypeDef), в него скидывал все "общие" переменные. Потом гнал этот кластер от функции к функции. В каждой функции выделялись необходимые переменные и считывались, а после перезаписывались на новые. Получается, что на входе и выходе всех функций один и тот же кластер, только значения изменяются.

Вариант 1 из моего первого сообщения. В кластере были только контролы или так же и индикаторы? Положим, контролы при передаче в SubVI всегда имеют актуальное значение, потому можно хоть сам кластер завести, хоть его локальную переменную. А где обновлять индикаторы? После каждого вызова SubVI? Ещё такой момент: при группировке всех элементов в кластер на ЛП они оказываются заключены в рамку этого кластера. То есть, по вкладкам Tab Control'а уже не разнести. Не совсем удобно.
А что касается подхода: одна VI - один экран. Это далеко не панацея, да и экраны у всех разные :wink: .

Ну да, я сам так считаю, даже вёл дискуссии на эту тему. Кстати, интересный момент: если открыть древние VI (взять те же NI'шные инструменты из старых LV), то их диаграммы часто выглядят как небольшой квадрат с мешаниной из графики. Раньше мониторы были маленького размера, а программисты всё равно старались следовать тому, чтобы диаграмма помещалась на экран.
Но всё-таки хотелось бы компактности и простоты построения кода. Что до сих пор недолюбливаю в LabVIEW, так это лапшу из проводов, и кашу из контролов/индикаторов, VI и структур. Порой на приведение к красивому виду времени уходит больше, чем на кодинг. В этом плане, опять же, текстовый код проще сделать красивым.
Borjomy_1 wrote:Надо сокращать количество контролов и индикаторов...

Не всегда это получается. В релизе конечно индикаторов и контролов по минимуму. В отладочных версиях полно отладочных контролов/индикаторов, которые нужны для проверки разных алгоритмов и т.п. Кроме того, порой приходится переделывать чужие программы и тут уж никуда не деться. Удалить лишние контролы/индикаторы я не могу, потому что они уже нужны и описаны. Остаётся только загонять их все в подпрограмму.

Когда-то видел интересный подход с очередью из параметров. По-моему, там нужно было помещать параметры в очередь, удалять из неё и модифицировать отдельными :vi: . Правда, не помню, в чём заключался сам принцип такого механизма.
User avatar
dadreamer
professor
professor
 
Posts: 3117
Joined: 17 Feb 2013, 16:33
Medals: 4
Activity (1) Professionalism (1) Автор (2)
LabVIEW Version: 2.5 — 2018
Karma: 789
I/O VIP vision internet

Re: Наилучший способ передачи множества параметров в SubVI

Postby Artem.spb on 16 Jan 2016, 21:53

А чем собственно "первый" пример не устраивает? тем, что сбор в кластер занимает много места?
Я тоже пользуюсь методом, описанным Иваном: в начале собираю все необходимые параметры в кластер, а дальше гоняю этот кластер сквозь :vi: , даже если внутри нужны не все параметры. Это гораздо проще и элегантнее, чем собирать перед каждым subVI нужный ему кластер и отправлять внутрь только "полезную" информацию.
Artem.spb
expert
expert
 
Posts: 1397
Joined: 31 Jul 2011, 23:05
Medals: 2
Activity (1) Автор (1)
LabVIEW Version: 12,14,15
Karma: 239
CLD hardware I/O VIP freelance

Re: Наилучший способ передачи множества параметров в SubVI

Postby IvanLis on 17 Jan 2016, 00:14

dadreamer wrote:Вариант 1 из моего первого сообщения. В кластере были только контролы или так же и индикаторы? Положим, контролы при передаче в SubVI всегда имеют актуальное значение, потому можно хоть сам кластер завести, хоть его локальную переменную. А где обновлять индикаторы? После каждого вызова SubVI? Ещё такой момент: при группировке всех элементов в кластер на ЛП они оказываются заключены в рамку этого кластера. То есть, по вкладкам Tab Control'а уже не разнести. Не совсем удобно.

В принципе Artem.spb уже дал ответ.

В кластере не контролы/индикаторы (разницы в них практически нет, их значение всегда доступно через свойства), а именно значение. Я также в кластер часто закидываю пути к файлам, ссылки, параметры и свойства, короче все что нужно в процессе работы.

В процессе работы, при переходе от функции к функции, необходимые данные из кластера считываются, которые нужно - обновляем и т.д. и т.п.

Что касается их отображения, то делается это по событию или после окончания итерации, при этом из кластера вытаскиваются необходимые значения и закидываются в соответствующие индикаторы. При необходимости можно это делать после каждой функции, хотя смысла в этом не вижу.
Получается, что значения всех индикаторов обновляются разом, для ускорения можно заблокировать FP, что бы она перерисовывалась только после полного обновления.
User avatar
IvanLis
professor
professor
 
Posts: 4626
Joined: 02 Dec 2009, 17:44
Location: СССР
Medals: 7
Activity (2) Professionalism (1) Tutorials (1) Gold (1) Man of the year 2012 (1)
Автор (1)
LabVIEW Version: 2010
Karma: 727
hardware VIP bloggers teachers

Re: Наилучший способ передачи множества параметров в SubVI

Postby dadreamer on 17 Jan 2016, 13:37

В итоге останавливаюсь пока что на каком-то из этих решений:
1) кластер из ссылок на контролы и индикаторы;
2) кластер из значений контролов и индикаторов;
3) смесь 1 и 2.
Наверное, всё-таки 1 удобнее, чем 2 или 3. По ссылке всегда можно получить актуальное значение контрола/индикатора где угодно, и не только. Можно получить любые свойства этого элемента. И при необходимости обновить элемент. Для решения 2 нужно отдельно "синхронизировать" текущие значения индикаторов/контролов со значениями в кластере. Как до подачи в ВПП, так и после.

В общем, как буду делать новый проект, попробую. Также, может, посмотрю какие-то другие решения, если не устроят эти.
User avatar
dadreamer
professor
professor
 
Posts: 3117
Joined: 17 Feb 2013, 16:33
Medals: 4
Activity (1) Professionalism (1) Автор (2)
LabVIEW Version: 2.5 — 2018
Karma: 789
I/O VIP vision internet

Re: Наилучший способ передачи множества параметров в SubVI

Postby Artem.spb on 17 Jan 2016, 16:00

dadreamer wrote:В итоге останавливаюсь пока что на каком-то из этих решений:
1) кластер из ссылок на контролы и индикаторы;
2) кластер из значений контролов и индикаторов;
3) смесь 1 и 2.
.


я как раз использую 1+2, но это два разных кластера:
1) кластер ссылок для управления FP (заблокировать, переключить tab и т.п. в том числе можно и обновить значение)
2) кластер рабочих параметров, необходимых для расчётов, но не нежных пользователю (те самые пути к файлам)
Artem.spb
expert
expert
 
Posts: 1397
Joined: 31 Jul 2011, 23:05
Medals: 2
Activity (1) Автор (1)
LabVIEW Version: 12,14,15
Karma: 239
CLD hardware I/O VIP freelance

Re: Наилучший способ передачи множества параметров в SubVI

Postby ESeid on 19 Jan 2016, 11:07

dadreamer wrote:В итоге останавливаюсь пока что на каком-то из этих решений:
1) кластер из ссылок на контролы и индикаторы;
2) кластер из значений контролов и индикаторов;
3) смесь 1 и 2.
Наверное, всё-таки 1 удобнее, чем 2 или 3. По ссылке всегда можно получить актуальное значение контрола/индикатора где угодно, и не только. Можно получить любые свойства этого элемента. И при необходимости обновить элемент. Для решения 2 нужно отдельно "синхронизировать" текущие значения индикаторов/контролов со значениями в кластере. Как до подачи в ВПП, так и после.

В общем, как буду делать новый проект, попробую. Также, может, посмотрю какие-то другие решения, если не устроят эти.

Очень интересный подход. У меня в готовых инструментах до 30-40 индикаторов+контролов, я их группировал в кластеры, но вот до кластера ВСЕХ ссылок не додумался. Спасибо за идею, буду пробовать.
ESeid
assistant
assistant
 
Posts: 149
Joined: 30 Mar 2011, 22:41
Medals: 1
Автор (1)
LabVIEW Version: 8.2-2013
Karma: 34

Re: Наилучший способ передачи множества параметров в SubVI

Postby Pavel on 19 Jan 2016, 12:57

Кластер чем неудобен, так это тем что при передачи в субвиай делается его копия. В принципе для референсов это будет не критично, но если передавать весь кластер со всеми данными (допустим супер кластер) то при большом проекте копирование кластера будет отъедать место.
Pavel
developer
developer
 
Posts: 271
Joined: 31 Jul 2009, 08:07
Medals: 1
Activity (1)
LabVIEW Version: 8.5
Karma: 39
VIP

Re: Наилучший способ передачи множества параметров в SubVI

Postby Artem.spb on 19 Jan 2016, 22:54

Pavel wrote:Кластер чем неудобен, так это тем что при передачи в субвиай делается его копия. В принципе для референсов это будет не критично, но если передавать весь кластер со всеми данными (допустим супер кластер) то при большом проекте копирование кластера будет отъедать место.


ну это не совсем так, точнее, зависит от того, как передавать
mem.png

на верхней строке кластер передаётся в функцию, там обрабатывается и отправляется наружу. копии не создаются.
В нижней строке при отправке в каждую функцию создаётся копия.
Но идея в частности в том чтобы кластер передавался от функции к функции (и через сдвиговый регистр в цикле), чтобы в нём всегда была актуальная информация (например для скользящего среднего надо хранить некоторую историю). И в этом случае копий не создаётся.
Artem.spb
expert
expert
 
Posts: 1397
Joined: 31 Jul 2011, 23:05
Medals: 2
Activity (1) Автор (1)
LabVIEW Version: 12,14,15
Karma: 239
CLD hardware I/O VIP freelance

Re: Наилучший способ передачи множества параметров в SubVI

Postby Pavel on 20 Jan 2016, 09:08

Если речь идет о сабвиай, то при вызове делается копия всех параметров (так было до LV 2010, уже давно не пишу программы но думаю ничего не поменялось). В Labview есть/был инструмент Show Buffer Allocations, посмотрите им.
Pavel
developer
developer
 
Posts: 271
Joined: 31 Jul 2009, 08:07
Medals: 1
Activity (1)
LabVIEW Version: 8.5
Karma: 39
VIP

Re: Наилучший способ передачи множества параметров в SubVI

Postby Artem.spb on 20 Jan 2016, 10:17

Pavel wrote:Если речь идет о сабвиай, то при вызове делается копия всех параметров (так было до LV 2010, уже давно не пишу программы но думаю ничего не поменялось). В Labview есть/был инструмент Show Buffer Allocations, посмотрите им.


Не знаю, откуда ы Вас такая странная информация. Вы бы сами проверили, прежде чем путать людей.
Вот скрин моего текущего проекта. Чёрные точки - выделение памяти. И так было с тех пор, когда я первый раз проверил это дело. ещё в 8 или 2009
mem.png
Artem.spb
expert
expert
 
Posts: 1397
Joined: 31 Jul 2011, 23:05
Medals: 2
Activity (1) Автор (1)
LabVIEW Version: 12,14,15
Karma: 239
CLD hardware I/O VIP freelance

Re: Наилучший способ передачи множества параметров в SubVI

Postby Pavel on 20 Jan 2016, 13:15

У вас красным "овалом" обведено выделение памяти под кластера, то же самое происходит и в сабвиай. Т.е. при вызове подпрограммы LV выделит память и скопирует туда кластер.
Pavel
developer
developer
 
Posts: 271
Joined: 31 Jul 2009, 08:07
Medals: 1
Activity (1)
LabVIEW Version: 8.5
Karma: 39
VIP

Re: Наилучший способ передачи множества параметров в SubVI

Postby Artem.spb on 20 Jan 2016, 15:28

Pavel wrote:У вас красным "овалом" обведено выделение памяти под кластера, то же самое происходит и в сабвиай. Т.е. при вызове подпрограммы LV выделит память и скопирует туда кластер.

это утверждение даже звучит нелогично.
что же в таком случае происходит с оригинальными данными?
Artem.spb
expert
expert
 
Posts: 1397
Joined: 31 Jul 2011, 23:05
Medals: 2
Activity (1) Автор (1)
LabVIEW Version: 12,14,15
Karma: 239
CLD hardware I/O VIP freelance

Next

Return to Лицевая панель

Who is online

Users browsing this forum: No registered users and 3 guests

cron