How many "User Events" can LabVIEW queued?

[Yair]

First thing that popped into my head reading this:

"I'm Dr.T and I'm a Night-Elf Mohawk."

I'm already apologizing for this:

[jcarmody]

If instead of "QSM" we referred to that pattern as "Hector," I would consider that a better (if rather arbitrary) name.

HECTOR!!!!!!

[Daklu]

for the humor!

(I’m working on a more complete comparison between QSMs and “real” state machines. I’ll likely post it in a new thread when it’s ready.)

Continuing from earlier…

Who is Scooby?

Really? Scooby-Doo? Shaggy? Velma, Fred, and Daphne? You know… Mystery, Inc?

(I thought the US exported our television across the galaxy…)

Having a QSM managing many objects' States would be very difficult.

Agreed. I’d probably take it a step further and say having a QSM manage anything other than itself is a mistake. (At least I would if I thought QSMs were a good idea.)

From you images it looks like you have a string Command from a Queue wired into a case structure. Is this not some form of QSM (in the above sense)?

Not in my mind. Although in principle you could queue up more than one message at a time, there is no reason to do so. Each case is an atomic operation. Any time the loop is ready to dequeue a message, any message is valid. None of the cases depend on another case being executed prior to it or following it.

It also seems you have taking messaging a step further and implemented the famous design pattern that Paul-At-Lowell raves about (he was threaten to post this recently, but this is the first LabVIEW example I have seen).

3) In the example you posted it seems like there is a great deal of work gone into the messaging, do you have a reusable framework to build from?

This application does use the command pattern, but it’s not part of my messaging system. The messaging component essentially consists of a MessageQueue class, which wraps LV’s queue prims along with error handling, and a Message base class with a single Get Name method. Rather than sending messages as strings and variants/typedefs (both of which caused me maintenance headaches) all messages are sent as objects. This makes it much easier for me to arbitrarily change data the message carries without breaking the app in a bunch of different places.

In that application each message is a unique class and the message name is defined by the message class’ name. This gives me type safety; I don’t have to worry about accidentally sending the wrong data to any message handling case and the only spell checking required is to make sure the cases are spelled identically to the class names. In a sense it is “debugging by design.” I eliminated the possibility of a whole range of bugs and all the error checking code that goes along with them.

The downside is that each message requires its own class even if multiple messages contain the same data. That can create a lot of duplicate code, and LV edit time performance seems to suffer badly when there are lots of classes in a project.

I’ve addressed that in my latest application by creating unique message classes according to the type of data they carry. If multiple messages carry the same data (or more frequently, no data) then all those message objects are instances of the same message class, but the message name property is set when the object is created. The tradeoff? Less type safety, more spell checking inspection, simplified project window and class hierarchy.

But if you would like to, please feel free to post more on this as I am very interested in this as it seems you have a higher level of abstraction here.

Can’t post the app and the topic itself is a 6-week thread all on its own. If you don’t have it I strongly recommend purchasing Head First Design Patterns. It’s well worth it at twice the price.

1) How do you handle smaller GUIs. For example if you have a small application with a main GUI and 5 smaller dialogs (for data entry etc...) do you use this pattern (and separate GUI and Engine) for all of them?

I don’t universally use active objects for all my applications. There’s a lot of complexity associated with them that isn’t always beneficial, and to be honest, I’m not satisfied with the ActiveObject.lvlib template I have. I’m still trying to figure out how to appropriately separate the active object functionality from the business object functionality. I do prefer the flexibility of the MVC architecture and will use it unless there is a very compelling reason not to.

When fleshing out an app’s requirements I try to be very up front about the consequences of what my customer is asking for. Often they say something like, “All I need is a quick vi to do…” My response is, “I can do that, but here are the things that will be difficult to add later.” Once they understand that they *always* want a more flexible design. I’m sure that’s partly due to the environment I work in. In product development testing our test engineers often don’t know exactly what they will need to test in the future so they want to keep their options open as long as possible.

2) What about really basic dialogs?

