Про State machine

[Vitekkz88]

Полностью согласен с dadreamer. Не буду повторяться, писал о том же самом.

[Blackman]

1. Какое отношение имеет архитектура к ошибке программера, который например в VI http://labviewportal.org/download/file.php?id=22864 при добавлении состояния, выполнение которого требует существенных временных ресурсов, забыл заблокировать панель и никак не проинформировал пользователя о том, что программа будет занята, например установив курсор Busy.
2. Избегайте не является синонимом слова Нельзя. Этот пример слабый аргумент о "неправильности" архитектуры
SB State Machine. И когда это шаблон, который является официальным начиная с не помню какой версии, стал "неправильным"?
3. никогда не закрывает проекты сразу. Сначала она спросит про работающие VI и потребует подтверждения на их остановку, потом предложит сохранить не сохраненные изменения и только после очередного подтверждения начнет закрывать проект.
4. Про ответственные объекты и аварии: их было бы значительно меньше, если бы не так называемый "человеческий фактор")
5. VIPM - не "черный ящик". Можно легко получить представление о том как он сделан, посмотрев открытый код его предка "OpenG Commander"

[dadreamer]

1. Какое отношение имеет архитектура к ошибке программера, который например в VI download/file.php?id=22864 при добавлении состояния, выполнение которого требует существенных временных ресурсов, забыл заблокировать панель и никак не проинформировал пользователя о том, что программа будет занята, например установив курсор Busy.

Такое, что при более удачной архитектуре не потребовалось бы блокировать панель, выводить диалоговые окна, устанавливать курсор в Busy и т.д. Давно 21-й век на дворе, и современные машины спокойно могут обрабатывать события панели и параллельно вести вычисления / сбор данных. Нет необходимости в однопоточном State Machine, который работает с задержками.

2. Избегайте не является синонимом слова Нельзя. Этот пример слабый аргумент о "неправильности" архитектуры

Я и на форумах NI видел подобные советы. Извините, сейчас нет времени выискивать те посты. Раз NI пишет в официальном хэлпе, что нужно избегать, то лучше избегать. Так же, как и с локальными переменными. Иначе возникнут (и часто возникают) проблемы, что мы и видим.

И когда это шаблон, который является официальным начиная с не помню какой версии, стал "неправильным"?

Proof от NI?

3. никогда не закрывает проекты сразу. Сначала она спросит про работающие VI и потребует подтверждения на их остановку, потом предложит сохранить не сохраненные изменения и только после очередного подтверждения начнет закрывать проект.

Причём тут диалоговые окна... Речь о том, что в коде нет "левых" зависаний и блокировок при остановке/закрытии . И это только пример одной программы. Возьмите любую другую среду, MS Visual Studio, например. Или, например, "писалку" оптических дисков. Хотя диск прожигается, мы всегда можем нажать "Стоп" и остановить прожиг, причём прога не зависнет во внутренних циклах. Другое дело, что диск испортим таким образом.

4. Про ответственные объекты и аварии: их было бы значительно меньше, если бы не так называемый "человеческий фактор")

От этого никуда не деться, везде он есть.

5. VIPM - не "черный ящик". Можно легко получить представление о том как он сделан, посмотрев открытый код его предка "OpenG Commander"

Так, наверное, много изменили с того времени. Часть функций вообще платная. Но сейчас мне не особо интересно копаться в VIPM'е, поскольку он лишь пример неверной архитектуры (если JKI не поменяли её в последних версиях).

[Blackman]

..Нет необходимости в однопоточном State Machine, который работает с задержками

Не понял о каких конкретно задержках идет речь. А утверждать об однопоточносьти SB State Machine большое заблуждение).
Все приложение строится по модульному принципу. Как правило один модуль - один Loop. Каждый модуль выполняет определенные функции. Приложение собирается из модулей в зависимости от требуемого функционала, как из кубиков. Модули запускаются асинхронно.

Но сейчас мне не особо интересно копаться в VIPM'е, поскольку он лишь пример неверной архитектуры (если JKI не поменяли её в последних версиях).

Ага поменяли) Перешли от классической Producer-Consumer (2 Loop) к модульной на базе SB State Machine.

[AndreyDmitriev]

Ух, какая жаркая дискуссия...

Ладно, поехали.
Во-первых, NI хотя и рекомендует не ставить Event структуру в case - это, скорее, перестраховка для новичков, которые не будут понимать, отчего передняя панель перестаёт реагировать на внешнее раздражение. Формально ничего плохого в этом нет. Что не рекомендуется - так это ставить две Event структуры на блок диаграмму, а в case - почему бы и нет.

