state machine template critique

[GregFreeman]

Per other's suggestions in another thread here, I have put together a state machine type architecture that I have already somewhat started to pitch (it seemed to turn some heads) and I'm going to show it in a design meeting. I wanted it critiqued before I did though. Opinions, criticisms, and suggestions welcome!

[GregFreeman]

I should add, this is more of an example than a template. The template will have far less cases. Unless some of you think I should leave it as is?

[Ben]

[Set Sarcasm Mode = True]

An empty template should handle just about anything but do we really want to be THAT fleixble?

[Set Sarcasm_mode = False]

I tried to open that in LV 7.1 and LV 2009 and it looks empty.

Sorry,

Ben

[GregFreeman]

hmmm...weird. Here it is just zipped instead of in a .llb. Kudos for trying (literally)!

[Ben]

A couple of quick comments

1) drop the name of the queue so you can run multiples of these in parallel without them stepping on each other.

2) Just a matter of taste but I prefer to le the consumer kill the queue since only it knows when it is done eating.

3) the type def was saved as LV 8.5 so watch out.

Ben

Message Edited by Ben on 10-23-2009 11:26 AM

[GregFreeman]

---

Ben wrote:

A couple of quick comments

1) drop the name of the queue so you can run multiples of these in parallel without them stepping on each other.

2) Just a matter of taste but I prefer to le the consumer kill the queue since only it knows when it is done eating.

3) the type def was saved as LV 8.5 so watch out.

Ben

Message Edited by Ben on 10-23-2009 11:26 AM

---

1. No problem

2. I originally had it that way, for the same reason you described. Then I looked at the LabVIEW producer consumer architecture and it had it after the producer loop. Thats what I get for being a "robot". I also like it after the consumer loop better because no error is thrown due to the queue being destroyed prior to the consumer loop finishing processing/reading from the queue.

3. Thats what I get for having two versions of LabVIEW open at once...fail.

Thanks!

Message Edited by for(imstuck) on 10-23-2009 11:43 AM

[Mark_Yedinak]

Overall it looks pretty good. I posted another example architecture in another thread you may want to look it as well. I agree with Ben that you should drop the name. However I don't necessarily see a problem with your top level VI release the queue as part of its cleanup. I generally go by the rule that the creater of the queue should be the one responsible for destroying it. You do have an issue if your error handler kicks in in that there is no way for it to feed back to the event structure that it has exited. I would probably replace the error constant with the Clear Errors subVI. Both do the same thing but the Clear Errors looks cleaner and expresses better what is actually being done.

[jcarmody]

Have you looked at the JKI State Machine or this library that NI offers? I'm partial to JKI, but the other looked good to me, too. As I started learning to use the template I found myself appreciating some features that I wouldn't have come up with on my own in 1e6 years. One thing I like is that they both use strings instead of enums, contrary to what we'd learned from NI training.

<personal plug> I wrote a plugin that assists in state machine development.  It works on any Case Structure, but it has special features that only apply to the JKI State Machine. <\personal plug>

[Mark_Yedinak]

---

jcarmody wrote:

Have you looked at the JKI State Machine or this library that NI offers? I'm partial to JKI, but the other looked good to me, too. As I started learning to use the template I found myself appreciating some features that I wouldn't have come up with on my own in 1e6 years. One thing I like is that they both use strings instead of enums, contrary to what we'd learned from NI training.

<personal plug> I wrote a plugin that assists in state machine development.  It works on any Case Structure, but it has special features that only apply to the JKI State Machine. <\personal plug>

---

I know there is always the onging debate regarding using strings or ENUMS. Both have their advantages and disadvantages. I tend to like ENUMs though because they help to prevent coding errors by inserting incorrect states. I know JKI's state machine includes the state to catch unknown states but I like to enforce this check at coding time rather than at runtime. Plus, the old embedded programmer in me likes the fact that ENUMs use less space than strings. I know this doesn't matter much on today's PCs but old habits are sometimes hard to break.

[GregFreeman]

---

Mark Yedinak wrote:

---

jcarmody wrote:

Have you looked at the JKI State Machine or this library that NI offers? I'm partial to JKI, but the other looked good to me, too. As I started learning to use the template I found myself appreciating some features that I wouldn't have come up with on my own in 1e6 years. One thing I like is that they both use strings instead of enums, contrary to what we'd learned from NI training.

<personal plug> I wrote a plugin that assists in state machine development.  It works on any Case Structure, but it has special features that only apply to the JKI State Machine. <\personal plug>

---

I know there is always the onging debate regarding using strings or ENUMS. Both have their advantages and disadvantages. I tend to like ENUMs though because they help to prevent coding errors by inserting incorrect states. I know JKI's state machine includes the state to catch unknown states but I like to enforce this check at coding time rather than at runtime. Plus, the old embedded programmer in me likes the fact that ENUMs use less space than strings. I know this doesn't matter much on today's PCs but old habits are sometimes hard to break.

---

You have been a ton of help, Mark. Thanks. I also like enum because it's so easy to take that strict type def control and just right click the case structure, and add a  case for every value when the control has been modified.