LabVIEW Portal

Все верно, в real time это не работает, я просто не думал что кто то начнет сразу компилировать. Нужно не только Open FP но еще и Close. Как то так
Я правда все эти дела оформляю в SubVI. Но здесь оставим как есть, для наглядности. Кроме того, что будет, если один из методов вернет ошибку?
Все правильно, Actor вылетит с ошибкой, которую впрочем можно отловить, обработать и принять решение останавливать Actor, вызвавший ошибку или shutdown всю программу, а может просто проигнорировать и продолжать работу, как ни в чем не бывало. Но есть проблема, если Вы решаете остановить Actor, верхний while loop останется работать, он то об ошибке в “нижнем while loop” ни ухом ни рылом. Поэтому нужно добавить UE, которое пригодится не только в случае с ошибками, но и в случае, когда Вам нужно остановить Actor из другого Actor-a
Вооот… А теперь представьте, что у Вас десяток Актеров c UI, и че для каждого создавать user event-ы? Нет конечно, нужно просто создать общего родителя и там сделать одну UE и пользоваться этим ивентом во всех детях (если нужно конечно) Другой пример, в своих проектах, каждый запускаемый actor TCP, UDP, Config и тд отчитывается главному, мол я такой то, запустился без ошибок.. Процесс запуска и инициализации я обычно показываю на splash screen, в виде progress bar, этот splash screen служит по совместительству Launcher-ом Главный - ага, все запустились? Молодцы! Можно показывать юзеру окно программы. Естественно этот отчет сделан в абстрактном классе (родителе), а не в каждом отдельном ребенке. И вообще используя OOP можно свести к минимуму дублирование кода, вот этим AF и пользуется. Actor это не просто параллельный цикл, это отдельный независимый модуль, который может жить независимо своей жизнью, принимать собственные решения, базируясь (или нет) на инструкциях “сверху” ООП достаточно большая тема выходящая за рамки этого форума. Следующий раз, когда меня посетит муза, (обычно с бодуна, а выпиваю я крайне редко) я добавлю к этому проектику, какой нибудь генератор чисел, который будет слать эти числа в главное окно программы.

Часть десятая: Error Handle

Простейший пример обработки ошибки, а заодно научимся передавать информацию, в нашем случае это будет boolen.
Добавим на FP две кнопки, при нажатии на которые будем генерировать ошибки критическую и не очень Создадим метод, при вызове которого будут генерироваться эти ошибки, причем если передаваемый параметр ‘true’ то ошибка будет критической, если ‘false’ то легкой.
ПКМ Main FP.lvclass -> New -> VI From Static Dispatch Template. Делаем блок диаграмму, похожую на эту Сохраняем его под именем Custom Error, не забываем соединить Boolean input с коннектором Далее повторяем шаги, описанные в седьмой части Tools –> Actor Framework Message Maker выделяем наш сохранённый метод Custom Error и генерируем Custom Error Msg.lvclass. Перетаскиваем его в виртуальную папку Messages for Main class.
Создаем два события по нажатию кнопок и перетаскиваем туда из окна проекта Send Custom Error.vi В в одном случае передаем True во втором False Теперь повторяем шаги из пятой части, только сейчас выделяем Handle Error.vi, кликаем ок
Окно нашего проекта сейчас выглядит так Открываем Handle error.vi и изменяем блок диаграмму Все сохраняем, запускаем щелкаем по кнопкам, осмысливаем чего мы тут натворили

в приложении обновленный проект

Доброго всем времени суток господа девелоперы.
Что бы не плодить новые темы, решил продолжить в этой, потому предложеный мной проект использует все тот же Actor Framework. Практически все мои проекты используют эту замечательную библиотеку, как в явном виде, так и в скомпилированную в PPL
Ну о архитектуре plugin я уже упоминал в соответствующей теме и возможно в будущем я продемонстрирую какой нибудь пример. А сегодня хочу поделится демонстрационным проектом, цель которого ... показать как я завершаю выполнение программы. Например Ваша программа отслеживает и контролирует давление в какой то системе, было бы логично не просто завершить работу программы, но и перед этим произвести какие то действия: Закрыть открытые порты, установить в ноль блоки питания, открыть клапана - не оставлять же систему под давлением... Причем желательно наблюдать за процессом... И в случае если оператор женщина, иметь возможность передумать в самый последний момент....
Вообщем хватит демагогии. Разархивируем, открываем проект и запускаем Launcher. Тыкаем на кнопочки, оставляем коментарии.
Ах да, чуть не забыл - проект в LabVIEW 2016 с новой версией Actor Framework стало еще проще работать...

Хороший пример, но в случае работы с Actor Framework часто стоит задача еще и отследить закрытие/порядок закрытия акторов при завершении приложения. Понятно, что в таком случае поможет Handle Last Ack.vi метод, но и его использование должно быть правильным, дабы не заблокировать систему в целом. Интересно, решаете ли Вы тоже и эту задачу в своих проектах? Если да, то как именно обрабатываете задержку закрытия, если актор не останавливается сразу? Такой пример тоже был бы полезен здесь, если у Вас есть такой в "загашнике"
А вообще, интересно сколько людей на портале сейчас использует AF в проектах? Или что-то подобное, типа JKI SMO?..

