please don't do it

[shoneill]

I agree 100% with Titou,

for me, scaleability and maintainence are two big plus points for a queued state machine.  But for me, the only difference between a queued state machine and a normal state machine is the presence of an interactive UI.  If I need one, I go the queued approach, if not, the normal SM approach.

State Machine
Scaleable Maintenance

But on the other hand, I have quite a few programs which are programmed the "old" way.  If I ever have to actually significantly optimize them, I'll most certainly switch to QSM.  UI - Code coupling (or de-coupling would be more accurate) is simply hugely superior.

Shane.

[terrill]

You guys are missing the point. I too use the queued state machine for GUIs or for situations where the order of execution is determind by runtime events. My complaint is that people now use this structure for everything. It can be a simple function with 10 steps that always happen in the same order and it will be coded as a state machine. Just because you can does not mean you should.

[becktho]

Hi

I always try to find the appropriate coding style. Compared to a sequence structure or dataflow, using a SM (even for 10 steps) allows you to simply deactivate existing code without removing it. Just by simply changing the transition value. For me this is sometimes very very useful.

But of course you're right - don't use something where it doesn't make sense.

Thomas

[TiTou]

I'm not sure we are missing your point terrill... I feel we understood and answered.

Using QSM is often used even if a simpler architecture could do the job : I think we almost all agree on that point.

From this statement, you're saying we should not stick to SQM when not needed and use the appropriate architecture (this is, how I sum what you said, maybe I misundertood you on that point ).

I repeat that for a function with 10 steps that will always happen in the same order I prefer a basic SM to a sequence because (as pointed Dennis) this allows not to go through all states if an error occures in state 1 or you can also have one subVI for each operation, put then one after the other and link the errors, no need for a sequence in that case. Do we agree on that point ?
BTW another advantage is to avoid sequence locals and locals which break the data flow...

This thread is quite interesting  !

[shoneill]

OK, I think we're getting closer to a common ground.

I strongly believe that once a program goes beyond a certain complexity (I would measure "complex" as well over 10 individual steps) it becomes much easier to plan, program and debug if it's implemented in a SM-type architecture.  Like Becktho says, parts of the code can simply be left out later.  These "left out" parts can be parts of the code very useful for debugging which then don't have to be re-programmed each time you want to debug again.

I simply believe it gives a more modular approach to programmins but I too would not dream of using it for a small (< 20 individual functions) VI which has no visible UI.

The same limit also applies WITHIN a SM architecture.  What functions are contained within the same state?  What should be split, what should remain together?  I think each programmer must decide on what the optimal "block" or "module" size is for their application / programming style / employer etc.

If I may attach a small example.

1.png is a block diagram is a relatively small data processing application which have implemented in queued SM fashion.
2.png is a much earlier version (with not even half the functionality) which is wired conventionally.  Badly, but conventionally.

I was going with the version 2 until addition of functions (no constant specs here guys 🙂 ) became so burdensome that I switched over to SM design and immediately the speed of development leapt forward.  I would shudder to think what 1.png would look like in the 2.png style of programming.  Anyone got a 30" monitor?

So I suppose, the diagram in 2.png is my limit for non-SM design.

Anyone else?

Shane

EDIT: Oops, forgot the pics.

Message Edited by shoneill on 06-22-2006 03:04 PM

Message Edited by shoneill on 06-22-2006 03:04 PM

[terrill]

Titou,

I probably would not use any state maching for that situation. You state one of my main reasons being dataflow. I also believe in code reuse and state machines mostly tend to be application specific. I would separate the code into functional blocks and try to be as object oriented as possible. I would keep data flow and handle errors in individual vis. If some elaborate error handling is needed then error code may be coded. I can see situations where a state machine would be useful if are different ways of handling errors or if the ability to correct the error exists.

[becktho]

This is a statement I have to jump on definitely.

".. try to be as object oriented as possible.."

Using basic LV where subvis are wired together you are by far not object oriented.

[terrill]

I do not think the code example you give is fair. You created many subvis in the state machine code. That being said, it is a GUI so it probably be coded as a state machine.

[shoneill]

I don't really see the "code reuse" topic being something to differentiate SM architecture from the rest.

There's no real difference between the code contained in a single SM state and the "functional blocks" you are describing.  They're just linked differently.

He, maybe you're closer to using a SM architecture than you realise 😉

I personally make most of my SM code to use the same code but in different (Variable versus fixed) order when called as a stand-alone VI or as a sub-VI respectively.  I also don't use events for calls as Sub-VI of course as the UI then loses its importance).  This results in very different behaviour of the VI when run alone or when called as part of another application which makes it ideal for debugging.  Of course that's possible with SM and other programming methods too.

Shane.

PS I wasn't trying to be "fair".  I wasn't aware this was a competition.  I thought it was an exchange of viewpoints.  At the end of the day, everyone should code how they feel is best.  I also admitted that the diagram 2 needed sub-VIs in my previous post....

Message Edited by shoneill on 06-22-2006 03:24 PM

[Joe_H]

I think we all agree that SM's are an outstanding architecture for maintainablity and scalability. However they can be overkill for some small vi's. With that said it really does not matter how this thread turns out because we all have our own style of programming. we all program the way we feel comfortable doing so. I may link error clusters and you may use a SM. The point is it gets the job done and we feel good about the job that we did. This is just about the same discussion as about local and global variables. It can go on and on. The fact is we get into a comfort zone. If your comfortable always using SM's then hey go for it, if not then don't use. we are not going to convince anybody to change if they simply do not want to no matter how much we want them to, if we could there would be no war in IRAQ.

just my 2 cents.