Нужны критика и нравоучения. Формирование импульсов

Делись идеей, получай поддержку и критику!
K0sinus
user
user
Сообщения: 70
Зарегистрирован: 22 ноя 2017, 10:29
Версия LabVIEW: 2019
Откуда: Санкт-Петербург
Поблагодарили: 2 раза
Контактная информация:

Re: Нужны критика и нравоучения. Формирование импульсов

Сообщение K0sinus »

Т.е. в сам event structure кроме добавления в очередь ничего не добавлять? Даже простейшую обработку события? Или я могу кроме, например, добавления в очередь состояния "перерасчёт", в определенном событии сделать что-то, что в это состояние не входит? (Просто многие события должны триггерить этот перерасчёт, но кое-что должны делать уникальное).

Или нельзя разным событиям давать одно состояние и надо для каждого делать отдельное?

Просто в одном событии мне трубуется спускать в Cinsumer данные, в каком-то нет, но так не работает - данные приходится запихивать каждый раз.
K0sinus
user
user
Сообщения: 70
Зарегистрирован: 22 ноя 2017, 10:29
Версия LabVIEW: 2019
Откуда: Санкт-Петербург
Поблагодарили: 2 раза
Контактная информация:

Re: Нужны критика и нравоучения. Формирование импульсов

Сообщение K0sinus »

Коллеги, спасибо за рекомендации. Спешу похвастаться результатом - напоминаю, главный файл - data_input.vi.

Подскажите, правильно ли я всё реализовал в структуре Producer/Consumer или имелось ввиду несколько другое?
Как ещё можно улучшить код? Что ещё можно сделать модульнее?
Вложения
datainp.rar
(465.85 КБ) 218 скачиваний
Аватара пользователя
taras_33

Activity
professional
professional
Сообщения: 391
Зарегистрирован: 31 окт 2009, 18:25
Награды: 1
Версия LabVIEW: 2019
Поблагодарили: 13 раз
Контактная информация:

Re: Нужны критика и нравоучения. Формирование импульсов

Сообщение taras_33 »

Как ещё можно улучшить код? Что ещё можно сделать модульнее?
Многое еще можно улучшить, для начала оформите все в виде проекта, что бы легче было народу разбираться кто кого вызывает и откуда. И если data_input.vi главный - то и назовите его как нибудь типа main.vi
Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots.
So far, the Universe is winning!
K0sinus
user
user
Сообщения: 70
Зарегистрирован: 22 ноя 2017, 10:29
Версия LabVIEW: 2019
Откуда: Санкт-Петербург
Поблагодарили: 2 раза
Контактная информация:

Re: Нужны критика и нравоучения. Формирование импульсов

Сообщение K0sinus »

Это не основной проект, а маленькая форма, выдернутая из большого проекта - и там есть main.vi, поэтому я не видел смысла делать отдельный подпроект. Но раз Вы просите, конечно сделаю, это не сложно.

Вопрос прежний - правильно ли реализована структура Producer/Consumer и что бы ещё Вы улучшили.
Вложения
datainp.rar
(467.02 КБ) 178 скачиваний
Аватара пользователя
taras_33

Activity
professional
professional
Сообщения: 391
Зарегистрирован: 31 окт 2009, 18:25
Награды: 1
Версия LabVIEW: 2019
Поблагодарили: 13 раз
Контактная информация:

Re: Нужны критика и нравоучения. Формирование импульсов

Сообщение taras_33 »

Это не основной проект, а маленькая форма, выдернутая из большого проекта
Это совсем другая история. Трудно что либо советовать не зная общей архитектуры проекта.
В больших проектах использую только Actor Framework. Пару лет назад писал о нем на этом форуме
Преимущества данного инструмента очевидны. В нем реализованы все преимущества ООП. Но почему то широкого распространения в России (во всяком случае на этом форуме) он получил. А вот в США у LV программистов, теми с которыми я знаком , это считается стандартом. Но навязывать именно эту модель программирования я не буду, думаю что это будет сложно для понимания (в смысле для не подготовленного программиста).
Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots.
So far, the Universe is winning!
Аватара пользователя
taras_33

Activity
professional
professional
Сообщения: 391
Зарегистрирован: 31 окт 2009, 18:25
Награды: 1
Версия LabVIEW: 2019
Поблагодарили: 13 раз
Контактная информация:

Re: Нужны критика и нравоучения. Формирование импульсов

Сообщение taras_33 »