Kosist писал(а):Интересно, решаете ли Вы тоже и эту задачу в своих проектах? Если да, то как именно обрабатываете задержку закрытия, если актор не останавливается сразу? Такой пример тоже был бы полезен здесь, если у Вас есть такой в "загашнике"

Естественно! Куда же без Last Ask. В среднем проекте используется порядка 20 Actors. Одни работают постоянно, других запускает/останавливает пользователь - тыкая на кнопочки. Нужно же как то отслеживать весь этот "табун". Вот здесь незаменимым оказывается Last Ask. Вариантов множество, все зависит от структуры программы и поставленой задачи. В простейшем случае можно поступить так. После запуска Actor-a его Enqueuer добавляем в массив
При завершении программы, разослать всем stop-ы и отслеживать в Last Ask который из актеров завершил работу и удалить его enqueuer из массива, попутно показывая запуск/остановку в строке состояния... Ну и проверять масив. Если масив пустой - закрываем главное окно программы. Повторюсь это простейший случай. В реальных проектах немного все сложнее, но и надежнее.
Когда дело касается какой то модификации существующего рабочего проекта, то OOP и AF вне конкуренции. Быстрота что то добавить/удалить/изменить, не затрагивая остальной рабочий код вот основное достоинство "этой парочки" Мое мнение таково: что грамотная структура программы намного важнее, чем грамотно написанная функция. В последствии функцию (vi) можно быстро переделать, а вот изменить структуру всего проекта куда сложнее.

При запуске нэстедов с флагом "Auto-stop" не тоже ли самое происходит? Вы так дублируете встроенное решение.

Aleksandr писал(а):При запуске нэстедов с флагом "Auto-stop" не тоже ли самое происходит? Вы так дублируете встроенное решение.

Не совсем. Вот текст из справки:

Auto-stop determines whether Nested Actor stops when the calling actor stops. The default value is TRUE. If you set the value of this input to FALSE, you must manually override the Stop Core VI on the caller actor to specify stop behavior for Nested Actor.

Т.е. если Вы остановили актор, который имеет nested actors, то тогда и они будут остановлены. Т.е. флаг "Auto-stop" помогает
остановить акторы. А если нужно вначале проконтроллировать их остановку, а уже потом остановку главного актора, то нужно использовать Handle Lask Ack.

Т.е. если Вы остановили актор, который имеет nested actors, то тогда и они будут остановлены. Т.е. флаг "Auto-stop" помогает
остановить акторы. А если нужно вначале проконтроллировать их остановку, а уже потом остановку главного актора, то нужно использовать Handle Lask Ack.

Ну так и используйте функцию "Read Autostop Nested Actor Count" в каждом "Handle Last Ack Core", не пойму чему противоречит.

Aleksandr писал(а):Ну так и используйте функцию "Read Autostop Nested Actor Count" в каждом "Handle Last Ack Core", не пойму чему противоречит.

А где будет вызываться функция "Read Autostop Nested Actor Count"? Главный актор будет остановлен, а значит Nested Actor, после остановки, посылает Last Ack сообщение "в никуда" (ошибки не будет). Это в случае флага "Auto-stop".
В целом, смысл следующий. Если Вы желаете просто останавливать акторы, не заботясь о порядке остановки, и в целом "правильности" остановки модулей, то конечно, флаг "Auto-stop" то, что нужно. Я же имел ввиду "полный" контроль над остановкой модуля. Ведь просто число неостановленых модулей не говорит ни о чем. А что если я хочу убедиться, что лишь определенный вложенный актор остановлен? Значит, нужно отслеживать это либо по конкретной ссылке на актор, либо по его имени (которое может храниться в самом акторе). И так далее...

А где будет вызываться функция "Read Autostop Nested Actor Count"?

В функции Handle Last Ack Core.

Главный актор будет остановлен

Ну раз он остановлен, то и следить некому.

не заботясь о порядке остановки

Данное поведение случиться только если "главный" актор получил сообщение об остановке и никак не обработал его (нет перегрузки сообщение Stop Msg). Тут вопрос сразу должен ли он был получить такое сообщение вообще. Автоостановка всех нэстедов это дефолтное поведение, никто не запрещает "правильно" их останавливать.

А что если я хочу убедиться, что лишь определенный вложенный актор остановлен?

Всё через тот же Handle Last Ack Core...

Aleksandr писал(а):

Главный актор будет остановлен

Ну раз он остановлен, то и следить некому.

Ну вот именно! Как же тогда удостовериться в том, что вложенный актор остановился так, как нужно; или восстановился вообще? Глюки фреймворков еще никто не отменял, поэтому просто полагаться в таком случае что само остановит актор - не всегда вариант.

Данное поведение случиться только если "главный" актор получил сообщение об остановке и никак не обработал его (нет перегрузки сообщение Stop Msg). Тут вопрос сразу должен ли он был получить такое сообщение вообще. Автоостановка всех нэстедов это дефолтное поведение, никто не запрещает "правильно" их останавливать.