Пруф - идём в официальные примеры NI и ищем там State Machine Fundamentals.vi. Видим прекрасное:



Технически надо понимать, что если мы выходим из Event структуры, либо тормозим её выполнение на досточно долгий промежуток времени, то передняя панель не будет отвечать на запросы по определению, что, безусловно, не есть хорошо (можете, кстати, поэкспериментировать с опцией Lock panel (defer processing of user actions) until the event case completes, но это чуть другая история). По большому счёту тут есть два подхода - либо разрешить пользователю делать какие-либо действия парраллельно, либо нет. Хорошие программы должны быть отзывчивы, но это не всегда возможно. Даже если взять LabVIEW - в процессе сборки приложения либо инсталлятора вы не можете продолжать работать, и изменять код, для этого выводится модальное окно с прогресс индикатором. В случае, если невозможность немедленного останова вызовет возможную поломку оборудования или создаст угрозу для персонала, то в этом случае применяются совсем другие решения (либо чисто аппаратные, либо так называемые безопасные ПЛК).

Ну вот пример, допустим у нас есть некий код, который выполняется несколько секунд, когда пользователь нажимает на кнопку:



Нет ничего плохого ставить его прямо в Event структуру, но пользователя надо уведомить, о том, что идёт выполнение - помимо прогресс индикатора надо будет либо заблокировать кнопки, на которые программа не будет реагировать, либо выставить Set Busy - тогда курсор превратится в песочные часы:



Теперь, предположим, у нас довольно много кода, и его выполнение инициируется из разных мест (ну, скажем и кнопка и меню) тогда имеет смысл воспользоваться паттерном State Machine, положив Event структуру в Idle, а код - в отдельный кейс (см. самый первый скриншот).
Технически можно обойтись и без кейса, сделав саму Event структуру частью State Machine, и сгенерировав Event программно:



Однако сути это не поменяет - мы всё равно будем тормозить Event Структуру и уведомить пользователя всё равно придётся.
Можно даже вынести Event структуру из case структуры и поставить конечный автомат рядышком - тогда While цикл станет частью Idle:



Но и тут мы покидаем Event структуру, и на это время она перестанет отвечать на внешнее раздражение.

Всё, что, написано выше - совершенно легитимные конструкции, какую из них использовать - зависит от предпочтений программиста и возникающих потребностей. Если код предельно простой, то обходятся просто Event структурой, при усложнении заводится case структура.

Теперь пусть мы разрешим пользователю делать что-либо параллельно с исполнением. Тут у нас включается другой паттерн (ищем в примерах Queued Message Handler Fundamentals.vi):



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

Но за усложение, как вы понимаете, придётся заплатить свою цену - если пользователь нащёлкает по кнопке несколько раз, то и в очередь будут добавлены несколько элементов, которые будут последовательно обрабатываться во втором цикле. Это может быть вовсе не то, что нужно. Опять же выход из такой программы "досрочно" возможен, но придётся набросать некоторое количество кода для реализации логики выхода. Это более гибкий паттерн, а вот использовать его или нет - это зависит от требований. Я не сторонник "раннего усложнения". Если код может быть простым - он должен быть простым. С опытом (после пары-тройки масштабных переделок) просто придёт понимание того, где нужно изначально сделать сложную и гибкую архитектуру, а где - нет. Попытка сразу сделать "сложно" без опыта и без особой необходимости как правило закончится неудачей. Где-то так.

[Vitekkz88]

AndreyDmitriev писал(а):Даже если взять LabVIEW - в процессе сборки приложения либо инсталлятора вы не можете продолжать работать, и изменять код, для этого выводится модальное окно с прогресс индикатором.

И что, в процессе сборки инсталлятора нельзя нажать кнопку "Cancel"? Там же в модальном окне кнопочки есть. И LabVIEW их не блокирует. Разработчик может прервать процесс в любой момент. Глупо было бы, если бы инсталятор собирался так: нажали Build и всё, ждём до потери пульса пока соберется без вариантов отмены. Затем правим код, начинаем новую сборку и где-то на середине процесса вспоминаем, что надо добавить еще пару модулей...а отмену не нажать, надо сидеть и ждать.
Про Producer-Consumer:

AndreyDmitriev писал(а):за усложение, как вы понимаете, придётся заплатить свою цену - если пользователь нащёлкает по кнопке несколько раз, то и в очередь будут добавлены несколько элементов, которые будут последовательно обрабатываться во втором цикле.

