Про State machine

[JohnChaban]

Всем добрый день.
Собираю программу в state machine, заметил одну неприятную вещь. Например есть кнопка при нажатии на которое происходит действие и машина принимает состояние из которого была нажата кнопка.
И второй раз уже при нажатии на кнопку действие не происходит и программа зависает и на другие обьекты если нажимаешь действе не происходит.
Интересно почему?
Выкладываю кусочек кода если нужно выложу целую программу

[IvanLis]

Потому что у Вас SM не попадает в это состояние, а соответственно и Event структура не задействуется. Да и вообще, плохая идея использовать Event внутри условия, т.к. потом поставите еще одну Event, потом еще одну.... а нужно стараться все делать на одной.

По этому разносите на два цикла:
1. Обработка событий интерфейса + отправка команд в основной цикл.
2. Основной цикл, реализующий SM, которая обрабатывает все команды, в том числе и от интерфейса.

Посмотри пример: https://books.google.ru/books?id=NZELAg ... &q&f=false

[Blackman]

Где сама кнопка? Mechanical Action? В Plan есть значение 5?
Покажите другие переходы из этого состояния. (False и Plan).
Индикатор State переместите в Loop для индикации текущего состояния, а не только первого.

...плохая идея использовать Event внутри условия...

Event Structure в Idle State машины обычная практика. Естественно структура должна быть одна и только в этом состоянии. Это стандартный шаблон в старом StateChart Tools.

[dadreamer]

Event Structure в Idle State машины обычная практика. Естественно структура должна быть одна и только в этом состоянии. Это стандартный шаблон в старом StateChart Tools.

Если в иных состояниях была нажата кнопка, обрабатываемая в Event Structure, имеем FP Deadlock?
Ensure That Event Structures Handle Events whenever Events Occur

Avoid Using a Case Structure to Determine when an Event Structure Handles Events
Avoid placing an Event structure within a Case structure. For example, in the following block diagram, the Event structure is inside a Case structure and front panel locking is enabled for the Value Change case.

If you click the Get Value control, the front panel locks indefinitely. The False Boolean constant wired to the Case structure prevents the Event structure from handling the event inside the True case. Because panel locking is enabled for the event, the front panel waits for the Event structure, but dataflow prevents the Event structure from executing to handle the event. If you disable front panel locking for this application and click the Get Value control, the front panel becomes responsive and completes when you press the stop button. However, the numeric value does not increment because the Event structure still cannot execute to handle the event.

[Blackman]

Event Structure в Idle State машины обычная практика. Естественно структура должна быть одна и только в этом состоянии. Это стандартный шаблон в старом StateChart Tools.

Если в иных состояниях была нажата кнопка, обрабатываемая в Event Structure, имеем FP Deadlock?

Конкретный пример даст ответ. У меня никогда такого не было.)
P.S. Хороший пример. Но он мало похож на State Machine. Речь шла об Event Structure в Idle State машины.

[dadreamer]

Конкретный пример даст ответ. У меня никогда такого не было.)

У меня было, причём довольно странным образом. В одной программе эффект проявлялся, в другой нет, хотя архитектуры были абсолютно одинаковы. При снятии галки "Lock panel (defer processing of user actions) until the case for this event completes" кнопки можно было нажимать, но их нажатия не обрабатывались. И плюс FP не обновлялась, т.к. UI блокировался. А ещё бывало, что при запуске Main панель вообще не обновлялась, хотя программа исправно работала. Лечилось только перезапуском программы.

Всё-таки в Case лучше Event не вставлять. Есть более удачные шаблоны.

P.S. Хороший пример. Но он мало похож на State Machine. Речь шла об Event Structure в Idle State машины.

Это пример для размышлений. Согласно его логике, если программа застрянет в других стэйтах, и мы нажмём какие-то кнопки, то либо FP заблокируется, либо не получим реакцию на эти кнопки. И, естественно, при переходе в Idle события будут обработаны и FP разблокируется. Однако, такое поведение при работе с UI зачастую неприемлемо, как для рядового пользователя, так и для программиста (на мой взгляд).

[Blackman]

Так этот шаблон State Machine и препятствует возникновение длительной блокировки UI, так как переносит обработку из Event Structure в соответствующее состояние (Case).
Выполнение Event при этом носит "реактивный " характер: Event->Get Next State->Goto Next State.

[dadreamer]

Blackman, можете скинуть пример такого шаблона целиком? А то не понятно, какой StateChart Tools нужно ставить.

[Blackman]

Blackman, можете скинуть пример такого шаблона целиком? А то не понятно, какой StateChart Tools нужно ставить.

Только если посмотреть как было. Без старой версии, VI из шаблона редактировать не получится.
Ставить нужно соответствующий версии )

[dadreamer]