Использование переменных не запрещено, но крайне затрудняет читабельность кода, поэтому не рекомендуется. Начните работать со ссылками (reference). Создайте cluster, обзовите его как нибудь типа Run Parameters, сделайте type def-ом и запихайте в него references всех контролов с лицевой панели. Используя этот кластер как вход SubVI у вас будет доступ к свойствам контрола. Посмотрите скриншот, думаю будет понятно, что я имею ввиду
Тема недавно поднималась
Вложения
Run Parameters.png
Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots.
So far, the Universe is winning!
K0sinus
user
user
Сообщения: 70
Зарегистрирован: 22 ноя 2017, 10:29
Версия LabVIEW: 2019
Откуда: Санкт-Петербург
Поблагодарили: 2 раза
Контактная информация:

Re: Нужны критика и нравоучения. Формирование импульсов

Сообщение K0sinus »

Правильно ли я понял две вещи:
1. Reference+Property node:value предпочтительнее, чем local variable;
2. В структуре priducer/consumer в продюсере не надо спускать данные в продюсер, а можно сразу протащить в консюмер кластер с ссылками через шрифт регистр?
Аватара пользователя
dadreamer

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

Re: Нужны критика и нравоучения. Формирование импульсов

Сообщение dadreamer »

K0sinus писал(а):1. Reference+Property node:value предпочтительнее, чем local variable;
Добавлю свои пять копеек. Однозначно нельзя сказать, что лучше. С помощью Property Node -> Value можно тоже устроить ситуацию гонки, если не понимать принцип потока данных. В этом плане свойство Value от "локалки" ничем не отличается. У узлов свойств есть один минус, которого нет у локальных переменных, - почти все (около 90%) Property/Invoke Nodes выполняются в UI-потоке, который один на всё приложение. Если в данный момент выполняется какой-либо узел свойств, другие узлы вынуждены ждать, пока он не отработает (то же касается CLFN в режиме UI). Это может приводить к "веселым" эффектам, когда юзер нажал на заголовок окна или решил попереключать вкладки Tab-контрола, а времякритичный цикл встал на несколько сотен миллисекунд. Поэтому всё-таки желательно запускать Property/Invoke в отдельном цикле, работающем с элементами UI (кнопки, индикаторы и прочие вещи). А в других циклах использовать инструменты синхронизации или те же "локалки" (имея некоторый опыт работы с ними довольно легко избегать ситуаций гонки). В принципе, в цикле State Machine можно пользоваться и тем, и другим, если это не сказывается на работоспособности программы - например, пуск заданного режима - отключение/включение части контролов, т.е. моменты, когда переключение в UI не нарушит чего-то важного.
С другой стороны, с помощью Property Node -> Value (Signaling) можно вызвать срабатывание события Value Change некоторого контрола. "Локалки" такое не могут.
Аватара пользователя
taras_33

Activity
professional
professional
Сообщения: 391
Зарегистрирован: 31 окт 2009, 18:25
Награды: 1
Версия LabVIEW: 2019
Поблагодарили: 13 раз
Контактная информация:

Re: Нужны критика и нравоучения. Формирование импульсов

Сообщение taras_33 »

Правильно ли я понял две вещи:
1. Reference+Property node:value предпочтительнее, чем local variable;
dadreamer прав в том что property node в большинстве своем выполняются в UI потоке. Критичные по времени вычисления естественно должны выполняться в отдельных потоках, посему в своих проектах используя property node "веселых" эфектов пока удается избежать.
2. В структуре priducer/consumer в продюсере не надо спускать данные в продюсер, а можно сразу протащить в консюмер кластер с ссылками через шрифт регистр?
Так зачем их "спускать" через очередь, если они доступны сразу. Кластер со всеми references , "Run Parameters" в приведенном выше примере напоминает данные класса... Впрочем сейчас не об этом..
Как уже упоминалось, постарайтесь максимально избавиться от property node в верхнем цикле. Там же стоит минимизировать любые сравнения/вычисления. Нужно что то вычислить - опеделите какие данные нужны для этого и каких нет в нижем цикле - вот их и передавайте. А если они все доступны, так и передавайте только команду, без данных.
Кстати кластер Run Parameters может содержать не только ссылки, но и какие-то переменные необходимые для вычислений. Я Вам больше скажу - заведите туда ссылку на саму очередь.
Create constant.png
В этом случае у Вас в нижнем цикле в SubVI будет возможность послать комманду этому же циклу. Этакая управляемая стейт машина. Вообщем полет фантазии ничем не ограничен.
Вложения
Queue.png
Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots.
So far, the Universe is winning!
Аватара пользователя
dadreamer

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

Re: Нужны критика и нравоучения. Формирование импульсов