Это легко разруливается очищением очереди. Я не могу говорить за всех, но 90% моих пользователей желают примерно следующего:
1. Нажали кнопку, начался некий процесс. В этот момент надо остальные кнопки заблокировать и сделать серым цветом(свойство disable and grayed), чтоб лишнего не нажимать и видеть явно, что заблокировано. Либо делать всё доступным, но чтоб нажатия кнопок для запуска других процессов не срабатывали(то есть они нажимаются, моргают, но эффекта нет и не ожидается после завершения текущего процесса) !!!НО!!! пользователь должен иметь доступ к встроенной справке, к переключению по вкладкам, просмотру определенных данных, доступ к меню приложения и т.д.
2.Чтоб одна кнопка могла запускать один процесс, а если нажали вторую, то текущий прерывается и запускается новый процесс. Как только он закончился, пусть запускается предыдущий(или не запускается).
3.Останов в любой момент.
Именно поэтому я использую в своих приложениях Producer-Consumer, а останов всего приложения выполняю по логическому "или" кластера ошибки+отдельный уведомитель.
А сидеть в одном процессе без возможности элементарного останова с "повешаными" GUI - ИМХО не профессионально выглядит, хотя и имеет право на жизнь. Хоть часики там нарисуйте, хоть кружок. Ощущение "повисшего" софта никому не интересны. Приведите примеры, где это реально может быть полезным(в плоть до блокировки закрытия приложения)?

[AndreyDmitriev]

Приведите примеры, где это реально может быть полезным(в плоть до блокировки закрытия приложения)?

Это как правило небольшие диалоги в составе большой программы, либо простенькие утилиты, отрабатывающие за сравнительно короткое время. Ну, вот к примеру, у меня есть утилита, позволяющая вручную выбрать и реконструировать изображение из компьютерной томогорафии. Типичное ремя реконструкции - максимум пять - семь секунд, а сама утилита с точки зрения пользователя проста как пять копеек - и тут мне не нужно заморачиваться с Producer-Consumer, достаточно выкатить песочные часы. Или, скажем простой трёхкнопочный диалог собственного изготовления с несколькими полями ввода - ну не буду же я в него вставлять Producer-Consumer? Если бы время работы в "занятом" режиме было сильно больше (как, к примеру в упоминавшемся диалоге сборки), то я безусловно добавлю кнопку отмены (хотя и в этом случае я всё ещё теоретически могу обойтись без Producer-Consumer). При дальнейшем усложнении, если я захочу дать возможность пользователю делать множественные действия параллельно, я уже не обойдусь без этого паттерна. Ещё перед началом работы над каждым проектом, либо его частью, я знаю - понадобится ли мне тот или иной паттерн или нет. В тех редких случаях, когда дальнейшее развитие продукта неоднозначно, туда сразу закладываются определённые возможности расширения, но и тут выбирается "золотая середина" между изначальной сложностью архитектуры и теоретической возможностью дальнейших переделок если изначально архитекура оказалась недостаточно гибкая. Я не призываю отказаться от Producer-Consumer, я лишь призываю не использовать его там, где в этом нет необходимости. Второй постулат - использовать Event структуру внутри case структуры в составе простого конечного автомата без привлечения Producer-Consumer - вполне допустимо, я как раз с этого примера от NI предыдущий пост и начал.

[Vitekkz88]

AndreyDmitriev, я согласен на счет диалогов. Там можно вообще не использовать event-структуру и машина состояний будет там так же избыточна. Утилиты - тут уж хозяин-барин. Но это действительно либо примитивные либо маленькие фрагменты программы. Тут же речь о более глобальном, насколько я понял. Вон, для Blackman считается нормой, если софт по нажатию на кнопку останова не будет останавливается сразу, а "вешать" интерфейс - сугубо личная прерогатива разработчика. Как так то!?
Целиком строить приложение по архитектуре State Machine Fundamentals.vi. - это грабли.
IvanLis пояснил, к чему это приводит в долгосрочной перспективе. И я сам сталкивался с такой ситуацией.

[AndreyDmitriev]

AndreyDmitriev, я согласен на счет диалогов. Там можно вообще не использовать event-структуру и машина состояний будет там так же избыточна. Утилиты - тут уж хозяин-барин. Но это действительно либо примитивные либо маленькие фрагменты программы. Тут же речь о более глобальном, насколько я понял. Вон, для Blackman считается нормой, если софт по нажатию на кнопку останова не будет останавливается сразу, а "вешать" интерфейс - сугубо личная прерогатива разработчика. Как так то!?
Целиком строить приложение по архитектуре State Machine Fundamentals.vi. - это грабли.
IvanLis пояснил, к чему это приводит в долгосрочной перспективе. И я сам сталкивался с такой ситуацией.

