И снова очереди

[Eugen Graf]

Ошибки я обрабатываю в потоках-циклах, а из потока у меня выходят кластеры без ошибок. Объединяются они в один для того, чтобы удостовериться, что все потоки закончены по принципу data flow.

[mzu2006]

Обработка ошибок в таких многопоточных архитектурах это очень интересная тема, и явно тянет не на один пост.

чтобы удостовериться, что все потоки закончены по принципу data flow

ты имел в виду, "перед тем как удалять очереди и user events", да?

[Eugen Graf]

Да.

[Pavel]

Следуя выше указанным советам я это и сделал, попутно добавив пару комментариев для таких же "чайников" как сам . Ничего не напутал? Значит можно использовать это как шаблон? Меня интересует обработка ошибок, я не совсем понимаю механизм. Зачем их всех собирать в кучку (в конце) и записывать в кластер, ни слова не сказав пользователю? Я так понимаю если уж мы их собрали, и произошла какая то ошибка, то нужно сообщить об этом, используя палитру Dialog and User Interface. Или я не прав?

Еще раз спасибо Eg и mzu2006

В цикле где закрываешь референсы на очереди и события я бы поставил проверку валидности референса. А то если хоть один из массива окажется битый то все остальные после него не закроются. Во-вторых у типа variant есть атрибуты которые можно использовать для передачи служебной информации к данным. И хоть твой вариант выглядит более наглядным все же иногда стоит использовать атрибуты. В третьих: если ошибка будет повторяться в каждой итерации цикла представь как ты достанешь пользователя своим Dialog and User Interface. Что б этого не было, используют лог (или 2 лога) куда обычно пишется все состояние программы.

[Eugen Graf]

Да, вариант с атрибутами я ещё не пробовал, думаю стоит посмотреть что это за зверь. А теперь об обработчике ошибок. У меня есть центральный обработчик ошибок, который отправляет возникшую ошибку, без открытия диалога в поток-индикатор-логгер лицевой панели.

[mzu2006]

В цикле где закрываешь референсы на очереди и события я бы поставил проверку валидности референса. А то если хоть один из массива окажется битый то все остальные после него не закроются.

проверять не надо, закроются нормально, т.к. Release Queue/Destroy UE выполняется даже при пришедшей на error in ошибке. 8.6 online help destroy user event

все же иногда стоит использовать атрибуты

На версии 7 я тестировал что быстрее: добавить ещё один элемент в кластер или использовать аттрибут варианта. Смутно помню, что аттрибут варианта получился медленнее. Как правило, тип передаваемых данных известен.

(или 2 лога)

А зачем 2 лога?

У меня есть центральный обработчик ошибок, который отправляет возникшую ошибку, без открытия диалога в поток-индикатор-логгер лицевой панели.

Да, я бы тоже так делал. Иногда возникает необходимость классифицировать ошибки: с чем-то можно разобраться на месте (в потоке драйвера). Что-то можно записать в лог, что-то выдать пользователю.

ты достанешь пользователя своим Dialog and User Interface.

Совершенно согласен. модальное окно диалога использовать не надо вообще. Как вариант: boolean indicators, которые загораются при ошибке в подсистеме, и кнопка сброса рядом. Или log с грамотной возможностью фильтрации.

[taras_33]

Доброе время суток народ. Два дня мучений и причина найдена..... Но вопрос остался открытым. Суть в следующем. Имеется три параллельные циклы (юзер интерфейс, прибор с RS232, индикатор) комунникация с помощью очередей. Этот кусок кода (извлечение элемента из очереди)

In Queue.PNG (3.15 КБ) 4206 просмотров

повторяется неоднократно, следовательно был создан SubVI

SubVI.PNG (1.16 КБ) 4206 просмотров

. Как оказалось в параллельный циклах одновременно этот SubVI не работает. Но стоит создать его копию с другим именем и включить в проект, все работает. Кто подскажет в чем дело?

[Eugen Graf]

Да, тебе следует сделать его реинтрантным (в установках).

[FireFly]

VI Properties -> Execution -> Reentrant execution
Почитай

[taras_33]

Спасибо мужики, снимаю шапку Все работает