Страница 2 из 3

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

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

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

Просто в одном событии мне трубуется спускать в Cinsumer данные, в каком-то нет, но так не работает - данные приходится запихивать каждый раз.

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

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

Подскажите, правильно ли я всё реализовал в структуре Producer/Consumer или имелось ввиду несколько другое?
Как ещё можно улучшить код? Что ещё можно сделать модульнее?

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

Добавлено: 19 мар 2018, 13:52
taras_33
Как ещё можно улучшить код? Что ещё можно сделать модульнее?
Многое еще можно улучшить, для начала оформите все в виде проекта, что бы легче было народу разбираться кто кого вызывает и откуда. И если data_input.vi главный - то и назовите его как нибудь типа main.vi

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

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

Вопрос прежний - правильно ли реализована структура Producer/Consumer и что бы ещё Вы улучшили.

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

Добавлено: 26 мар 2018, 16:06
taras_33
Это не основной проект, а маленькая форма, выдернутая из большого проекта
Это совсем другая история. Трудно что либо советовать не зная общей архитектуры проекта.
В больших проектах использую только Actor Framework. Пару лет назад писал о нем на этом форуме
Преимущества данного инструмента очевидны. В нем реализованы все преимущества ООП. Но почему то широкого распространения в России (во всяком случае на этом форуме) он получил. А вот в США у LV программистов, теми с которыми я знаком , это считается стандартом. Но навязывать именно эту модель программирования я не буду, думаю что это будет сложно для понимания (в смысле для не подготовленного программиста).

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

Добавлено: 26 мар 2018, 19:55
taras_33
Использование переменных не запрещено, но крайне затрудняет читабельность кода, поэтому не рекомендуется. Начните работать со ссылками (reference). Создайте cluster, обзовите его как нибудь типа Run Parameters, сделайте type def-ом и запихайте в него references всех контролов с лицевой панели. Используя этот кластер как вход SubVI у вас будет доступ к свойствам контрола. Посмотрите скриншот, думаю будет понятно, что я имею ввиду
Тема недавно поднималась

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

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

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

Добавлено: 27 мар 2018, 18:27
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 некоторого контрола. "Локалки" такое не могут.

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

Добавлено: 27 мар 2018, 20:28
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 будет возможность послать комманду этому же циклу. Этакая управляемая стейт машина. Вообщем полет фантазии ничем не ограничен.

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

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

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

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

to: K0sinus Еще совет: В случае возникновения какой либо ошибки в нижнем цикле, с последующей его остановкой, UI останется работать и Ваша программа "повиснет". Поэтому create user event и в случае ошибки - генерируйте событие, которое остановит UI (верхний цикл)

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

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

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

Добавлено: 29 мар 2018, 17:33
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

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

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

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

Добавлено: 30 мар 2018, 09:29
Artem.spb
K0sinus писал(а):Mechanical action кнопки менял, не помогло.
так не бывает.
кнопки с отскоком не получится вытащить, а вот с переключением возвращают нормальноые bool
buttons.PNG
buttons.PNG (2.22 КБ) 5779 просмотров