Ну я просто за последовательные шаги в программировании. Это значит, что программист вначале изучает Event структуру, и затем переходит к использованию конечных автоматов, Event структур в их составе (и тут уже вопросов не возникает, почему UI не отвечает) и потихоньку к Producer-Consumer, ну и дальше к сложным системам. Попытка сделать сразу что-то сложное методом "тыка" обычно кончается плачевно - либо сложная программа строится на примитивным элементах и обрастает граблями, либо используются сложные паттерны без понимания принципов их работы - и то и другое превращает работу в ад.

[Blackman]

Vitekkz88 писал:
Вон, для Blackman считается нормой, если софт по нажатию на кнопку останова не будет останавливаться сразу, а "вешать" интерфейс...

И где это Blackman так считает и призывает "вешать" интерфейс?
Видимо у нас раз представления о том, как безопасно останавливать приложения. Вы, как я понял, предпочитаете методом VI: Abort)
5 копеек по шаблонам:
Вам нравится создавать статические Loop-ы на BD одного VI, а я привык создавать их динамически из набора готовых Loop-в (модулей).

[Vitekkz88]

Blackman не призывает, а считает нормой - это во-первых:

Ну, а по вашему это нормально, что панель блокируется и не отвечает на действия пользователя? Лично мне такой State Machine не нужен. Как минимум, программа в любую секунду должна иметь возможность остановки кнопкой "Стоп" безо всяких задержек. Не говоря о работе остальных UI элементов.
А VIPM на мой взгляд временами работает весьма странно. Да и у многих он глючит, по отзывам.

1. Да это нормально, когда надо, блокировать панель и не давать пользователю "щелкать" или "ползать" по ней. Логику действий пользователя в моем приложении - законы - устанавливаю я. Пользователь или соглашается с ними, подписывая лицензионное соглашение и получает программу, или не соглашается и не подписывает лицензионное соглашение и все остаются при своих.
2. Нажатие пользователем кнопки "Стоп" "безо всяких задержек" не означает, что программа должна быть тут же остановлена см. п.1. Так как во многих случаях пользователь просто не знает (а не читая справку и знать не хочет) логику работы приложения и пытается подавать команды, которые не могут быть выполнены "в любую секунду ". Это не зависит от архитектуры программы.
3. Об остальных элементах UI, как бы и говорить нечего см.п.1.
4. А по мне так нормально. Криминала не замечал)
5. Я отзывы не читал, но из-за солидарности полностью их поддерживаю)

Во-вторых:

Blackman писал(а):Вы, как я понял, предпочитаете методом VI: Abort

Поняли не правильно. Выше написано:

Vitekkz88 писал(а):я использую в своих приложениях Producer-Consumer, а останов всего приложения выполняю по логическому "или" кластера ошибки+отдельный уведомитель.

Или в вашем понимании VI:Abort и останов по логическому "или" кластера ошибки+отдельный уведомитель для останова это одно и тоже?

[AndreyDmitriev]

Blackman не призывает, а считает нормой - это во-первых:

Ну, а по вашему это нормально, что панель блокируется и не отвечает на действия пользователя? Лично мне такой State Machine не нужен. Как минимум, программа в любую секунду должна иметь возможность остановки кнопкой "Стоп" безо всяких задержек. Не говоря о работе остальных UI элементов...

Мы тут мешаем в одну кучу пользовательский интерфейс (или User eXperience, как щас модно говорить) с точки зрения пользователя и реализацию с точки зрения программиста. Это две разные вещи. Конечному пользователю глубоко фиолетово как оно там внутри устроено. Программисту же потребности пользователя небезраличны (я встречал программистов, кторые программируют так, как удобно им самим, но не так, как удобно пользователю).

Блокировка панели при работе с железками - это нормально, если это оправдано.

Ну вот как пример навскидку - слайдерами производится перемещение манипулятора по осям и на время перемещения контролы блокируются:
_eMbxZC-_cc

Мгновенная остановка программы тоже не всегда возможна. Ну вот у меня есть рентгеновская система - при останове программы (да и всей системы) мне нужно выключить высокое напряжение на трубке, выгрузить деталь, если она загружена, переместить манипулятор в исходное положение, и т.д. Ну программа при нажатии кнопки "Стоп" так и пишет - подождите, я выключаю высокое, перемещаю манипулятор, и т.д. Это совершенно нормально, если программа чем-то занята и сообщает пользователю об этом нормальным человеческим языком.

