please don't do it

[BiomedEE]

I think it is a little difficult for some to make comments on state machine versus other programming techniques when the only method they program is a state machine or qsm. That is the fundamental problem I see. Unfortunately, unless you have truly programmed with other methods, you can't really say one technique is better, yet I often hear that stance.

I often use a dynamic loader test sequencer for test applications and the code is often, with the exception of the actual test, copied right from application to application. I use state machines too but in these cases the main application is surely modified more than my test sequencer. There are cases where a state machine is optimal but I often put those cases as the ones that are not a sequence of tests. NI of course sells TestStand for those who don't want to write a test sequencer, but there are many variations and I use my own.

I like all archnitectures, not just state machines and variations of it.

All the best,

[Wiebe@CARYA]

Hi,


One thing that cannot be done with a queued state machine (but can be done with a state machine):


Document it as a flow chart.


Regards,


Wiebe.



"TiTou" <x@no.email> wrote in message news:1150960209972-381965@exchange.ni.com...
Hi all, Like many of you I do like and use a lot of queued state machines, not always of course, but maybe more that absolutely necessary ; sometimes a basic state machine would do the job and still I use my queued state machine. Why ? Well... tell me one thing that can be done with a basic SM and that can not be done with a QSM ??In some cases the QSM might be a little bit too sofisticated for the job but what's wrong with it ?THe same about stacked sequences, I totally agree with Dennis : tell me why I should use a sequence and not a simple SM with error handler ? That make no sense !I am not saying sequences should never be used, I just don't use them for the main architecture but in my subVIs when there is nothing to pass from a bit of code to the next.KISS (Keep It Simple Stupid) is a nice catch phrase but don't forget to keep it scalable and maintainable... and that can require more "sofisticated" code !
BTW : Dennis... first time I see a mistake in a post of yours but it is not about programming ;)&nbsp; ; you wrote "ad naseum", correct spelling is "ad nauseam" :pFor those who are not natural latin speakers it means "so as to disgust"

[TiTou]

---

Wiebe@CARYA a écrit:

One thing that cannot be done with a queued state machine (but can be done with a state machine):

Document it as a flow chart.

___________________________________________________________________________________________________________

Let me disagree... it depends if you have 1 or 2 loops (with one filling in the Q, and the second to execute orders), if one loop it's possible to draw a flow chart !

[Wiebe@CARYA]

"TiTou" <x@no.email> wrote in message news:1151080807002-382898@exchange.ni.com...
Wiebe@CARYA a écrit:
One thing that cannot be done with a queued state machine (but can be done with a state machine):


Document it as a flow chart.


___________________________________________________________________________________________________________Let me disagree... it depends if you have 1 or 2 loops (with one filling in the Q, and the second to execute orders), if one loop it's possible to draw a flow chart !


Not if you put things on top of the queue and on bottom of the queueu.

[TiTou]

true !!!

I forgot that... but when using both LIFO AND FIFO in a queued message handler I think this architecture is quite justified, isn't it ?

😉

[Wiebe@CARYA]

"TiTou" <x@no.email> wrote in message news:1151329208139-383440@exchange.ni.com...
true !!! I forgot that... but when using both LIFO AND FIFO in a queued message handler I think this architecture is quite justified, isn't it ?;)


If you really need LIFO and FIFO, sure, the queued state machine is good. But I seldom need it.


To prevent using LIFO functionality I just use normal state machines. Then I'm sure I can reproduce some flow charts for the documentation. (I mean: then I'm sure my specification that I made *upfront* matches my code).

[Daklu]

"There are often enough newbies who think using LV you can code sequentially, in dataflow or object oriented."

As one of the aforementioned newbies (only been playing with Labview for a week or so), I'm curious about this comment. As I read it there is an implication that you cannot code using all three models. Is the argument that object orientated coding is not available because there are no methods?

Message Edited by Daklu on 06-26-2006 12:05 PM

[tbd]

Hey terrill,
      Just wanted to add another virtual voice in agreement with you! At least I agree with your original post

FWIW, where I went to school, they didn't teach the "state machine" as a generic solution to programming problems.  They did encourage structure that conveyed its purpose.  When the SM hides simple logic, it's as bad as the stacked-sequence!

The State DIAGRAM (assuming one Buys-into it) is a nice way to reveal what its SM is doing, but amounts to a second-layer of "source-code, or simply program documentation.  Why not use a more transparent logic [when possible] that doesn't need to be explained?

I think the "state machine" is like a pair of "vice-grips", it's in most everyones' tool-box, but a few of us rarely use it,

usually, there's a better tool for the job.

Regards,
TBD (formerly Dynamik)

[becktho]

@Daklu - As this is my statement, I feel the need to answer. Working without any add-ons or toolkits you can not program object oriented. There is no way to define classes with private or public methods, create objects of them or use inheritance between classes - just to mention the obvious things.

There are some toolkits that allow you to do this, but unless it is not really necessary, stick to the dataflow.

What do you mean with "..because there are no methods?"?

[terrill]

object oriented "like" structures can be accomplished. The real missing piece is enforcing private members although with some checking I guess that can be accomplished. There is even seudo inheritance but it is limited. Even the NI goop that is planned will have limited inheritance. I would wait a while before I tackled goop. If you want to look at it for an introduction then I would suggest the openG package as it is free and is probably as good as any other method out there. Some aspects of the implementation show good ways to implement code. As a side note, I think most methods of programming can be accomplished with Labview.