Boris_K писал(а):Какие преимущества могут давать эти методы, почему их так много?
Эти методы дают дополнительный контроль над запускаемым
с рядом параметров. Обычно используются при динамическом вызове SubVI или при работе с реентерантными SubVI. Но, возможно, подойдут и в вашем случае, хотя на 100% не могу сказать. Подробные описания инструментов приведены в справке
.
Если кратко, то Run VI похож на обычный запуск SubVI с тем исключением, что FP не отображается при вызове, а входными параметрами служат значения панели, а не значения в проводах, заведённых на SubVI. Есть опция для того, чтобы "забыть" про запущенный SubVI и не ждать, когда он закончит своё выполнение. Перед тем, как использовать метод Run VI, нужно открыть ссылку на SubVI с помощью Open VI Reference.
Call By Reference и Start Asynchronous Call используются непосредственно для динамического вызова SubVI. Динамический вызов сокращает временные расходы и потребление памяти, т.к. SubVI загружается в память
только при вызове Open VI Reference. Инструмент Call By Reference вызывает любой SubVI, чья соединительная панель совпадает с типом панели, заданным явно при вызове Open VI Reference. То есть, в ран-тайме можно вызывать динамически ряд SubVI с одинаковыми соединительными панелями (последовательно или параллельно), меняя лишь путь к подприборам и передаваемые на вход параметры. С помощью Call By Reference можно разработать систему плагинов на SubVI, если стоит такая задача.
Start Asynchronous Call используется для асинхронного запуска SubVI, т.е.
не ждёт окончания работы SubVI. И этот инструмент прекрасно подходит для запуска множества реентерантных SubVI, которые должны выполняться параллельно (например, реализация многопоточности при сетевом обмене). Параметры для Start Asynchronous Call также задаются при получении ссылки с помощью Open VI Reference. Для реентерантных подприборов есть ряд опций, наиболее важными из них являются:
- Prepare for reentrant run (SubVI реентерантный и для каждого экземпляра требуется своё пространство данных);
- Enable simultaneous calls on reentrant VIs (SubVI реентерантный, для каждого экземпляра требуется своё пространство данных и клоны SubVI будут работать параллельно (например, в цикле));
- Prepare to call and forget (после вызова SubVI
не будет ждать окончания работы SubVI и "забудет" о нём);
- Prepare to call and collect (после вызова SubVI необходимо подождать окончания работы SubVI с помощью Wait On Asynchronous Call, чтобы получить выходные параметры).
Однако для вашего случая можно было бы ограничиться Call By Reference, т.к. Run VI не совсем подходит из-за способа передачи параметров в SubVI, а Start Asynchronous Call вообще не уместен, т.к. не нужна асинхронность выполнения. Хотя, тормоза при работе с панелью могут и не исчезнуть при таком запуске.
Boris_K писал(а):dadreamer писал(а):отключите панель SubVI
Как именно? (могу ошибаться)
Немного неверно выразился. Если вынесете цикл получения данных в отдельный подприбор, то панель итак не будет показываться (по умолчанию). А если оставите в Main VI, то можно попробовать убрать скроллбары, лишние кнопки, меню и т.п. в настройках внешнего вида
(VI Properties -> Window Appearance).
Boris_K писал(а):Остальные фреймы ивент-структуры - value change контролов
А вот если попробовать убрать эти фреймы Value Change или вынести их в отдельный цикл, тормоза останутся? Всё-таки работа с кнопками - это больше к UI относится. Недаром же галочка "Lock panel" ставится при создании таких фреймов. Я в последнее время делаю так: все события по контролам обрабатываются в отдельном цикле с Event структурой, а остальные циклы "узнают" об этих событиях через спец. очередь "команды", которая передаёт список команд на приборы, наподобие изменения уставок, включения/выключения узлов и т.д. Хотя и появляется больше проводов на БД, это гарантированно развязывает UI и циклы по работе с данными.
По вашей диаграмме... Вроде не вижу особых причин, почему работа с панелью могла бы влиять на этот цикл. Только я бы Wait On Notification заменил на Get Notifier Status - в таком случае мы получаем значения уведомителя мгновенно без прочих задержек. А задержку цикла вы устанавливаете через константу Event Structure, которая привязана к синим часам. Случаем, переполнения очереди событий нет? Проверить можно через Event Inspector Window (ПКМ на структуре). Ну, и работу с кнопками попробуйте убрать из этого цикла просто для проверки.
), а работать в принципе уже можно и с этим. Отпишусь, как попробую. Спасибо большое за советы! 
Вот примерно как Яков сделал: 
Так что дело в ОСи и в железе.