LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

State Machines are great...thank you all

Solved!
Go to solution

DianeS wrote:

A queued state machine is your friend

It's not just a fad or a trend

A typedef'd enum

Leaves plenty of room

For changes you won't have to mend!

 

I also like type-defined clusters

A variant gives it some lustre

You can pass anything

Array, number, or string

And your next state will always pass muster!

 

d

 

 

 

 


Smiley Very Happy

PaulG.

LabVIEW versions 5.0 - 2018

“All programmers are optimists”
― Frederick P. Brooks Jr.
0 Kudos
Message 11 of 25
(978 Views)

Darin K. wrote:

Now young Grasshopper it is time to take it to the next level.  With LV scripting you can write a state machine to write your state machine for you.

 

Have a look in the LAVA CR.

 

Felix 

0 Kudos
Message 12 of 25
(934 Views)

Glad you found the power and beauty of state machines.

And yes, some state machines will even brew your coffee...

______________________________________________________________________
0 Kudos
Message 13 of 25
(926 Views)

Although I like techno-poetry I feel obligated to post a disclaimer about QSMs.

 

QSMs do not scale well because

 

1) they are impossible to diagram

 

2) Testing becomes a night-mare since the order in which the states execute can change depending on other things the QSM is trying to do at or about the same time (a chaotic system).

 

I wrote about this more in this thread on LAVA.

 

I am not telling everyone that they should re-write the QSM as plain SMs.

 

What I will say is "If your customer gets frutrated with YOU and hire me, I'm going to re-write it as a SM (or at least fight for it Smiley Wink ).

 

Ben

Message 14 of 25
(915 Views)

to: DianS

 

You speak of luster in cluster

   I need some of that soon

Could you show me the way

To do it today

If so,

I'll finish by noon.

 

Hummer1

 

(variant in a cluster type def and how to use it....thanks)

0 Kudos
Message 15 of 25
(905 Views)

Ben wrote:

Although I like techno-poetry I feel obligated to post a disclaimer about QSMs.

 

QSMs do not scale well because

 

1) they are impossible to diagram

 

2) Testing becomes a night-mare since the order in which the states execute can change depending on other things the QSM is trying to do at or about the same time (a chaotic system).

 

I wrote about this more in this thread on LAVA.

 

I am not telling everyone that they should re-write the QSM as plain SMs.

 

What I will say is "If your customer gets frutrated with YOU and hire me, I'm going to re-write it as a SM (or at least fight for it Smiley Wink ).

 

Ben


I completely understand what you are saying Ben and in principal I agree with you. However at the same time I do like the power that a QSM can provide when used properly. In most of my state machines there are states, or more technically correct, tasks that are common and simply need to be executed. They can be invoked at any time and the state/task has no way of knowing what should come next. For these types of tasks the QSM is very useful. States/tasks that fall into this category are things such as error processing, data logging, execution control (stop/exit) or display updates. I am sure with some additional effort these items could be written as subVIs which you would simply invoke within the state machine. It would work for some things but the stop or exit conditions are handled very nicely in a queued state machine. As with most complex systems they can designed well or very poorly. As long as you know what the issues and pitfalls of a given architecture are you can design your system to utlilize the power of a given construct and minimize the effects of the pitfalls.



Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
Message 16 of 25
(901 Views)

Mark Yedinak wrote:

Ben wrote:

Although I like techno-poetry I feel obligated to post a disclaimer about QSMs.

 

QSMs do not scale well because

 

1) they are impossible to diagram

 

2) Testing becomes a night-mare since the order in which the states execute can change depending on other things the QSM is trying to do at or about the same time (a chaotic system).

 

I wrote about this more in this thread on LAVA.

 

I am not telling everyone that they should re-write the QSM as plain SMs.

 

What I will say is "If your customer gets frutrated with YOU and hire me, I'm going to re-write it as a SM (or at least fight for it Smiley Wink ).

 

Ben


I completely understand what you are saying Ben and in principal I agree with you. However at the same time I do like the power that a QSM can provide when used properly. In most of my state machines there are states, or more technically correct, tasks that are common and simply need to be executed. They can be invoked at any time and the state/task has no way of knowing what should come next. For these types of tasks the QSM is very useful. States/tasks that fall into this category are things such as error processing, data logging, execution control (stop/exit) or display updates. I am sure with some additional effort these items could be written as subVIs which you would simply invoke within the state machine. It would work for some things but the stop or exit conditions are handled very nicely in a queued state machine. As with most complex systems they can designed well or very poorly. As long as you know what the issues and pitfalls of a given architecture are you can design your system to utlilize the power of a given construct and minimize the effects of the pitfalls.


Hi Mark,

 

The last thing I want to do is get into another "big end of the egg or small end?" argument. My intent is to ensure our more inexperienced readers know about the limitations before they start down a path that could be rocky. 

 