If I have a basic Get/Set (Ok/Cancel) data entry screen, I really don't see the point of implementing something elaborate if I get the same result using Hector.

I agree. But why do you need Hector for a dialog box? (See image at the end of post for how I handle simple dialog boxes.)

Also when it comes to GUIs how to you test your code?

So far when using MVC my UI code has been almost trivially simple. The UI class is fairly dumb. Its public api is events to indicate the user performed an action and methods to allow the Controller to induce changes in the UI. It doesn’t maintain any information about what the Model is doing. Connecting the UI and the processing code (in the Model) is the Controller’s job.

If the UI has to do something a little more complex like load a file, usually I’ll create a DataFile class that knows how to load and save itself. When the UI needs to load the file it just calls the appropriate DataFile method. The DataFile object is tested separately from the UI object.

How do I validate my UI code? Inspection is often sufficient. If there’s some question I can easily verify it by stepping through the code.

Are you able to automate testing of it some how?

…in terms of GUI I don't have any way to automate/check/test these other than Usability Tests, but am very interested to learn more or how I can do this better. Would your implementation help towards this issue?

I dunno… you’re the script monkey in this conversation.

Automated testing and Design For Test aren’t areas I have much experience in. I understand the principle, but haven’t implemented much. I do remember recent posts from NI about a third-party automated GUI testing toolkit. Haven’t looked at it though…

MVC could help simply by removing the need to automate UI testing. Since the functional part of the application is in the Model and accessible entirely through method calls, in theory you can create enough unit tests to achieve full coverage.

[Daklu]

3) In the example you posted it seems like there is a great deal of work gone into the messaging, do you have a reusable framework to build from?

Since you asked, here's what I'm currently using for my messaging framework. I uploaded the source to the LapDog respository and will do any additional modifications there.

MessageLibrary.zip

[jgcode]

Not in my mind. Although in principle you could queue up more than one message at a time, there is no reason to do so. Each case is an atomic operation. Any time the loop is ready to dequeue a message, any message is valid. None of the cases depend on another case being executed prior to it or following it.

Yes, in essence this is how Hector should be used, all state information is contained in the objects, so (if you want tight code) any message/command/state should be able to be called in any order - it should be up the object if it is logical to perform action.

Of course you have have the flexibility to do what you want for any simple/complex GUI using Hector.

If you don’t have it I strongly recommend purchasing Head First Design Patterns. It’s well worth it at twice the price.

I do have it, that is what I meant when I referred to HFDP. I haven't dived deep into it yet as there is so much other stuff to do.

But it is on my do-list (keeping in mind this seems to grow exponentially).

I agree. But why do you need Hector for a dialog box? (See image at the end of post for how I handle simple dialog boxes.)

Ok, my aim was to give you a simple example (maybe too simple by calling it dialog?), then enquire how you would expand the design without a rewrite of the pattern used.

Now what happened now if the requirements changes to include:

• If user types in invalid entry for "This String" then display help text and disable Ok button (and this list grows to 10 others like this etc...)

My thoughts are still that Hector would be great here.

How do I validate my UI code? Inspection is often sufficient. If there’s some question I can easily verify it by stepping through the code.

Automated testing and Design For Test aren’t areas I have much experience in. I understand the principle, but haven’t implemented much. I do remember recent posts from NI about a third-party automated GUI testing toolkit. Haven’t looked at it though…

Yer, I read that post and also Omar posted here somewhere about some Ideas and stuff they do wrt to UI Testing and automating it. Interesting stuff.

MVC could help simply by removing the need to automate UI testing. Since the functional part of the application is in the Model and accessible entirely through method calls, in theory you can create enough unit tests to achieve full coverage.

Yer, that what I try to do.

Its more testing the GUI acting on the functional part that I am interested on improving.

The only way I know how to do it is manual testing.

Since you asked, here's what I'm currently using for my messaging framework. I uploaded the source to the LapDog respository and will do any additional modifications there.

Cheers, I'll take a squizz.

[Justin Goeres]

First, this is a great discussion. Keep it going! I just have a couple minor points of clarification to make.