Blackman, можете скинуть пример такого шаблона целиком? А то не понятно, какой StateChart Tools нужно ставить.

Только если посмотреть как было. Без старой версии, VI из шаблона редактировать не получится.
Ставить нужно соответствующий версии )

Можно, если пересохранить до версии 6.1. Всё эти примочки из State Diagram Toolkit преобразуются в стандартные элементы .

Веселый шаблон. Сам бы до таких извращений не додумался. Думаю, не от хорошей жизни так раньше делали. А просто возможности не позволяли в полной мере использовать современные шаблоны. Ещё попался на глаза ранний External Node "Integer To Enum" с богатой историей, никогда прежде их не доводилось изучать. Интересная штука. Хоть и ненужная больше.

По сабжу: добавил отдельный кадр-состояние "Delay", куда программа переходит по нажатию кнопки. Как и оказалось, если там поставить задержку, то панель блокируется, покуда не истечёт время задержки, после чего снова начинает работать в штатном режиме. Поэтому надо делать так, как IvanLis написал:

По этому разносите на два цикла:
1. Обработка событий интерфейса + отправка команд в основной цикл.
2. Основной цикл, реализующий SM, которая обрабатывает все команды, в том числе и от интерфейса.

[IvanLis]

Поэтому надо делать так:

По этому разносите на два цикла:
1. Обработка событий интерфейса + отправка команд в основной цикл.
2. Основной цикл, реализующий SM, которая обрабатывает все команды, в том числе и от интерфейса.

Я к этому тоже долго шел.
Веду проект в течении нескольких лет, который начинался с простой линейной структуры.
Потом дорос до State Machine, крутящейся в одном цикле, но т.к. были участки кода, требующие значительного времени для расчетов. Пришлось разбивать подобные участки на куски, что бы была возможность прервать расчет в произвольный момент времени, а не дожидаться окончания. Соответственно родился отдельный цикл обработки событий интерфейса.
Сейчас SM состоит из 57 кадров. Приходится обрабатывать UI, вести лог, принимать команды посредством Jabber и Yandex.Disk, обновлять конфиг. файлы, и т.д. и т.п.

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

[Blackman]

JKI State Machine
The easiest way to create powerful, maintainable VIs in LabVIEW™
The JKI State Machine™ for LabVIEW™ is an easy-to-use yet powerful state machine template.
It is the very same template that is used by the JKI team, nearly every day, and is the result of years of refinement by our team of LabVIEW™ experts.
http://jki.net/state-machine
Походу пора им VIPM переделывать)

[dadreamer]

Походу пора им VIPM переделывать)

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

[Blackman]

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

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

[dadreamer]

1. Да это нормально, когда надо, блокировать панель и не давать пользователю "щелкать" или "ползать" по ней. Логику действий пользователя в моем приложении - законы - устанавливаю я. Пользователь или соглашается с ними, подписывая лицензионное соглашение и получает программу, или не соглашается и не подписывает лицензионное соглашение и все остаются при своих.

Когда я сам блокирую панель или её элементы с помощью Property / Invoke Nodes и т.п. - вот это нормально. А когда панель блокируется в из-за неправильной архитектуры - это совсем не норма. Вот, английским же языком написано:

Так что, наверное, стоит всё-таки делать, как правильно, а не использовать критическое поведение, подгоняя под него код и прописывая в своих TOS.

2. Нажатие пользователем кнопки "Стоп" "безо всяких задержек" не означает, что программа должна быть тут же остановлена см. п.1. Так как во многих случаях пользователь просто не знает (а не читая справку и знать не хочет) логику работы приложения и пытается подавать команды, которые не могут быть выполнены "в любую секунду ". Это не зависит от архитектуры программы.

В большинстве случаев должна, и во всех уважающих себя продуктах это так и работает. Можно опять же привести избитый пример с установкой на ответственном объекте, которая, если не будет остановлена вовремя, то может произойти авария. А можно взять тот же , который останавливает и закрывает проекты/ сразу же, а не ждёт какие-то там 10-20-30 секунд во внутренних циклах. Можно и с другой стороны на это взглянуть. Вы, например, поставили новый продукт и его тестируете. Запустили и захотели остановить. А он не останавливается, да ещё и подвесился намертво. Что вы скажете о такой программе? И о её программистах?

3. Об остальных элементах UI, как бы и говорить нечего см.п.1.

Ну, допустим, не "Стоп" будем нажимать, а по вкладкам Tab Control'а ползать или графики крутить. Тоже не сможем? Да, из-за заблокированной панели.

4. А по мне так нормально. Криминала не замечал)

http://labviewportal.org/viewtopic.php?p=63298#p63298
Да и скептицизма хватает в плане того, что VIPM - "чёрный ящик", да ещё и сторонний продукт. Хотя последние версии более-менее стабильно работают, а вот на 2011 и ранних всякое бывало.