That seems to be one of the biggest pit-falls that lead to QSM trouble (using states where a sub-VI should be used). I probaly sound like an anti-QSm evangelist, and maybe I am. At one time NI was teaching the QSM as if it was the the "Cat's meow" in the earliest LV Advanced course. One of my customers swallowed that line hook-line-and-sinker" and developed a nightmare app (The case selection pop-up fills the screen and has a sroll bar to access many more!) that his buisness uses to bill his customers. Since he reserves the right to jump and change the code himself anytime he wants (he is paying by the hour and is aware that the QSM slows down development and testing) we have to keep it as a QSM. So we make good money off the QSM, but I would really love to deliver more "bang for the buck" by getting rid of his QSM and turn it into something more modular.

 

I'll bow out now since I have said what I felt needed to be said.

 

Smiley Happy

 

Ben

 

 

Message 17 of 25
(892 Views)

Ben wrote:

Hi Mark,

 

The last thing I want to do is get into another "big end of the egg or small end?" argument. My intent is to ensure our more inexperienced readers know about the limitations before they start down a path that could be rocky. 

 

That seems to be one of the biggest pitfalls that lead to QSM trouble (using states where a sub-VI should be used). I probaly sound like an anti-QSm evangelist, and maybe I am. At one time NI was teaching the QSM as if it was the the "Cat's meow" in the earliest LV Advanced course. One of my customers swallowed that line hook-line-and-sinker" and developed a nightmare app (The case selection pop-up fills the screen and has a sroll bar to access many more!) that his buisness uses to bill his customers. Since he reserves the right to jump and change the code himself anytime he wants (he is paying by the hour and is aware that the QSM slows down development and testing) we have to keep it as a QSM. So we make good money off the QSM, but I would really love to deliver more "bang for the buck" by getting rid of his QSM and turn it into something more modular.

 

I'll bow out now since I have said what I felt needed to be said.

 

Smiley Happy

 

Ben

 

 


I don't want to start a long debate either and that was not my intent. Along the lines of what you were saying though is that any state machine, whether it is a QSM or a standard state machine, that has more than a couple of dozen states (and that is extremely large in my opinion) needs to be refactored and simplified. The case you mention clearly illustrates how very large entities become unmanageable simply because you cannot understand the whole thing. I'm not saying that large systems don't exist, we all know they do, but what I am saying is that any view into the system should be relatively easy to see as a whole. For extremely complex state machines the upper view should contain the high level states of the system. I am sure that the example you sighted could have easily been refactored to use state machines within state machines. At the higher levels the sub-state machines (is there such a word) would encapsulate the complexity of the sub-state machines so at that view the transitions are understandable and clear. Yes, you will not see that whole thing but it will be much easier to understand the system. No one can ever really grasp the entirety of state machine, even if it is well designed. If you put it on paper and you need a billboard to show the whole thing it needs to be refactored and simplified. This is all part of making the system readable and easy to understand.

 



Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
Message 18 of 25
(879 Views)

I remember when I was in Grad School and learning about software design methodologies (in the early days).  We discussed how to define State Machines and how to conceptualize the whole thing.  The idea was to have an overall view of the system and break it down into its functional components, where State Machines had to be orginized in such a way that parts of it had to be represented on a single 8-1/2 x 11 sheet. 

 

We then compared different software design methodologies, where the design could be read like a book and be implemented in the same fashion.  The idea was that you could give (a) sheet(s) (or chapters) to different developers and they could develop their code to those requirements.  The software could then be pieced together with minimal integration issues.

 

From what I read, I think you are essentially saying the same thing, that QSM's are okay as long as they are not abused.  With that in mind, anything can be abused in software, and it is the abuse which is wrong, not the methodology.  

 

I understand Ben's concerns about QSMs, as they are similar to mine with Local Variables.  Well... I thought I was more of an anti_locals Evangelist than Ben being an anti-QSM.  

 

As for where I stand, I do use QSM's quite often.  Not necessarily in the same fashion as the code examples that I post in this forum, but I do not try to stay away from QSMs.  I do make a decision on which architecture is best for the application.  If it's a SM, so be it.  If it's a QSM, then so be it also.  And it could be neither, as it depends on the requirements for the code.

 

My point is that as long as the code is well designed, using QSMs should not be a problem.  And to realize that they are not the solution to everything.  And yes, we often see examples of abuse where the timeout event is abused

 

R

______________________________________________________________________
Message 19 of 25
(863 Views)
Yes, I think we are both saying the same thing. A good design is a good design regardless of the types of architectures used. Given a single problem there will always be multiple ways of solving it and implementing the solution. As long as good design methodologies are used the system will be easy to understand and maintain.


Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
Message 20 of 25
(858 Views)