Regarding the "state machine" terminology, it is absolutely true that the JKI State Machine is not a state machine in the strictest sense of the word. It's really more of a sequencer. For those of you who have seen JKI's LabVIEW User Group presentation on the JKI SM, you may remember that we usually point this out to head off exactly these discussions . I suppose you can call it a message handler, too, but we don't get hung up on the exact terminology. Besides, rightly or wrongly LabVIEW developers (especially beginning ones) think of a state machine as "a While Loop with an enum in a shift register, which drives a Case Structure." The JKI SM is string-based, but it looks a lot like what they're familiar with and so calling the JKI SM a state machine helps them understand it.

The other point I want to make (which might be sort of at odds with the "state machine" terminology issue), is that we don't just treat the JKI SM as a state machine. We use it like a fundamental building block for creating LabVIEW code. It's as much a first-class citizen in the language as a While Loop or a Case Structure, and it's the basis for other, more complicated designs. If you need to build a "real" state machine, you can absolutely do it using the JKI SM as a starting point. Or if you need separate loops for UI handling and asynchronous processing, each of those can be a JKI SM. Part of the reason we love the JKI SM so much is because of its scalability and flexibility.

FYI, I'm going to be doing a presentation at NIWeek 2010 with Nancy Hollenback (The G Team) and Norm Kirchner (NI) called "State Machine vs. State Machine," comparing two different SM designs (JKI's and one of Norm's) and discussing how each one approaches different design decisions. It's currently slated for Tuesday morning right after the first keynote, so if you're coming to NIWeek 2010 put it on your calendar .

[jgcode]

First, this is a great discussion. Keep it going! I just have a couple minor points of clarification to make.

Regarding the "state machine" terminology, it is absolutely true that the JKI State Machine is not a state machine in the strictest sense of the word. It's really more of a sequencer. For those of you who have seen JKI's LabVIEW User Group presentation on the JKI SM, you may remember that we usually point this out to head off exactly these discussions . I suppose you can call it a message handler, too, but we don't get hung up on the exact terminology. Besides, rightly or wrongly LabVIEW developers (especially beginning ones) think of a state machine as "a While Loop with an enum in a shift register, which drives a Case Structure." The JKI SM is string-based, but it looks a lot like what they're familiar with and so calling the JKI SM a state machine helps them understand it.

The other point I want to make (which might be sort of at odds with the "state machine" terminology issue), is that we don't just treat the JKI SM as a state machine. We use it like a fundamental building block for creating LabVIEW code. It's as much a first-class citizen in the language as a While Loop or a Case Structure, and it's the basis for other, more complicated designs. If you need to build a "real" state machine, you can absolutely do it using the JKI SM as a starting point. Or if you need separate loops for UI handling and asynchronous processing, each of those can be a JKI SM. Part of the reason we love the JKI SM so much is because of its scalability and flexibility.

FYI, I'm going to be doing a presentation at NIWeek 2010 with Nancy Hollenback (The G Team) and Norm Kirchner (NI) called "State Machine vs. State Machine," comparing two different SM designs (JKI's and one of Norm's) and discussing how each one approaches different design decisions. It's currently slated for Tuesday morning right after the first keynote, so if you're coming to NIWeek 2010 put it on your calendar .

Ok, I am glad someone from JKI replied as I didn't want to be botching what they have done by posting incorrectly (although you seem to like the discussion!). I like the sequencer notion (haven't heard that before )

I have used all resources available (LAVA, JKI, NI Forums), as well as trial-and-error to find out the best way to use it, but, it still only my interpretation (and to face facts, my interpretation can suck).

I am sure I have a lot to learns, I will def be attending that talk (are all the times up? - I will have to check), so in the meantime if anyone can post examples and comment more that would be much appreciated.

[Daklu]

First, this is a great discussion. Keep it going! I just have a couple minor points of clarification to make.

I'd love to respond to this comment right now. In fact I had a lengthy response (do I have any other kind?) half complete. Alas, I ran out of time and I'll be off the grid for the next week, so I'll have to pick up this thread later.

