Нотифьеры, очереди и логика

Общие принципы, проектирование, модуляризация, темплейты и шаблоны
rbl
assistant
assistant
Сообщения: 122
Зарегистрирован: 09 дек 2014, 10:14
Версия LabVIEW: 7-2015
Откуда: Санкт-Петербург
Контактная информация:

Re: Нотифьеры, очереди и логика

Сообщение rbl »

Количество подсистем конечно или оно изменяется в процессе функционирования? Если конечно, то что мешает добавить создание очередей в инициализацию (пусть даже избыточно) и в подсистемах только добавлять/извлекать элементы? Убивать очереди при остановке основной программы. В инициализации все очереди поместить в кластер кластеров, его преобразовать в Strict Type Def. После чего подключаем его на вход каждой подсистемы. В итоге имеем доступ ко всем очередям и редактирование в одном месте. У меня подобное прекрасно работает, при этом довольно шустро и долго (400 Гц, несколько суток).
Borjomy_1

Activity Professionalism Silver
doctor
doctor
Сообщения: 2210
Зарегистрирован: 28 июн 2012, 09:32
Награды: 3
Версия LabVIEW: 2009..2020
Откуда: город семи холмов
Благодарил (а): 27 раз
Поблагодарили: 26 раз

Re: Нотифьеры, очереди и логика

Сообщение Borjomy_1 »

Мне вот тоже непонятно, зачем при создании очереди проверять, не убили ли ее в прошлой жизни. Ну ладно, обтаин говорит, что ошибка. Но в других местах как об этом узнают, что нотификатор грохнут??? И вообще, зачем грохать глобальный нотификатор? Глобальный он уже потому, что через него общаются не связанные друг с другом модули. Раз так, то создавать его надо уровнем выше. И не трогать до окончания работы этого уровня.
rbl
assistant
assistant
Сообщения: 122
Зарегистрирован: 09 дек 2014, 10:14
Версия LabVIEW: 7-2015
Откуда: Санкт-Петербург
Контактная информация:

Re: Нотифьеры, очереди и логика

Сообщение rbl »

Borjomy_1 писал(а):Мне вот тоже непонятно, зачем при создании очереди проверять, не убили ли ее в прошлой жизни. Ну ладно, обтаин говорит, что ошибка. Но в других местах как об этом узнают, что нотификатор грохнут??? И вообще, зачем грохать глобальный нотификатор? Глобальный он уже потому, что через него общаются не связанные друг с другом модули. Раз так, то создавать его надо уровнем выше. И не трогать до окончания работы этого уровня.
Угу. Возможно тут совсем инновационный подход, либо поиск сложного в простом.
AlexanderKonoval
developer
developer
Сообщения: 257
Зарегистрирован: 03 янв 2014, 19:37
Версия LabVIEW: 2016
Откуда: Украина, Киев
Контактная информация:

Re: Нотифьеры, очереди и логика

Сообщение AlexanderKonoval »

Ну, давайте примем, что мне это надо. В любом случае, если даже если я это не буду проверять - всё-равно имеем появившуюся ненужную ссылку при Obtain.

я так понимаю, что никто просто раньше не задавался вопросом, зачем :labview: создаёт каждый раз новую ссылку при Obtain и почему её не уничтожает после закрывания :vi: ?
колдооооовствооооо! (С)
rbl
assistant
assistant
Сообщения: 122
Зарегистрирован: 09 дек 2014, 10:14
Версия LabVIEW: 7-2015
Откуда: Санкт-Петербург
Контактная информация:

Re: Нотифьеры, очереди и логика

Сообщение rbl »

AlexanderKonoval, Не могли бы пояснить для чего Вам необходимо создавать очередь (Obtain) внутри цикла, а не при инициализации?
С точки зрения программирования мне Ваш подход понятен, но для подобной реализации нужны другие языки программирования, с корректно работающими "сборщиками мусора". В LabView же на мой взгляд лучше работать с инициализацией.
AlexanderKonoval
developer
developer
Сообщения: 257
Зарегистрирован: 03 янв 2014, 19:37
Версия LabVIEW: 2016
Откуда: Украина, Киев
Контактная информация:

Re: Нотифьеры, очереди и логика

Сообщение AlexanderKonoval »

rbl, я не создаю очередь внутри цикла.

я вызываю внутри цикла уже существующую очередь через Obtain.

Почему Obtain, а не тяну проводок? потому что придётся тянуть бесполезный проводок через 3-6 :vi: к нужному.

А в некоторых случаях - :vi: вызывается асинхронно, что также вызывает определённые неудобства при подключении проводка.

