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

[taras_33]

Один раз наблюдал такой глюк. Кнопка имеет latch, соответственно её значение variant и ни считать ни записать нельзя. Меняю mechanical action на switch. А value из property node остаётся variant! Бред какой-то. Помогло удаление кнопки с панели с обратным восстанавлением. И ещё если меняете action кнопки, нужно заменить её reference в кластере. При инициализации references LabVIEW нарисует крест на проводе если они не совпадают, но глюки случаются ....

[K0sinus]

Один раз наблюдал такой глюк

Да, это как раз он и был. Плюс путаница с тайпдефами и кластерами. Вроде разобрался, спасибо!

Вот, что у меня получилось, всё стало модульнее, компактнее, с ссылками (к последнему пока не привык полностью, но надо, значит надо).
Правильно ли я всё реализовал? Не обошлось конечно и без property node:value(signaling) в producer'е, это критично? Или лучше создать ещё пару состояний в консюмере?

Еще, впервые работаю с кластером ошибок, поэтому получилась такая паутина в некоторых subV, поправьте тоже, если можно сделать лучше.

Пока не реализовал запоминание/сброс параметров при повторном запуске этого VI как subVI, но это впереди. Еще ломаю голову, как строить касательную только по положительным импульсам, но с этим должен разобраться сам - у вас прошу консультаций по стилю и оптимизации.

[K0sinus]

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

[Artem.spb]

Неудобный (по мне) метод: правой на ссылку в тайпдефе, там "select vi server class" и дале по меню.
Я же обычно правой на сам контрол, из меню выбираю "создать ref", и этот реф уже перетаскиваю в тайпдеф.
Если совсем сурово и часто приходится менять один их элементов, то моэжно и его сделать тайпдефом. И этот тайпдеф поместить в тайпдеф.

[K0sinus]

Вот, что у меня получилось, всё стало модульнее, компактнее, с ссылками (к последнему пока не привык полностью, но надо, значит надо).
Правильно ли я всё реализовал? Не обошлось конечно и без property node:value(signaling) в producer'е, это критично? Или лучше создать ещё пару состояний в консюмере?

Еще, впервые работаю с кластером ошибок, поэтому получилась такая паутина в некоторых subV, поправьте тоже, если можно сделать лучше.

Пока никто не отвечает, буду спрашивать дальше

Вопрос такой: может, в данной программе можно было воспользоваться какими-то готовыми решениями, а не писать с нуля? Например, сами импульсы или сохранение с шифрованием? Я нигде велосипеда не сделал?

[K0sinus]

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

[FireFly]

При использовании подхода producer/consumer всегда есть вероятность, что в какой-то момент времени (на короткий период) producer (или несколько producers) начнёт генерировать события быстрее чем consumer их обрабатывает.
Использование очереди позволяет не потерять эти события, в отличии от нотифаера.

[Artem.spb]

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

Кроме возможности поставить в очередь больше одного элемента есть ещё одно ключевое различие:
очередь = от многих одному,
нотификаторы - от одного многим.

Читатель очереди вытаскивает элемент из неё, так что параллельное чтение без глюков не получится.Обращение к нотификатору не удаляет элемент, так что можно проверять параллельно из нескольких мест.