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

Простейшие вопросы в области инженерной разработки
rsv
advanced
advanced
Сообщения: 170
Зарегистрирован: 18 июл 2019, 13:53
Версия LabVIEW: 2020
Откуда: Россия, Ижевск
Благодарил (а): 33 раза
Контактная информация:

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

Сообщение rsv »

Узнал много нового - и про функцию Type Cast, и про библиотеку OpenG.
Всем спасибо.
rsv
advanced
advanced
Сообщения: 170
Зарегистрирован: 18 июл 2019, 13:53
Версия LabVIEW: 2020
Откуда: Россия, Ижевск
Благодарил (а): 33 раза
Контактная информация:

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

Сообщение rsv »

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

Activity Автор
professor
professor
Сообщения: 3438
Зарегистрирован: 31 июл 2011, 23:05
Награды: 2
Версия LabVIEW: 12-18
Благодарил (а): 52 раза
Поблагодарили: 176 раз
Контактная информация:

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

Сообщение Artem.spb »

rsv писал(а): 02 фев 2021, 18:36 - из каждого модуля обращаться к сетевой переменной и через Unbundle вытаскивать нужные уставки;
- перед запуском цикла считать кластер в локальную переменную и передавать в каждый модуль в виде параметра;
Может есть ещё какие-то более быстродействующие решения?
хранить данные в проводах и извлекать из них по необходимости - самый быстрый и рекомендуемый способ
Аватара пользователя
Kosist

Activity Gold
expert
expert
Сообщения: 1237
Зарегистрирован: 21 фев 2011, 23:44
Награды: 2
Версия LabVIEW: 2013-2020
Благодарил (а): 23 раза
Поблагодарили: 30 раз
Контактная информация:

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

Сообщение Kosist »

rsv писал(а): 02 фев 2021, 18:36 Может есть ещё какие-то более быстродействующие решения?
Скорость здесь - вообще не решающий фактор, т.к. если конфигурационные параметры считываются/устанавливаются один раз, то это влияет на быстродействие приложения самым незначительным способом. А если Вы "дергаете" эти значения постоянно - что-то не так со структурой модулей. Ведь если настройки не меняются - зачем их постоянно считывать? Почему быстродействие актуально? Быстродействие по Вашему - это какие величины, как быстро это должно происходить?
Я бы больше волновался о архитектуре - например, разделить конфигурацию на отдельные классы/кластеры для каждого модуля. Потому как если все параметры записать в один кластер, а потом использовать его между разными модулями вытягивая лишь нужные параметры - создается сильная связка модулей, что не есть хорошо.
Мы делили апельсин - много наших полегло...
ujin1
adviser
adviser
Сообщения: 233
Зарегистрирован: 06 ноя 2020, 15:37
Версия LabVIEW: 19
Благодарил (а): 18 раз
Поблагодарили: 37 раз
Контактная информация:

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

Сообщение ujin1 »

rsv писал(а): 02 фев 2021, 18:36 - перед запуском цикла считать кластер в локальную переменную и передавать в каждый модуль в виде параметра;
Такой есть вариант
Подключить сформированный кластер к входу цикла или сдвиговому регистру. Это если параметров много и неудобно использовать провода.
Извлекать из кластера данные по мере необходимости.
По скорости должно быть как чтение локальной переменной, только локальная переменная ссылается на элемент передней панели, а вход и сдвиговый регистр в памяти на диаграмме.
Данные.png
Изображение
ujin1
adviser
adviser
Сообщения: 233
Зарегистрирован: 06 ноя 2020, 15:37
Версия LabVIEW: 19
Благодарил (а): 18 раз
Поблагодарили: 37 раз
Контактная информация:

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

Сообщение ujin1 »

Kosist писал(а): 02 фев 2021, 23:20 ...вытягивая лишь нужные параметры - создается сильная связка модулей, что не есть хорошо.
В JKI State machine при инициализации используют bundle (не bundle by name). Все параметры именованные. Нужные параметры далее unbundle by name.
Новый элемент добавляется в кластер не ломая ничего дальше. Связка при таком способе отсутствует.
Вложения
Данные1.png
Изображение
rsv
advanced
advanced
Сообщения: 170
Зарегистрирован: 18 июл 2019, 13:53
Версия LabVIEW: 2020
Откуда: Россия, Ижевск
Благодарил (а): 33 раза
Контактная информация:

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

Сообщение rsv »

Kosist писал(а): 02 фев 2021, 23:20 Скорость здесь - вообще не решающий фактор, т.к. если конфигурационные параметры считываются/устанавливаются один раз, то это влияет на быстродействие приложения самым незначительным способом. А если Вы "дергаете" эти значения постоянно - что-то не так со структурой модулей. Ведь если настройки не меняются - зачем их постоянно считывать?
Собственно, я и спрашивал что бы понять как лучше работать с неизменными конфигурационными параметрами...
Под дёрганием Вы понимаете считывание именно из сетевой переменной? А недёрганье - это то, что предложил ujin1 (кластер из сетевой переменной подаётся на вход цикла, а внутри модулей из входного кластера вытаскиваются нужные параметры)?
Kosist писал(а): 02 фев 2021, 23:20 Почему быстродействие актуально? Быстродействие по Вашему - это какие величины, как быстро это должно происходить?
1 итерация = 1 миллисекунда
Kosist писал(а): 02 фев 2021, 23:20 Я бы больше волновался о архитектуре - например, разделить конфигурацию на отдельные классы/кластеры для каждого модуля. Потому как если все параметры записать в один кластер, а потом использовать его между разными модулями вытягивая лишь нужные параметры - создается сильная связка модулей, что не есть хорошо.
Так и сделано - для каждого выходного сигнала используется свой кластер уставок. И к моменту запуска цикла они приходят разными извилистыми путями. Но для расчёта всё равно приходится несколько модулей использовать...
Artem.spb