[dadreamer]

Не понял о каких конкретно задержках идет речь.

Задержки, подобные той, что в примере Process Template (chan).vi, когда в отдельном стэйте выполняется времязатратный код, а Event-структура не в состоянии обработать события UI.

А утверждать об однопоточносьти SB State Machine большое заблуждение).

В том шаблоне, что вы показали, я нигде не увидел каких-либо параллельных циклов или чего-то, похожего на Queued Message Handler. Цикл State Machine один, и да, это один поток.

Ага поменяли) Перешли от классической Producer-Consumer (2 Loop) к модульной на базе SB State Machine.

Ну, тогда это их решение, и им решать проблемы, которые способен породить подобный подход. А вы участвуете в работе над VIPM? Откуда у вас исходники? Или это всё тот же OpenG Commander?

AndreyDmitriev, я использую в основном шаблон "Queued Message Handler" и считаю его намного удобнее остальных конструкций конечных автоматов. И, конечно, основным плюсом здесь является отзывчивость и независимость UI от остального кода. А шаблон из "State Machine Fundamentals" неудачен даже для новичков, которые, столкнувшись с вышеописанными "граблями" такого подхода, всё-таки переходят на шаблон "Queued Message Handler" (и вот тому подтверждение). Вот вы пишете, что ничего плохого нет, когда эвент стоит в кейс-структуре. Ну, чёрт с ним, с GUI - панель заблокируется, пользователь потерпит-подождёт секунд 10, потом сможет дальше кнопки нажимать. А если в том же эвенте у нас происходит обработка событий из других циклов или DLL? Известно, что при запуске программы очередь событий активна сразу же и начинает набирать события. Если обработчик событий недоступен, то события накапливаются в очереди. Таким образом, затянув по времени некоторый state, мы можем потерять важные события из-за переполнения очереди. Вряд ли такой вариант вообще допустим, когда идёт речь о работе с ответственными устройствами. Так что лучше сразу выбрать "Queued Message Handler" и обезопасить себя в будущем. Тем более что там нет ничего экстра-сложного, с чем не смог бы разобраться программист. Циклы, эвенты, очередь - всё. Элементарно. Ну, и опять же, с другой стороны: в традиционных текстовых языках вряд ли кто-то станет выполнять в одном потоке и работу с GUI, и работу с устройствами, и мат. вычисления и т.д. Стандартно всегда разносят по потокам, иначе возникнут те же неприятности: при паузе на каком-либо участке кода программа подвешивается и не реагирует на элементы формы. Так что шаблон "State Machine Fundamentals" крайне неудачный и NI стоило бы его заменить на простой шаблон, где нет Event Structure, а лишь цикл, кейс и сдвиговый регистр.

Мгновенная остановка программы тоже не всегда возможна. Ну вот у меня есть рентгеновская система - при останове программы (да и всей системы) мне нужно выключить высокое напряжение на трубке, выгрузить деталь, если она загружена, переместить манипулятор в исходное положение, и т.д. Ну программа при нажатии кнопки "Стоп" так и пишет - подождите, я выключаю высокое, перемещаю манипулятор, и т.д. Это совершенно нормально, если программа чем-то занята и сообщает пользователю об этом нормальным человеческим языком.

Когда такая блокировка контролируема, это одно дело, а когда она происходит спонтанно из-за особенностей работы Event Structure и LabVIEW - это другое. Я ничего не имею против этапов финализации и в любой более-менее сложной программе они обязательно будут. Вполне нормально отображать диалоги о некоторых операциях и т.п. А вот подвисания - это что-то ненормальное, на мой взгляд. Уж скоро квантовый компьютер изобретут, а у нас всё ещё программа виснет... Это, извините, нонсенс. Нужно избавлять от такого.

[JohnChaban]

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

[AndreyDmitriev]

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

Так происходит оттого, что вы покидаете Event структуру переходя в другое состояние State Machine, и всё время, пока вы находитесь в другом состоянии интерфейс откликаться не будет.

Ну вот смотрите, то что происходит у вас:



Этот код будет вызывать пятисекундное "зависание" интерфейса при нажатии кнопки.

Чтобы этого не происходило, код модифицируется вот так:



Теперь мы отправляем сообщение второму циклу и тут же возвращаемся в Event структуру - интерфейс не зависает.
Остальная логика (ну там выход, множественные нажатия на кнопку и т.д.) добавляется по вкусу.