Скорее всего, мы не понимаем друг друга.
Вопрос стоит не просто в том, что актор нужно остановить.
Вопрос в том, что вначале нужно удостовериться, что вложенные (nested) акторы остановлены, а уже потом останавливать главный актор.
В Вашем случае, при использовании флага "Auto-stop", такую проверку тоже можно делать, но если что-то пойдет не так, и главный актор остановится до того, как все его вложенные, Вы не увидите этого. Т.е. остановка вложенных акторов произойдет по-любому, но уже после остановки главного актора.
Вот почему я и говорю за Handle Last Ack; и вот о чем пример taras_33.
Ведь его пример - это не просто остановка вложенного актора. Это вначале проверка, что вложенный актор остановлен, а уже потом, после этого, можно закрывать главный актор. А это - уже не дублирование встроенного решения, т.к. встроенное решение должно в идеальном случае просто остановить вложенные акторы после того, как главный будет остановлен.
Надеюсь, что теперь разница ясна - или, по крайней мере, ясно почему я не согласен с просто флагом Auto-stop, и тем более Read Nested Actors Count.

Про дублирование о котором я говорил см. вложение.

Ну вот именно! Как же тогда удостовериться в том, что вложенный актор остановился так, как нужно; или восстановился вообще? Глюки фреймворков еще никто не отменял, поэтому просто полагаться в таком случае что само остановит актор - не всегда вариант.

Это не глюки фреймворка, а ошибки реализации. Почему вообще "основной" актор будет остановлен? Если он логгер и будет остановлен до остановки нэстедов, то какая разница чьё решение применять?

Вопрос в том, что вначале нужно удостовериться, что вложенные (nested) акторы остановлены, а уже потом останавливать главный актор.

Так и проверяйте в Handle Last Ack Core. Я уже 3ий раз об этом пишу.

Aleksandr писал(а):Так и проверяйте в Handle Last Ack Core. Я уже 3ий раз об этом пишу.

Так а я о чем толкую ? Я же за Handle Last Ack Core первым и написал.
Мое несогласие с Вами было в том, что проверка помощью Handle Last Ack Core - это то же самое, что и просто установить флаг "Auto-stop" = True. С этим я в корне не согласен, что и пытался объяснить.

Версия первая, использующая флаги.
Коротко: Launcher запускает главного, который в свою очередь запускает два Nested Actor. Через каждые 100mS главный посылает обоим "подчиненным" (как на русском обозвать Nested Actor?) сообщение с требованием обновить свои gauges, а так же устанавливает в false свои булевые индикаторы. При получении сообщения от главного, подчиненные Actors обновляют свои gauges и устанавливают булевые индикаторы главного в true. Этакий ACKnowledge (подверждения, мол ваше требование выполнено). (Что бы видеть мигание индикаторов я поставил небольшую задержку.)
При нажатии на кнопку, мы посылаем команду второму актеру "повиснуть" на 10 секунд.
А теперь главное. Нажали на кнопку, "повесили" актера и тут же нажали на крестик главной программы. Что произойдет? Правильно главная программа пошлет всем актерам стопы и закроется, не информируя юзера и не заботясь о последствиях. Но актер остался висеть, правда мы его повесили не смертельно и отвисев свои положеные 10 секунд он потом закроется. Такое поведение не всегда может устраивать. Хорошо что визуально мы видим "повесившегося", а если этот Актер повис намертво да еще выполняет что то критическое и его фронтальная панел не видна? Как показывает практика закон подлости работает исправно.

Поэтому предлагается версия номер два.
Здесь реализовано как раз то, о чем вы здесь спорили. В Handle Last Ack Core происходит проверка на отсуствие работающих актеров и только после этого закрывается главная программа.

P.S. Я рад что на портале появились люди обсуждающие AF

Kosist писал(а): А вообще, интересно сколько людей на портале сейчас использует AF в проектах? Или что-то подобное, типа JKI SMO?..

Сдаётся мне, что таких разработчиков не очень и много. Не, конечно же все об этом слышали, видели и смотрели примеры...но не так, чтоб перетаскивать проекты на Actor-ы. Не потому что Actor плохой, а скорее просто "а зачем?! Может это кому-то удобно, наглядно и т.д., но я по старой школе проекты делаю: дерево проекта, штук N папок, паттерн Produce-Consumer или машина состояний и вперёд. Этот подход покрывает подавляющее большинство решений задач по сбору данных и по автоматизации лично у меня. Как-то читал, что Actor полезен для ооооочень большого проекта, типа попроще будет между разработчиками передавать исходники и разработку вести. По своему опыту: и без Actor-ов всё норм, чесслово!
Если захочется экзотики, то может быть когда-нибудь и Actor гляну, но не более того ибо "а зачем?". Классическое ООП-программирование я и без этого знаю, захочу нормальной ООП софтины - я её на Java сделаю или на C++. А пока мне не охота хапнуть разочарований по части представления ООП в LabVIEW. Поэтому даже примеры не смотрю, но за предложенный вопрос для небольшого оффтопа - спасибо!