Can simple state machine replace all queue state machines? Noob dont know what issues are involved.

[sunflower2772]

Is queue state machine absolutely necessary? 

I am a disciple of KISS:  as long as the application WORKS and the code is SIMPLE, I dont really care about the rest.  I am also noobish to Labview structures for bigger programs.  I read all this comments about the queue state machine:

"All CLD exams can be completed with a simple state machine architecture,"

 "If you do not need it do not use it"

"I am not a fan of the queued state machine. I prefer the simple state machine."

Can all applications be implemented with the simple state machine without needing the queue state machine? What kind of important issues are involved if I dont use the queue state machine at all? I don't care if the code looks a bit ugly as long as the application works. 

I am also thinking of going for CLD exam and would like to stick to one simple structure until I can do it in my sleep, hence another reason for the question above.

Thanks. 

[altenbach]

Simpler is always better. A queued state machine is just one of many possible architectures. Initially it is only important to know that it exists. You should at least have some casual knowledge of what it is, so can can recognize the need in the future, once your programs become a little bit more complex. 😉

A queued state machine is a good solution once the program gets more complex and some processes need to execute with their own timing or take long to complete. A queued state machine will keep the user interface responsive, even if other things run in parallel.

You are right. If there are no serious computations or external hardware involved, a simple one-loop state machine is often all that's needed.

[Ben]

Quoting Dr Grey from here

---

When constructing these types of architectures it is important to remember the difference between a state machine and a task handler and not conflate the two in your design.  What most people refer to as a queued state machine is actually a task handler.  Task handlers are highly useful for things such as UI interactions where you do not want to lose a task.  State machines are useful when your process has several configurations it could be in (e.g. stopped, running, paused, etc.).  I agree with the previous posters that state machines should not be queued.  Task handlers should be queued.  Yes, you can, and probably should, have both is a large, GUI-based program.

---

 still cringe every time I open a BD and find VI's on the front and back of the cases (construct used for queued state machines that use some type of stack structure to keep track of what states should be executued, queue, array, or for those machine language programmers "the stack").

The big factor that determines if another loop s gets implemented (other than the GUI) is "how long?" since most people want an response to their mouse gestures in about 5-10 seconds before they attempt to abort the app as hung.

Ben

[altenbach]

Sorry, I should have been more clear.

Yes, you can do a "queued state machine" in a single loop by simply maintaining a stack of tasks. That's not what I meant. I was talking about a two-loop design, using an actual queue. I am never quite sure about the correct terminology of all these architectures. 😉

(After all, LabVIEW programmers use pictures instead of words to effectively communicate! :D)

[Ben]

---

@altenbach wrote:

Sorry, I should have been more clear.

Yes, you can do a "queued state machine" in a single loop by simply maintaining a stack of tasks. That's not what I meant. I was talking about a two-loop design, using an actual queue. I am never quite sure about the correct terminology of all these architectures. 😉

(After all, LabVIEW programmers use pictures instead of words to effectively communicate! :D)

---

I'd love to be able to cite you durring those recert exams when I KNOW what it looks like but don't rember the names that the CS type assigned.

Ben

[Ray.R]

---

@Ben wrote:

---

@altenbach wrote:

(After all, LabVIEW programmers use pictures instead of words to effectively communicate! :D)

---

I'd love to be able to cite you durring those recert exams when I KNOW what it looks like but don't rember the names that the CS type assigned.

---

So true...