Поэтому использую Obtain. Внутри маленького субви, который только то и делает, что открывает ссылку на очередь, делает пакет из поступивших в него данных, шлёт пакет в очередь.

К тому же, это позволяет мне менять что-то в одном месте - в указанном выше субВИ. Что удобно при длительной поддержке ПО.
колдооооовствооооо! (С)
Borjomy_1

Activity Professionalism Silver
doctor
doctor
Сообщения: 2210
Зарегистрирован: 28 июн 2012, 09:32
Награды: 3
Версия LabVIEW: 2009..2020
Откуда: город семи холмов
Благодарил (а): 27 раз
Поблагодарили: 26 раз

Re: Нотифьеры, очереди и логика

Сообщение Borjomy_1 »

Из документации
If you wire name, the function first searches for an existing notifier with the same name and returns a new reference to the existing notifier.
Этот метод подобен использованию goto в C. Может, и решает локальные проблемы. Но при каждом вызове функции для передачи данных вызывается обтаин и создается новый reference. Для программы, которая работает 24/7 - это совсем не полезно.
Я бы не поленился и явно протянул референс. Ну в крайнем случае прокэшировал его в VI. Опять-же есть такой класс Tasking2.lvclass, в котором сведены несколько очередей и нотификаторов. Через него такие вещи организуются без бубна.
Последний раз редактировалось Borjomy_1 13 сен 2016, 14:34, всего редактировалось 1 раз.
alex3f
beginner
beginner
Сообщения: 26
Зарегистрирован: 23 авг 2016, 09:16
Версия LabVIEW: 2016
Контактная информация:

Re: Нотифьеры, очереди и логика

Сообщение alex3f »

AlexanderKonoval, Obtain Notifier предназначен для создания новой ссылки (пусть даже на тот же Notifier). Всё подробно описано во встроенной в :labview: справке или онлайн https://zone.ni.com/reference/en-XX/hel ... _notifier/. Если Вы хотите использовать уже существующую ссылку, то можно воспользоваться передачей через переменную, если использовать Ваш подход в программировании. Или, как Вы уже поняли, создавать и удалять ссылку каждый раз, как написано в справке. Но лучше всего использовать проводники и предусматривать в программе кластер с параметрами, которые могут понадобиться, и протягивать его практически везде.
Всё достаточно логично.
Аватара пользователя
dadreamer

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

Re: Нотифьеры, очереди и логика

Сообщение dadreamer »

AlexanderKonoval
alex3f написал практически то же самое, что написал бы я. Либо вы тянете провод Notifier'а в Саб-ВИ, либо вы закрываете ссылку всякий раз, как получили новый Notifier (через Obtain). Других (простых) способов это обойти нет. Любые референсы в :labview: внутреннее представляют собой magic cookie, т.е. целое число, являющее индексом в таблице объектов :labview: (magic cookie jar). Причин, почему :labview: создаёт новый cookie, при вызове Obtain, может быть несколько, я не буду в это сейчас углубляться. Либо вы используете предложенные варианты, либо можете использовать "голое" число I32 (через Type Cast на Notifier'e) в ваших Саб-ВИ с помощью глобальных переменных или как-то ещё (оно не будет меняться, пока работает ваш основной VI).
rbl
assistant
assistant
Сообщения: 122
Зарегистрирован: 09 дек 2014, 10:14
Версия LabVIEW: 7-2015
Откуда: Санкт-Петербург
Контактная информация:

Re: Нотифьеры, очереди и логика

Сообщение rbl »

AlexanderKonoval писал(а):rbl, я не создаю очередь внутри цикла.
я вызываю внутри цикла уже существующую очередь через Obtain.
Почему Obtain, а не тяну проводок? потому что придётся тянуть бесполезный проводок через 3-6 :vi: к нужному.
А в некоторых случаях - :vi: вызывается асинхронно, что также вызывает определённые неудобства при подключении проводка.
Поэтому использую Obtain. Внутри маленького субви, который только то и делает, что открывает ссылку на очередь, делает пакет из поступивших в него данных, шлёт пакет в очередь.
Понятно. Определенный резон есть, но боюсь не стандартное применение функции может привести к "выстрелу в ногу". Мне все таки ближе провести одну шину из кластера кластеров и не заниматься ловлей блох...
К тому же, это позволяет мне менять что-то в одном месте - в указанном выше субВИ. Что удобно при длительной поддержке ПО.
А вот тут я бы поспорил. Доработка ПО лет так через 5, в котором часть функционала скрыта в сабвишках на самом нижнем уровне далеко не так проста и очевидно, особенно при работе в группе.
Ответить

Вернуться в «Модели программирования»