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 - один экран. Это далеко не панацея, да и экраны у всех разные

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

. Правда, не помню, в чём заключался сам принцип такого механизма.