Сообщение dadreamer »

taras_33 писал(а):Кстати кластер Run Parameters может содержать не только ссылки, но и какие-то переменные необходимые для вычислений. Я Вам больше скажу - заведите туда ссылку на саму очередь.
Это, ктати, довольно хороший подход, на мой взгляд. Если запаковать все ссылки программы в кластер (или вариант, кому что нравится) и расфасовать кластер по SubVI/циклам, то получится достаточно гибкая архитектура, где можно из любого подприбора управлять остальными циклами, например послать команду в UI или SM, да что угодно.
Аватара пользователя
taras_33

Activity
professional
professional
Сообщения: 391
Зарегистрирован: 31 окт 2009, 18:25
Награды: 1
Версия LabVIEW: 2019
Поблагодарили: 13 раз
Контактная информация:

Re: Нужны критика и нравоучения. Формирование импульсов

Сообщение taras_33 »

Это, ктати, довольно хороший подход, на мой взгляд. Если запаковать все ссылки программы в кластер
Я раньше делал немного по другому, использовал FGV для инициализации и хранения очередей и user events. Это давало возможность разнести в отдельные VI produser-ы и consumer-ы, кроме того избаляло от "лишних" проводов и блок диаграммы выглядели более красиво.

to: K0sinus Еще совет: В случае возникновения какой либо ошибки в нижнем цикле, с последующей его остановкой, UI останется работать и Ваша программа "повиснет". Поэтому create user event и в случае ошибки - генерируйте событие, которое остановит UI (верхний цикл)
Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots.
So far, the Universe is winning!
K0sinus
user
user
Сообщения: 70
Зарегистрирован: 22 ноя 2017, 10:29
Версия LabVIEW: 2019
Откуда: Санкт-Петербург
Поблагодарили: 2 раза
Контактная информация:

Re: Нужны критика и нравоучения. Формирование импульсов

Сообщение K0sinus »

Спасибо, что-то начало проясняться. Я бы не назвал этот вид лучше читаемым, чем то, что было, но, думаю, к этому быстро привыкают.
Многое из написанного пока не осмыслил (особенно некоторые аббриавиатуры мне неизвестны).
Я правильно понял, что я могу этот же кластер с ссылками использовать и как вход и выход для данного VI, а не только для его subVI's? Т.е. заменить мои Memory in и Memory out (так у меня было реализовано восстановление данных при отмене)
Аватара пользователя
taras_33

Activity
professional
professional
Сообщения: 391
Зарегистрирован: 31 окт 2009, 18:25
Награды: 1
Версия LabVIEW: 2019
Поблагодарили: 13 раз
Контактная информация:

Re: Нужны критика и нравоучения. Формирование импульсов

Сообщение taras_33 »

По поводу user event посмотрите VI, думаю разберетесь, если нет - поможем :wink:
Producer_Consumer.vi
(35.39 КБ) 185 скачиваний
По аббревиатурам:
UI = User Interface
UE = User Event
SM = State Machine
FGV = Function Global Variable
Я правильно понял, что я могу этот же кластер с ссылками использовать и как вход и выход для данного VI, а не только для его subVI's?
А почему нет? Как и говорил полет фантазии не ограничен.

Когда я говорил, что использовал ранее FGV для хранения очередей, то я имел ввиду вот это (в очень упрощенном виде конечно) :
FGV.png
Тогда в VI и subVI не нужно тащить провод от очереди, а использовать эту FGV
Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots.
So far, the Universe is winning!
K0sinus
user
user
Сообщения: 70
Зарегистрирован: 22 ноя 2017, 10:29
Версия LabVIEW: 2019
Откуда: Санкт-Петербург
Поблагодарили: 2 раза
Контактная информация:

Re: Нужны критика и нравоучения. Формирование импульсов

Сообщение K0sinus »

Такой вопрос ещё. Если брать референс кнопки и получать value, она не булевская, а вариантная (фиолетовая), соответственно, ее из кластера не вытащить, приходится спускать из продюсера. Есть способ ее конвертировать в bool? Mechanical action кнопки менял, не помогло.
Artem.spb

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

Re: Нужны критика и нравоучения. Формирование импульсов

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

K0sinus писал(а):Mechanical action кнопки менял, не помогло.
так не бывает.
кнопки с отскоком не получится вытащить, а вот с переключением возвращают нормальноые bool
buttons.PNG
buttons.PNG (2.22 КБ) 5770 просмотров
Ответить
  • Похожие темы
    Ответы
    Просмотры
    Последнее сообщение

Вернуться в «Проекты»