Советы по программированию на LabVIEW

[rsv]

Узнал много нового - и про функцию Type Cast, и про библиотеку OpenG.
Всем спасибо.

[rsv]

Вопрос по использованию сетевых переменных
При запуске приложения на ПК считываю уставки из ini-файла в сетевую переменную типа кластер. После этого уставки уже не меняются.
В дальнейшем уставки нужны на контроллере (Real-Time) в цикле. При каждой итерации последовательно вызывается несколько модулей, в которых используются уставки из кластера.
В связи с этим вопрос:
Как эффективнее использовать уставки на контроллере (быстродействие актуально):
- из каждого модуля обращаться к сетевой переменной и через Unbundle вытаскивать нужные уставки;
- перед запуском цикла считать кластер в локальную переменную и передавать в каждый модуль в виде параметра;
Может есть ещё какие-то более быстродействующие решения?

[Artem.spb]

- из каждого модуля обращаться к сетевой переменной и через Unbundle вытаскивать нужные уставки;
- перед запуском цикла считать кластер в локальную переменную и передавать в каждый модуль в виде параметра;
Может есть ещё какие-то более быстродействующие решения?

хранить данные в проводах и извлекать из них по необходимости - самый быстрый и рекомендуемый способ

[Kosist]

Может есть ещё какие-то более быстродействующие решения?

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

[ujin1]

- перед запуском цикла считать кластер в локальную переменную и передавать в каждый модуль в виде параметра;

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

[ujin1]

...вытягивая лишь нужные параметры - создается сильная связка модулей, что не есть хорошо.

В JKI State machine при инициализации используют bundle (не bundle by name). Все параметры именованные. Нужные параметры далее unbundle by name.
Новый элемент добавляется в кластер не ломая ничего дальше. Связка при таком способе отсутствует.

[rsv]

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

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

Почему быстродействие актуально? Быстродействие по Вашему - это какие величины, как быстро это должно происходить?

1 итерация = 1 миллисекунда

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

Так и сделано - для каждого выходного сигнала используется свой кластер уставок. И к моменту запуска цикла они приходят разными извилистыми путями. Но для расчёта всё равно приходится несколько модулей использовать...

[Artem.spb]

1 итерация = 1 миллисекунда

Не слишком ли шустро? Может можно оптимизировать код и "склеить" несколько итераций в одну?

[nae]

Как можно заставить код labview15 работать быстрее?
Пишу обращение к FTDI драйверу. Нужно принимать 50 фреймов/секунду по 655360 байт каждый. В приборе кадрового буфера нет, драйвер FTDI сам рулит буфером и накапливает поток на компе. Но накопить может не более 65536 байт. Т.е. я могу читать максимум такими кусочками за одно обращение к READ.
В итоге разбиваю фрейм на равные кусочки (для удобства) и читаю очередной кусок, просматриваю функцией search его на предмет обнаружения комбинации начала кадра. Если не нашел, значит продолжаем вычитывать кусочки и складывать их в буфер (по указателю на буфер и функцию Subset). Если вдруг начало кадра обнаружено, то значит у нас сразу за индексом есть заголовок - отправляем 40 байт заголовка в дешифратор заголовков, дочитываем через READ из буфера FTDI до целого куска, сбрасываем счетчик, чтобы начать писать в буфер кадра с начала.
Всё как бы работает, но i3-2350M тратит время целого ядра чтобы просто прочитать поток 25фпс, а на 50 фпс ядра уже не хватает - возникает куча смещений в потоке. А ведь мне ещё и с данными фрейма поработать нужно успеть, да ещё и нарисовать его, например в intencity graph (или как лучше выводить изображение в LV? Может тулбокс какой-то есть чтобы выдавать "видеопоток" на скорости монитора, например 120Гц)
Гугл на тему быстрых вычислений в LV советует купить PXI и зашить всё в плис - я в принципе согласен, но сейчас хочется разобраться в вопросе на ПК.
Вопросы:
1) У меня в коде есть какой-то ресурсоёмкий момент, мешающий быстрому исполнению?
2) i3-2350M дремучее дно и не тянет (да и LV надо 2022 - модный, быстрый...)?
3) нужно переписать чувствительные ко времени куски на другом языке и вызывать их через call library function чтобы было быстрее?
4) как использовать дополнительные аппаратные инструкции для ускорения рассчетов вроде avx, sse и т.п. или LV и так использует всё что есть по максимуму?
5) По хорошему-то мне надо вообще 100+фпс успевать...

[Juri]

Избавьтесь от build array. Создайте массив в начале программы и заменяйте его значения в процессе исполнения. Кроме того посмотрите какие процессы можно распараллелить. Сейчас впечатление, что у вас вся нагрузка идет на одно ядро процессора.

[nae]

Склеивание двух кусков через билдаррей не такая уж и затратная операция, учитывая то, что я это делаю всего один раз за кадр. Как бы не понятно почему выкладывание двух кусков в буфер будет быстрее билдаррея этих двух кусков. Но попробую.
Нагрузка действительно на одно ядро. Я даже делал два таймедлупа (на вычитку потока и на отрисовку через intesity graph) и ставил им в качестве процессорайди 0 и 3 или любые другие числа (у меня схема процессора 2/4), но всё равно нагрузка была только на одно ядро. Win10 показывает что процесс labview кушает 30% (с ядрами 0 и 3 на циклах), аида показала занятость в районе 50% и потребление процессора в районе 16Вт.
Как правильно скидывать задачу на другое ядро?

[dadreamer]

1. Не манипулировать ссылками (reference) во времякритичных циклах, т.к. обращение к ссылкам выполняется через Property/Invoke Nodes, которые выполняются в UI-потоке. Заменить узлы Value на "локалки" хотя бы.
2. Сделать все используемые FTDI саб-ВИ реентерантными и установить все вызываемые CLFN как Any thread (жёлтые).
3. Попробовать бинарный поиск вместо классического. Готового инструмента в нет, но реализация там простая.

[nae]

О! А нет ли случайно способа установить FTDI драйвер (или совместимый) на борт к sb9637 (гуманитарный кит) ? Чтобы читать его по USB из LV RT?!

[nae]

1. Не манипулировать ссылками (reference) во времякритичных циклах, т.к. обращение к ссылкам выполняется через Property/Invoke Nodes, которые выполняются в UI-потоке. Заменить узлы Value на "локалки" хотя бы.
2. Сделать все используемые FTDI саб-ВИ реентерантными и установить все вызываемые CLFN как Any thread (жёлтые).
3. Попробовать бинарный поиск вместо классического. Готового инструмента в нет, но реализация там простая.

1. Буферизовать через сдвиговый регистр и поманипулировать уже снаружи? Так-то буферы там не весть какие большие - самый жирный около полмегабайта. Т. е. чтобы полностью от потока UI отвязаться нужно передавать буферы в эту функцию без ссылок?
2. Да, CLFN были красненькие - в потоке UI выполнялись...
3. Попробую.

[dadreamer]

1. Буферизовать через сдвиговый регистр и поманипулировать уже снаружи? Так-то буферы там не весть какие большие - самый жирный около полмегабайта. Т. е. чтобы полностью от потока UI отвязаться нужно передавать буферы в эту функцию без ссылок?

Да, можно использовать регистры/FN, локальные переменные, очереди, уведомители. Ссылки уместно использовать там, где не требуется высокая производительность, например в цикле обработки (G)UI событий.