[jgcode]

I'd love to respond to this comment right now. In fact I had a lengthy response (do I have any other kind?) half complete. Alas, I ran out of time and I'll be off the grid for the next week, so I'll have to pick up this thread later.

What will I do with myself?

[JG ponders the inevitable]

[Daklu]

Quick update: I am currently working on an app in which I ripped out the active object implementation (it was getting too cumbersome) and replaced it with a more "pure" state machine idea I have, based in part on the GOF's state pattern. My initial impression is that it requires far fewer states than the equivalent QSM and is much easier to understand and extend. I'll see if I can get something posted in the next couple days and the rest of you can take a gander.

FYI, I'm going to be doing a presentation at NIWeek 2010 with Nancy Hollenback (The G Team) and Norm Kirchner (NI) called "State Machine vs. State Machine," comparing two different SM designs (JKI's and one of Norm's) and discussing how each one approaches different design decisions.

Oh man I wish I could see this. (Yeah, I'd keep my mouth shut and just listen. )

Anyone know if Norm has made his state machine model public, or is he using NI's standard template?

[Yair]

FYI, I'm going to be doing a presentation at NIWeek 2010 with Nancy Hollenback (The G Team) and Norm Kirchner (NI) called "State Machine vs. State Machine," comparing two different SM designs (JKI's and one of Norm's) and discussing how each one approaches different design decisions. It's currently slated for Tuesday morning right after the first keynote, so if you're coming to NIWeek 2010 put it on your calendar .

You're up against Rob Dye. Come on! Who creates these schedules?

[Daklu]

Ok, my aim was to give you a simple example (maybe too simple by calling it dialog?), then enquire how you would expand the design without a rewrite of the pattern used.

Now what happened now if the requirements changes to include:

• If user types in invalid entry for "This String" then display help text and disable Ok button (and this list grows to 10 others like this etc...)

My thoughts are still that Hector would be great here.

I suppose "great" depends on what you're trying to accomplish and what kind of architecture your application has. The solution to that specific problem depends on the particulars. Who (meaning which part of the application) knows how to validate the entry? Who owns the help content? Who is responsible for the way the content is displayed? etc. If the answer to all these questions is "the dialog box," then a QSM will work, but hopefully you'll be aware of the limitations of the decision and can communicate those to your customer. If you haven't even asked those questions then I'll argue you haven't thought out your application's architecture well enough.

Your question appears to assume I use single vis for my dialog boxes. I don't do that. My dialog boxes are classes. Why? Classes allow me to decouple the app's user interface from its functionality. Sometimes dialog boxes need to be shown in response to a user action, such as pushing a button. Sometimes they need to be shown because of something happening in the application, such as getting invalid measurement data. Using QSM dialog boxes scatters user interface code all over the functional code.

Consider this: Suppose you've created an automated test app that has all sorts of dialogs for status updates, warnings, prompts for locations to save files, etc. It's just what the customer asked for. A month later he comes back and says, "You know what? We need an option that allows advanced users to disable the status update and warning dialog boxes." How do you apply this change? Probably by creating a UserType {Beginner | Advanced} enum and adding it to a supercluster of data that is carried through your app. Dialog boxes are shown or not shown during execution based on the enum. Kind of a pain, but not insurmountable. Probably the kind of change you expect to do as a developer.

Then he comes back and says, "We need an option to run in unattended mode. Status updates and warnings should be saved to a log file. In this mode data will be saved on the network share." Okay, now we have UserType {Beginner | Advanced | Unattended}, probably add a LogFileDirectory to the supercluster, and we change around the functional code to deal with the new requirements. Unfortunately the requests keep coming...

"Sometimes the network is down. The data needs to be saved locally if that happens."

"We want the option to save data in text format or as an .xls report."

"One of our operators can't see very well. Can you create a 'High Contrast' option?"

Q: What do all these requests have in common?

A: None of them affect the test execution logic in any way, yet will likely require changes to your test execution code in order to implement. I have a hard time considering an implementation "great" if it includes these limitations.

Cheers, I'll take a squizz.

I have no idea what that means, but it sounds disgusting.

Regarding the "state machine" terminology, it is absolutely true that the JKI State Machine is not a state machine in the strictest sense of the word. It's really more of a sequencer.

So if it's a sequencer, what is it you're sequencing?

I suppose you can call it a message handler, too, but we don't get hung up on the exact terminology.

I've said it before, but I think the terminology is extremely important. Message handlers, sequencers, and state machines all have very different purposes and are not interchangable. Failing to distinguish between them creates a lot of confusion about what role that bit of code is supposed to fulfill. In my opinion this diagram illustrates the key difference between a QSM and message handler.

Not extending the message queue past the dequeue prim makes all the difference in the world. A message handler can't send messages to itself because there's no reason for it to do so. If I end up in a situation where the message handler needs to send a message to itself then there's a flaw in my design that needs to be addressed.

It's as much a first-class citizen in the language as a While Loop or a Case Structure, and it's the basis for other, more complicated designs.

Calling something a "first-class citizen" in a language usually means you can pass it as a parameter or assign it to a variable. So, while technically you are correct (while loops and case structures aren't first class citizens either) I'm pretty sure that's not what you meant.

I'm open (but skeptical) to the idea of using a QSM as a fundamental building block, as long as it is very restricted in the scope of what it is asked to do. What I have seen most often is people attempting to use the QSM as an application architecture, a task it is entirely unsuitable for. But in order to convince me QSMs make good building blocks you'd need to start by answering the question I asked Jon earlier--How do you decide if a piece of functionality should be a case or a sub vi? More generally, how do you go from a flow chart (like the one from Ben I posted above) to a QSM implementation?

Part of the reason we love the JKI SM so much is because of its scalability and flexibility.

I see these claims being made all the time about QSMs. Are they flexible? You bet! Jello is flexible too--that doesn't make it a good building material. Good building materials offer the right balance between flexibility and structure. QSMs are too flexible. There's no inherent structure helping to guide design decisions. Without structure it can't be scalable. You won't get far building a Jello house before it collapses under its own weight.

[jgcode]

How do you apply this change? Probably by creating a UserType {Beginner | Advanced} enum and adding it to a supercluster of data that is carried through your app.

Just to be clear I don't agree with the above programming methodology although to be honest, thats what used to do when I started using LabVIEW but I consider it a very bad way to program now (as I am sure I have mentioned before). It is an assumption I guess that is made when talking about using QSM etc..

Dialog boxes are shown or not shown during execution based on the enum. Kind of a pain, but not insurmountable. Probably the kind of change you expect to do as a developer.

I may have dialog boxes shown based on the that state of possibly multiple classes within an application. I guess in this case, and for a simple example, it would be based on the configuration of the application and an event occurring rather than an enum e.g. attendedMode = TRUE AND exceptionOccurred = TRUE.

Q: What do all these requests have in common?

A: None of them affect the test execution logic in any way, yet will likely require changes to your test execution code in order to implement. I have a hard time considering an implementation "great" if it includes these limitations.

But you still need an architecture that sits behind that dialog box - the engine/process that runs it.

And using whatever implementation, I agree, it's function should be solely to present information to the user and possibly allow for user input, not affect execution logic.

Using your presented example:

If the system is running in "Normal Mode" and an exception occurs that you want to present to the user then I image in implementation could be as follows:

1. Pass Object as an input for the Dialog box

2. Run method to format information to string (possibly do this before passing to Dialog)

3. Get Exception string from Object

4. Display String in Dialog Box

5. Allow the user to enter a Comment in a "Comments Box"

6. If User presses Ok, Set Comment information to Object

7. If User presses Cancel, Set a predefined, default Comment (to indicate it was cancelled by the User) / leave blank etc...

8. Pass out Object that now contains the Exception Information and now a user Comment

Depending on other State data the Application logic may decide to

1. Discard this data

2. Log this data to a network share

3. Log this data locally

Now if the Application was configured to attendedMode=FALSE then application would make the decision not to show the dialog box in the first place, would instead run methods to format the Exception data to a string and maybe Set a default Comment to indicator not attended etc... But the application would be still be using the same Class methods called by dialog box - so that functionality is encapsulated and reusable

Therefore, with all functionality encapsulated, it has nothing to do with the Dialog or it's implementation. Its separated.

Put simply, the Dialog should call Get methods to access Object data and Set methods for User input etc...

So all the above options have absolutely nothing to do with how the data is displayed to the user.

And the architecture of the Dialog used (to display the data to the user) has nothing to do with the Application making the decision to:

1. Show a standard dialog box

2. Show a high contrast dialog box OR

3. Do not show a dialog box.

4. Other (expanded for more functionality)

Now I am sure you can implement the Application Logic using advanced design patterns that incorporate LVOOP - and that is what I am really interested in (and what the community is calling for at present).

But I still consider the QSM an important building block of my application for example, in order to implement the Dialog Box you get a new requirement (and for want of a better example) that says "the User Comment must be at least 20 characters long" (as management think this will make the attending user less likely to just press "a" <enter> and carry on).

Therefore when the Dialog is open the User types in a Comment that is 10 Characters long.

Your dialog (e.g. on a Comment Value Change Event) would then

1. Check the entry

2. Decide whether it was valid (>= 20 CHARS)

3. If valid enable Ok Button

4. If not valid display some text (contextual help) on screen that is a message saying why it failed

In order for the Dialog Box to do either of the above, one way would require it queuing a message to itself in order to either enable the Ok button OR to display some message based on the result of the validity check of the Comment.

Therefore, using a QSM would be a great way to do this IMO, and it would be an easy way to sequence these methods/commands/states.

And I also see no difference using a QSM or splitting this out into two loops in the same VI whereby a Producer (User Event loop) sends a message to the Consumer (Working Loop). Whilst this may have the advantage or simple design, it is more work to implement and it has limitations in sharing statefullness between the two loops (as they are combined). The JKI QSM implementation can be considered a Producer/Consumer combined in a single loop.

Additionally as this UI functionality is encapsulated within the QSM it can be broken down further it required based on changing requirements etc...

It can also be reused throughout an application (depending on if it runs in parallel, but considering a standard Dialog) just like any other subVI/method etc...)

So maybe in order to implement the above:

1. I start by creating the Dialog using a QSM without the need for any SubVIs, Typedefs or additional classes as it is so simple and its quick. The UI works and I don't need to spend that much time on it.

2. Changes occur to requirements and I refactor to make it tighter, using subVIs for reuse, typedef etc..

3. More expanding features means that I need to start using classes or possibly x-controls to encapsulate UI functionality etc...

4. A new requirement means I really need to take it up a notch and do something advanced e.g. a skinnable UI for Standard and High Contrast views that would need to share an engine/process for functionality reuse etc... Now this maybe implemented a totally different way, but one way could be using multiple QSMs whereby the original QSM gets strips of FP objects and become the engine/process in a UI Class that would now have two UIs (both implemented as QSMs).

Thats the thing I like is the flexibility of it all when I use the JKI QSM.

If I would have started with option 4 when I really only needed option 1 (and for example, it turns the application only ever needed option 1) then IMO would have wasted a lot of time (the customers and mine) on implementing something I didn't need.

I am also not bottled-necked in my approach as I can refactor the implementation at anytime to account for requirement changes.

[Daklu]

It'll take me some time to absorb this post, but I do have a few quick comments.

Just to be clear I don't agree with the above programming methodology although to be honest, thats what used to do when I started using LabVIEW but I consider it a very bad way to program now (as I am sure I have mentioned before). It is an assumption I guess that is made when talking about using QSM etc..

"You" was intended as a general term to indicate the QSM user, not you--Jon--specifically. I did a very poor job of making that clear.

But you still need an architecture that sits behind that dialog box - the engine/process that runs it.

This is one of the main points where I've not quite been understanding where you've been coming from. The way I've seen the QSM used and my main point of contention with it is using it as a top level vi within a module and expecting it to provide some sort of structure to the module. It sounds like you've got some other architecture in mind already and are just using the QSM as a way to implement the architecture?

[jgcode]

It'll take me some time to absorb this post, but I do have a few quick comments.

Please post when you have time ! I love reading your stuff.

"You" was intended as a general term to indicate the QSM user, not you--Jon--specifically. I did a very poor job of making that clear.

Sorry, thats my fault, I will try not to take stuff so literal

Wrt the internet - that is the one thing I still have trouble grasping.

This is one of the main points where I've not quite been understanding where you've been coming from.

Gees, sometimes I don't even know where I am coming from!

The way I've seen the QSM used and my main point of contention with it is using it as a top level vi within a module and expecting it to provide some sort of structure to the module. It sounds like you've got some other architecture in mind already and are just using the QSM as a way to implement the architecture?

I have found, that this architecture is great (theres that word again) for the backbone of my screens (dialogs, data entry etc...) in most of my apps.

I find that using LVOOP I can encapsulate so much, that using a QSM as a Top Level VI can work fine in a small-to-medium size app.

As I have found it's pretty clean, when I am just (as Justin puts it) sequencing things.

But I have also seen its limitations or how it can be implement badly to create garbled code (with the points you raised thus far) and try to avoid those.

Also, programmers have been creating Large Applications for a long time, before LVOOP was around, so I trust the veterans, and am confident that these design patterns are quite robust and have been used extensively.

On the flipside, I am, as mentioned above, very interested in seeing the new breed of LabVIEW design patterns, most likely implemented in LVOOP (as it really is so powerful), that the community will develop / already have.

I am excited to see these and there seems to be a big push for it in the community, that hopefully they will start getting fleshed out, shared, standardised. and supported real soon.

[Daklu]

FYI, I posted a screen shot of the state machine implementation I mentioned above on Paul's thread here.

[burd]

Hi Justin,

I read your presentation. Unfortunately you may have forgoten to put the power supply presentation's example available for download. It is very hard to follow the example just by reading the power point presentation. Is there any chance you could put this example available for download? There is also another example in the power point presentation using LVx. Could you also make it available for download?

Thanks

Helcio

First, this is a great discussion. Keep it going! I just have a couple minor points of clarification to make.

Regarding the "state machine" terminology, it is absolutely true that the JKI State Machine is not a state machine in the strictest sense of the word. It's really more of a sequencer. For those of you who have seen JKI's LabVIEW User Group presentation on the JKI SM, you may remember that we usually point this out to head off exactly these discussions . I suppose you can call it a message handler, too, but we don't get hung up on the exact terminology. Besides, rightly or wrongly LabVIEW developers (especially beginning ones) think of a state machine as "a While Loop with an enum in a shift register, which drives a Case Structure." The JKI SM is string-based, but it looks a lot like what they're familiar with and so calling the JKI SM a state machine helps them understand it.

The other point I want to make (which might be sort of at odds with the "state machine" terminology issue), is that we don't just treat the JKI SM as a state machine. We use it like a fundamental building block for creating LabVIEW code. It's as much a first-class citizen in the language as a While Loop or a Case Structure, and it's the basis for other, more complicated designs. If you need to build a "real" state machine, you can absolutely do it using the JKI SM as a starting point. Or if you need separate loops for UI handling and asynchronous processing, each of those can be a JKI SM. Part of the reason we love the JKI SM so much is because of its scalability and flexibility.

FYI, I'm going to be doing a presentation at NIWeek 2010 with Nancy Hollenback (The G Team) and Norm Kirchner (NI) called "State Machine vs. State Machine," comparing two different SM designs (JKI's and one of Norm's) and discussing how each one approaches different design decisions. It's currently slated for Tuesday morning right after the first keynote, so if you're coming to NIWeek 2010 put it on your calendar .

Edited September 11, 2010 by burd

[jgcode]

I read your presentation. Unfortunately you may have forgoten to put the power supply presentation's example available for download.

[cross-posted to jki-forums]