State Machine vs Sequence Structure for DAQ read/write and file I/O

[Ray.R]

---

Dr. Reynolds wrote:

 I think I'm going to have to go with a Flat Sequence Structure and move on.

Quick question though. The Property Node allows me to reuse a boolean switch (for instance) in different cases of my state machine?

---

1. You will (may?) hit a large brick concrete granite wall by sticking with a Flat Sequence.  It will not replace a State Machine.  And it will not allow (easy) scalability.  If you describe what your state machine should do, I (we) can gladly create an example for you.  Even a hand-drawn sketch of a state machine representation will do.  Describe what the overal system does.

2.  Using a State Machine may eliminate the need for a property node if you want to use it to "re-use" a value.  You would use a Shift Register to pass values from one state to another.  The value would be shared (thus available) among all states and remain constant unless changed by one of the states.

R

[Dr._Reynolds]

---

Norbert B wrote:

Michael,

please look at attached screenshot. Hope this clears up some questions.....

 

---

[...] I agree with you regarding taking a course, but I just don't have time right now. [...]

---

That is one of the most common false estimation ever done! You have to spend some time (about a week), but you can save weeks during your developement. Choosing the wrong architecture due to lack of knowledge has to lead to exceeded projecttimeframes as well as nearly impossible changemanagement! So gathering as much knowledge as possible before starting to design the code can save you a lot of money!

To be honest, sure maybe there is no suitable course available at the moment, so taking a course is not possible. But if you are not sure, ask your local NI representative!

---

[...] I think I'm going to have to go with a Flat Sequence Structure and move on[...]

---

That is imho the badest choice you can meet. Just to quote Ray: "Stacked Sequence Structures should be removed from the palette.  They always lead to horrible code."

hope this helps,

Norbert 

[EDIT]: Please note that the enums are predestinated to be typedefined... so please make a single typedefinition and use this for controlling the states. This will reduce implementationtime when extending the state machine immensly....

Message Edited by Norbert B on 09-12-2008 04:05 AM

---

Hi Norbert,

Yes, this indeed helps. I was getting hung up on the Property Node stuff and a rather complex state machine example (called "State Machine Example.vi" -- attached screenshot) that has a lot of extra stuff in it. If I don't need to use Property Nodes and such, things seem a little simpler. Could you send me the Vi that you posted?

I've found some video so I'll take a look at that and a few other examples. Google seems to work a little better for me than the regular NI search (LOL). 

Thanks again,

-- Michael

 

[Dr._Reynolds]

---

JoeLabView wrote:

---

Dr. Reynolds wrote:

 I think I'm going to have to go with a Flat Sequence Structure and move on.

Quick question though. The Property Node allows me to reuse a boolean switch (for instance) in different cases of my state machine?

---

1. You will (may?) hit a large brick concrete granite wall by sticking with a Flat Sequence.  It will not replace a State Machine.  And it will not allow (easy) scalability.  If you describe what your state machine should do, I (we) can gladly create an example for you.  Even a hand-drawn sketch of a state machine representation will do.  Describe what the overal system does.

2.  Using a State Machine may eliminate the need for a property node if you want to use it to "re-use" a value.  You would use a Shift Register to pass values from one state to another.  The value would be shared (thus available) among all states and remain constant unless changed by one of the states.

R

---

Greetings Joe,

Thanks for the help. What I wanted to do first was get my hands on a simple but worthwhile state machine example. That way I could simply expand that machine to something bigger and closer to what I NEED to do. My simple example was a four-state machine described earlier. I understand how to do enumeration but I don't know the most efficient way to handle multiple transitions. I've seen Select blocks used; I've seen Property Nodes with Enumerated Arrays (see Coke Machine); and neither really explain how to do it.

My system needs to do the following:

• start with a system reset
• read data from a file (while EOF not true)
  •  look for a countdown value which will trigger some external action
  • compare value to a range, if range exceeded, trip an alarm which causes datalogging and back to system reset

That's essentially the essence of what's happening. The data file values are sent to an external computer via DAQ boards. Those signals are processed and digital signals are sent back to say ALARM tripped or NO ALARM. The more I think about this, I'm asking myself if a state machine would be overkill. It's going to go through this sequence of events over and over without any real user input.

In any event, any assistance you can provide on either (or both) fronts would be appreciated.

Thanks,

-- Michael

P.S. I'll stay away from the Stacked and Flat stuff. Promise 🙂

[Andrey_Dmitriev]

---

JoeLabView wrote:

Stacked Sequence Structures should be removed from the palette.  They always lead to horrible code.. 

---

Sorry, but I disagree with this. In some cases this produces terrible code, you're right, but in some cases it helpful. Personally I using stacked sequence for controlling time of the execution (three frames with GetTickCount and subtract).

Andrey.

[Ray.R]

Andrey,

You're an exception to the rule.  One of the few who knows how to use it well 😉

[DFGray]

Try the example listed here. It uses a queue driven state machine to allow multiple actions.  Queues are highly flexible in that they can be flushed, reordered, queried, etc, tailoring the behavior to whatever you need it to be.  The example does none of this, but shows the basic idea.  The example was designed to show how to design a good UI, so it spends most of its time waiting for user input.  However, it should work for you.  Note that the data storage mechanism in the example is somewhat obsolete.  It works, but there are much better methods available.  Let me know if you need more information.