Activity Автор
professor
professor
Сообщения: 3438
Зарегистрирован: 31 июл 2011, 23:05
Награды: 2
Версия LabVIEW: 12-18
Благодарил (а): 52 раза
Поблагодарили: 176 раз
Контактная информация:

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

Сообщение Artem.spb »

rsv писал(а): 03 фев 2021, 08:15 1 итерация = 1 миллисекунда
Не слишком ли шустро? Может можно оптимизировать код и "склеить" несколько итераций в одну?
Аватара пользователя
nae
user
user
Сообщения: 79
Зарегистрирован: 20 мар 2014, 14:21
Версия LabVIEW: 15
Откуда: Новосибирск
Благодарил (а): 5 раз
Контактная информация:

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

Сообщение 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+фпс успевать...
Вложения
2022-07-08_12-43-13.png
Аватара пользователя
Juri
I/O
I/O
Сообщения: 268
Зарегистрирован: 19 апр 2017, 23:06
Версия LabVIEW: 2021
Благодарил (а): 15 раз
Поблагодарили: 6 раз

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

Сообщение Juri »

Избавьтесь от build array. Создайте массив в начале программы и заменяйте его значения в процессе исполнения. Кроме того посмотрите какие процессы можно распараллелить. Сейчас впечатление, что у вас вся нагрузка идет на одно ядро процессора.
Аватара пользователя
nae
user
user
Сообщения: 79
Зарегистрирован: 20 мар 2014, 14:21
Версия LabVIEW: 15
Откуда: Новосибирск
Благодарил (а): 5 раз
Контактная информация:

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

Сообщение nae »

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

Activity Professionalism Автор
professor
professor
Сообщения: 3939
Зарегистрирован: 17 фев 2013, 16:33
Награды: 4
Версия LabVIEW: 2.5 — 2022
Благодарил (а): 12 раз
Поблагодарили: 133 раза
Контактная информация:

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

Сообщение dadreamer »

1. Не манипулировать ссылками (reference) во времякритичных циклах, т.к. обращение к ссылкам выполняется через Property/Invoke Nodes, которые выполняются в UI-потоке. Заменить узлы Value на "локалки" хотя бы.
2. Сделать все используемые FTDI саб-ВИ реентерантными и установить все вызываемые CLFN как Any thread (жёлтые).
3. Попробовать бинарный поиск вместо классического. Готового инструмента в :labview: нет, но реализация там простая.
Аватара пользователя
nae
user
user
Сообщения: 79
Зарегистрирован: 20 мар 2014, 14:21
Версия LabVIEW: 15
Откуда: Новосибирск
Благодарил (а): 5 раз
Контактная информация:

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

Сообщение nae »

О! А нет ли случайно способа установить FTDI драйвер (или совместимый) на борт к sb9637 (гуманитарный кит) ? Чтобы читать его по USB из LV RT?!
Аватара пользователя
nae
user
user
Сообщения: 79
Зарегистрирован: 20 мар 2014, 14:21
Версия LabVIEW: 15
Откуда: Новосибирск
Благодарил (а): 5 раз
Контактная информация:

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

Сообщение nae »

dadreamer писал(а): 08 июл 2022, 14:48 1. Не манипулировать ссылками (reference) во времякритичных циклах, т.к. обращение к ссылкам выполняется через Property/Invoke Nodes, которые выполняются в UI-потоке. Заменить узлы Value на "локалки" хотя бы.
2. Сделать все используемые FTDI саб-ВИ реентерантными и установить все вызываемые CLFN как Any thread (жёлтые).
3. Попробовать бинарный поиск вместо классического. Готового инструмента в :labview: нет, но реализация там простая.
1. Буферизовать через сдвиговый регистр и поманипулировать уже снаружи? Так-то буферы там не весть какие большие - самый жирный около полмегабайта. Т. е. чтобы полностью от потока UI отвязаться нужно передавать буферы в эту функцию без ссылок?
2. Да, CLFN были красненькие - в потоке UI выполнялись...
3. Попробую.
Аватара пользователя
dadreamer

Activity Professionalism Автор
professor
professor
Сообщения: 3939
Зарегистрирован: 17 фев 2013, 16:33
Награды: 4
Версия LabVIEW: 2.5 — 2022
Благодарил (а): 12 раз
Поблагодарили: 133 раза
Контактная информация:

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

Сообщение dadreamer »

nae писал(а): 08 июл 2022, 15:411. Буферизовать через сдвиговый регистр и поманипулировать уже снаружи? Так-то буферы там не весть какие большие - самый жирный около полмегабайта. Т. е. чтобы полностью от потока UI отвязаться нужно передавать буферы в эту функцию без ссылок?
Да, можно использовать регистры/FN, локальные переменные, очереди, уведомители. Ссылки уместно использовать там, где не требуется высокая производительность, например в цикле обработки (G)UI событий.
Ответить
  • Похожие темы
    Ответы
    Просмотры
    Последнее сообщение

Вернуться в «Для чайников»