Event Structure as State Machine

[LAVA 1.0 Content]

QUOTE(PeterB @ Nov 13 2007, 03:42 PM)

http://wiki.lavag.org/Event_Structure#User_Events' target="_blank">Done.

:thumbup: Thanks!

[LAVA 1.0 Content]

QUOTE(Michael_Aivaliotis @ Nov 12 2007, 11:29 PM)

...

Can someone explain the difference between State Diagram and State machine?

...

I'll try and wait for correction*.

A State Machine is a programing construct that implements a state diagram.

A State Diagram is a drawing that illustrates the various states a process can be in and the conditions under which it will transition from one state to another. I have also heard them called "State Transition Diagrams.

This is illustrated in the State Diagram Editor. With the SDE you edit the SD and LV re-codes the state machine.

Ben

* Don't give up easy.

[ned]

QUOTE(vito @ Nov 12 2007, 11:04 PM)

I hope I've presented a simple, elegant and efficient architecture. It could certainly do with some refining and I look to the community to find holes in the architecture and give me the opportunity to address them.

The benefits I see are:

1) Quick and simple to set up

2) Very legible as all actions are an Event Case that is readily listed and jumped to

3) Easy to expand.

4) Can be used for small or large projects

5) If you're willing to use Value (Signaling), great visibility on where you're code is at without any extra programming.

See attachment for a template.

I have to admit that after an initial reading of this my first reaction was pure horror, and that hasn't changed after reading it again. My primary criticism is that this isn't LabVIEW - you have broken any sense of dataflow. It is impossible to probe a wire to see the sequence in which your states execute. If a user event occurs in the middle of one of your event sequence chains (one case triggering another) you'll lose the ordering and will have trouble following what happened. If you ever need to split your logic from your user interface - say, you decide to move to an RT target with a remote display - you'll have to rewrite all your code. Events are wonderful things but they're designed to respond to occasional, unpredictable actions. They're not intended to control the normal flow of your program; if they were, we wouldn't need wires and dataflow.

The standard approach here would be to create an enumeration with all your states, with one value for each of your current boolean. That value is stored in a shift register around a while loop. An event structure resides in a separate while loop, and a queue communicates between them. When an event occurs, the corresponding enumeration value is placed in the queue to be processed by the case structure. This structure has all the advantages you listed and it follows traditional data flow. If you want to know where you are you just put a probe on the input to the case structure (or wire an indicator to it). Much easier than a page of booleans. If you ever need to separate your logic from your user interface, you just move the case structure to the new target and replace the queue with some sort of network communication. As an added benefit, other LabVIEW programmers will quickly understand what you're doing, because it's a standard pattern.

See attached example. I think you'll see it's easier to set up, read, expand and debug.

[EJW]

QUOTE(EJW @ Nov 9 2007, 11:22 AM)

::SNIP:: I realize this post may start a forum riot (state diagram diehards), but i am curious to know people's current opinions.

Well this is certainly an educational topic. At least we are getting good information all in one spot as discussions on event structures seems to be a little thin anyway.

I guess it comes down to on preference and even program size. I am assuming the projects most people are commenting on are probably rather large compared to the

one i will be doing. Most likely I will stick to the State Machine, even though as a former text-based EVENT driven programmer, i will muddle through the cumbersome state machine process.

When it comes down to it, a State Machine IS nothing more than a hard-wired Event Structure. Your data flow still flows to a decision maker which dictates what the next STATE (EVENT) will be.

Verbage appears to be the only hurdle here as to what it is called, an event or a state. The two really are the same albeit handled a bit differently.

I think the whole LED thing is a bit too much as well. Oddly the program I am going to be rewriting was originally written with a stacked sequence structure inside a while loop. I think the third sequence

has another while loop where it waits for a start signal and processed the half dozen or so user controls. That program did NOT save any settings, so if you changed something that wasnt programmed, you had to change it every time you restarted, or someone (ME) had to go back and make code changes, recompile and take back out to the machine. I did NOT write the first iteration of this (LV 5.1.1), but I am going to rewrite it (LV8.5).

:headbang:

[vito]

QUOTE(ned @ Nov 14 2007, 01:31 AM)

I have to admit that after an initial reading of this my first reaction was pure horror, and that hasn't changed after reading it again. My primary criticism is that this isn't LabVIEW - you have broken any sense of dataflow. It is impossible to probe a wire to see the sequence in which your states execute. If a user event occurs in the middle of one of your event sequence chains (one case triggering another) you'll lose the ordering and will have trouble following what happened. If you ever need to split your logic from your user interface - say, you decide to move to an RT target with a remote display - you'll have to rewrite all your code. Events are wonderful things but they're designed to respond to occasional, unpredictable actions. They're not intended to control the normal flow of your program; if they were, we wouldn't need wires and dataflow.

The standard approach here would be to create an enumeration with all your states, with one value for each of your current boolean. That value is stored in a shift register around a while loop. An event structure resides in a separate while loop, and a queue communicates between them. When an event occurs, the corresponding enumeration value is placed in the queue to be processed by the case structure. This structure has all the advantages you listed and it follows traditional data flow. If you want to know where you are you just put a probe on the input to the case structure (or wire an indicator to it). Much easier than a page of booleans. If you ever need to separate your logic from your user interface, you just move the case structure to the new target and replace the queue with some sort of network communication. As an added benefit, other LabVIEW programmers will quickly understand what you're doing, because it's a standard pattern.

See attached example. I think you'll see it's easier to set up, read, expand and debug.

ned,

I see that you are not impressed with the new proposed Event Structure As State Machine (ESSM) architecture. Firstly, thanks for taking the time to show me the equivalent functionality using a conventional Event Loop And Consumer Loop (ELCL) architecture.

My objective is to put up for consideration a simple, effective and expandable architecture for LabVIEW programs. The ELCL architecture requires queues to be established, wired up and destroyed and an additional loop. So it's not as simple, therefore it needs to have other advantages to make up for the loss of simplicity.

I'd like to now address each of the disadvantages that have been mention for the ESSM architecture:

1) My primary criticism is that this isn't LabVIEW - you have broken any sense of dataflow.

Maybe I'm missing something here, but whether you put an action into the (invisible) Event Queue or a queue that the programmer explicitly established, dataflow is broken. And to the same extent. I don't see any difference between the ESSM and ELCL architectures in terms of dataflow breaks.

2) It is impossible to probe a wire to see the sequence in which your states execute.

The "LED panel" provides this information and in a better form than a text string. This is because the "LED panel" is graphical. You can see LEDs flash and note their occurrence and order a lot better than strings that flash up.

3) If a user event occurs in the middle of one of your event sequence chains (one case triggering another) you'll lose the ordering and will have trouble following what happened.

Whether you handle user events in the Event Structure or delegate them to a Consumer Loop, if a user event occurs it will equally interrupt the ordering.

4) If you ever need to split your logic from your user interface - say, you decide to move to an RT target with a remote display - you'll have to rewrite all your code.

Yes, this is a disadvantage of the ESSM architecture. However all the code will not have to be rewritten, but it will have to be cut and pasted into a new structure or the Event Structure will have to be changed to a case structure and unwanted cases removed. Not sure how hard this would be to do or how often or likely it is to happen. Haven't had a need to move my code to another target yet and I'll cross that bridge if and when I come to it.

5) As an added benefit, other LabVIEW programmers will quickly understand what you're doing, because it's a standard pattern.

This is the subject of the topic. This is a new proposed architecture. Is it good enough to use or not? If it stands the test of the LAVA forum, perhaps it will get used. If significant holes are found in the ESSM architecture then it will disappear.

So, I'm still happy with the ESSM architecture, but I look forward to more input as I'm keen to standardise my development on a simple, effective and expandable architecture.

Regards,

[JDave]

QUOTE(vito @ Nov 13 2007, 04:20 PM)

My objective is to put up for consideration a simple, effective and expandable architecture for LabVIEW programs. The ELCL architecture requires queues to be established, wired up and destroyed and an additional loop. So it's not as simple, therefore it needs to have other advantages to make up for the loss of simplicity.

A few quick thoughts.

I have tried the ESSM (Event Structure in While Loop) architecture before, for many of the reasons you stated. It worked for me for a while but I found that I didn't like it very much as time went on.

Primary reasons are:

• I found it confusing to differentiate from actual UI interaction and programmatic interaction.
  
• I found that I was trying to pack as much as possible into every event to avoid creating new events.
  
• I didn't find any easy way to expand it. (I didn't think of chains of User Events or chains of Value Change events)
  

The problem here is that I may duplicate functionality in many different events because I don't have a specific action for it. So it becomes difficult to change the code later on.

I also feel that the expansion techniques you describe are more ad hoc patches than an architected design. Don't take that too harshly, it is just my gut feeling and if the ESSM architecture takes off then it will most likely feel more normal.

David

[vito]

QUOTE(JDave @ Nov 14 2007, 12:24 PM)

A few quick thoughts.

I have tried the ESSM (Event Structure in While Loop) architecture before, for many of the reasons you stated. It worked for me for a while but I found that I didn't like it very much as time went on.

Primary reasons are:

• I found it confusing to differentiate from actual UI interaction and programmatic interaction.
  
• I found that I was trying to pack as much as possible into every event to avoid creating new events.
  
• I didn't find any easy way to expand it. (I didn't think of chains of User Events or chains of Value Change events)
  

The problem here is that I may duplicate functionality in many different events because I don't have a specific action for it. So it becomes difficult to change the code later on.

I also feel that the expansion techniques you describe are more ad hoc patches than an architected design. Don't take that too harshly, it is just my gut feeling and if the ESSM architecture takes off then it will most likely feel more normal.

David

JDave,

Yes, it can become confusing to differentiate from actual UI and programatic interaction. This is a strength and weakness of the ESSM architecture. The beauty is that you can click in one place and see all your handlers. The problem is that once you have 50 of them you loose track of which are front panel controls and which you have used. As with most things there are workarounds. You could always label the programmatic interactions starting with, say and asterisk or some other character that you like. This change is easy and reliable since all programatic handlers are lsited in the one place (the LEDs). I still find the ability to click in one place and have all my code listed with descriptive headings and able to jump to any using the pop up menu saves me a lot of time. Anyway the ELCL architecture does not provide a solution since all tasks are delegated to the Consumer Loop and the list is just as mixed.

Does a series of events address your concern "I found that I was trying to pack as much as possible into every event to avoid creating new events"?

Regards,

[JDave]

QUOTE(vito @ Nov 13 2007, 06:18 PM)

Yes, it can become confusing to differentiate from actual UI and programatic interaction. This is a strength and weakness of the ESSM architecture. The beauty is that you can click in one place and see all your handlers. The problem is that once you have 50 of them you loose track of which are front panel controls and which you have used. As with most things there are workarounds. You could always label the programmatic interactions starting with, say and asterisk or some other character that you like. This change is easy and reliable since all programatic handlers are lsited in the one place (the LEDs).

I understand your point here, but I didn't find mixing my events and actions to be beautiful.

QUOTE

I still find the ability to click in one place and have all my code listed with descriptive headings and able to jump to any using the pop up menu saves me a lot of time.

And I find having one place to find all my UI and asynchronous events, as well as another to find all my actions to save me a lot of time. It is very true that with questions of this nature it is very much what appeals to the programmer.

QUOTE

Anyway the ELCL architecture does not provide a solution since all tasks are delegated to the Consumer Loop and the list is just as mixed.

This is true to an extent, but the event is handled up top and the appropriate action is sent down. This provides a clean way to filter events and have a list of actions that is named for what they do -- not what they respond to.

QUOTE

Does a series of events address your concern "I found that I was trying to pack as much as possible into every event to avoid creating new events"?

Other than the fact that I find it abhorrent? I suppose so. But I am not going to create an event for every action that needs to happen. Then I have a mass of events that really aren't events. And my selection list for my Event Structure QUICKLY becomes unwieldy. Not to mention that I can't put artificial separators in the Event Structure. At least with an action structure I can have dummy separators in my enumerated type that help the developer to quickly scan through the list.

And it does NOT address the concern of having duplicate code in several events. If several events all require a certain event to be greyed out, then I will put that property node in each and every event. If I later decide that I should make it transparent, I need to find each event and change the code. If I then decide that for some of those events I need to make a different control visible I add that code in. I find it much more readable to send a list of actions down : "Disable CONTROL" and optionally "Show OTHER CONTROL". Then any changes are made to these actions and all the events that call these actions are completely unchanged. Additionally I have a nice list of named actions that each event causes. This is much more readable than parsing the property nodes and code in the event case.

I do have to click in the bottom loop to open up any of those actions, but I would have had to click somewhere anyway.

[ned]

QUOTE(vito @ Nov 13 2007, 07:20 PM)

ned,

I see that you are not impressed with the new proposed Event Structure As State Machine (ESSM) architecture. Firstly, thanks for taking the time to show me the equivalent functionality using a conventional Event Loop And Consumer Loop (ELCL) architecture.

Sorry if I was a bit harsh in my initial reply; let me see if I can explain myself by responding to your points below. I also realize that there is no one ideal architecture for every program, and that your approach may be a good fit for your applications.

QUOTE(vito @ Nov 13 2007, 07:20 PM)

My objective is to put up for consideration a simple, effective and expandable architecture for LabVIEW programs. The ELCL architecture requires queues to be established, wired up and destroyed and an additional loop. So it's not as simple, therefore it needs to have other advantages to make up for the loss of simplicity.

I'd like to now address each of the disadvantages that have been mention for the ESSM architecture:

1) My primary criticism is that this isn't LabVIEW - you have broken any sense of dataflow.

Maybe I'm missing something here, but whether you put an action into the (invisible) Event Queue or a queue that the programmer explicitly established, dataflow is broken. And to the same extent. I don't see any difference between the ESSM and ELCL architectures in terms of dataflow breaks.

While using a queue does break strict dataflow, I find it easier to follow what is happening because there is a clear connection (a wire) between the two loops, between the enqueue element and dequeue element. There's no guesswork as to what happens when a value goes into the queue. Also, if you look at the example code I wrote, you'll see that chaining multiple actions together does happen in a strict dataflow way, through the use of shift registers.

QUOTE(vito @ Nov 13 2007, 07:20 PM)

2) It is impossible to probe a wire to see the sequence in which your states execute.

The "LED panel" provides this information and in a better form than a text string. This is because the "LED panel" is graphical. You can see LEDs flash and note their occurrence and order a lot better than strings that flash up.

I disagree about this, but perhaps it is a matter of preference. A single string takes up much less space, and if you want to have booleans you still have that option although it requires more coding. A definite advantage of the text string is that it is unique. Let's say one of your event cases hangs up somewhere, but several of your booleans are true (either because you've caused a value change event on one in your event case, or you've forgotten to clear a boolean in a previous state, or you accidentally selected a property node for the wrong boolean). How do you know which case you're in? With an enumeration this is never an issue.

(... as an aside, in your template code, you could simplify by using the reference provided in the event data node to clear your boolean, rather than using an explicit property node ...)

QUOTE(vito @ Nov 13 2007, 07:20 PM)

3) If a user event occurs in the middle of one of your event sequence chains (one case triggering another) you'll lose the ordering and will have trouble following what happened.

Whether you handle user events in the Event Structure or delegate them to a Consumer Loop, if a user event occurs it will equally interrupt the ordering.

Please take a look at the example code I posted and note that this is not the case: only in the Idle state do I dequeue actions, so if several states all chain together they are guaranteed to execute uninterrupted in that order. However, I could also chain events together by enqueuing them, and still guarantee execution order by inserting them at the beginning of the queue (as opposed to the event structure which would insert them at the end), something that is not possible in your model. At any time I can examine the entire contents of the queue using the "Get Queue Status" primitive in a separate loop for debugging purposes; in fact, if I use a named queue, I can create a new VI that obtains a reference to that named queue and view its contents without interrupting running code. Furthermore it becomes possible to modify the contents of the queue and discard them if necessary. For example, if someone clicks a STOP button, you can flush the entire queue, forcing a return to the Idle state as soon as the action in progress completes. When you use LabVIEW's internal event queue you give up this control and flexibility.

QUOTE(vito @ Nov 13 2007, 07:20 PM)

4) If you ever need to split your logic from your user interface - say, you decide to move to an RT target with a remote display - you'll have to rewrite all your code.

Yes, this is a disadvantage of the ESSM architecture. However all the code will not have to be rewritten, but it will have to be cut and pasted into a new structure or the Event Structure will have to be changed to a case structure and unwanted cases removed. Not sure how hard this would be to do or how often or likely it is to happen. Haven't had a need to move my code to another target yet and I'll cross that bridge if and when I come to it.

I hope you don't find yourself in that situation. I've converted several applications to RT which depended heavily on passing a cluster of references to every front panel object through to every subVI, and because of this, separating the logic from the user interface was not simple. I think you'd find that replacing all your events would be similarly difficult.

QUOTE(vito @ Nov 13 2007, 07:20 PM)

5) As an added benefit, other LabVIEW programmers will quickly understand what you're doing, because it's a standard pattern.

This is the subject of the topic. This is a new proposed architecture. Is it good enough to use or not? If it stands the test of the LAVA forum, perhaps it will get used. If significant holes are found in the ESSM architecture then it will disappear.

So, I'm still happy with the ESSM architecture, but I look forward to more input as I'm keen to standardise my development on a simple, effective and expandable architecture.

Regards,

I hope my comments explain why I do not think this would be a good choice for a standard architecture, and I welcome more discussion and opinions from others.

[vito]

ned,

Thanks for your insightful and detailed reply. There's one thign I didn't understand. You mentioned "(... as an aside, in your template code, you could simplify by using the reference provided in the event data node to clear your boolean, rather than using an explicit property node ...)". Which Event Data Node reference do I use and where is it wired?

Regards,

[Ton Plomp]

QUOTE(vito @ Nov 15 2007, 06:09 AM)

ned,

Thanks for your insightful and detailed reply. There's one thign I didn't understand. You mentioned "(... as an aside, in your template code, you could simplify by using the reference provided in the event data node to clear your boolean, rather than using an explicit property node ...)". Which Event Data Node reference do I use and where is it wired?

Regards,

I haven't looked at your code but I think Ned means something like this:

http://lavag.org/old_files/monthly_11_2007/post-2399-1195104981.png' target="_blank">

Where the left connector pane of the event structure returns the reference of the control that caused the event.

Ton

[ned]

QUOTE(vito @ Nov 15 2007, 12:09 AM)

ned,

Thanks for your insightful and detailed reply. There's one thign I didn't understand. You mentioned "(... as an aside, in your template code, you could simplify by using the reference provided in the event data node to clear your boolean, rather than using an explicit property node ...)". Which Event Data Node reference do I use and where is it wired?

Regards,

tcplomp understood pretty much what I meant, but I should have looked closer at your code and been clearer in my comment. I had thought that you were clearing the boolean indicators using property nodes rather than writing to them directly, for two reasons: many of your event cases have a property node in the last frame of the sequence, and as a rule I only trigger events on controls so I missed that you are using indicators. However, if you're already doing what you're doing, you can at least avoid accidentally clearing the wrong indicator by using something like this:

http://lavag.org/old_files/monthly_11_2007/post-3989-1195136758.gif' target="_blank">

[LAVA 1.0 Content]

Side Note:

I will attempt to place the control for which an event is configured in the event case itself. This alllows me to double click on the control from the FP and quickly find the event for that control.

Ben

[Ton Plomp]

QUOTE(neB @ Nov 15 2007, 04:25 PM)

I will attempt to place the control for which an event is configured in the event case itself. This alllows me to double click on the control from the FP and quickly find the event for that control.

The reverse has been easy since 8.5 (I believe):

http://lavag.org/old_files/monthly_11_2007/post-2399-1195140553.png' target="_blank">

Ton

[Yair]

QUOTE(tcplomp @ Nov 15 2007, 05:29 PM)

The reverse has been easy since 8.5 (I believe):

I'm pretty sure this has been around since 6.1, where the event structure was introduced. It's definitely there in 7.0.

Unfortunately, it doesn't change tab controls on the front panel, so if the control(s) are not in the currently visible tab page, you will only see their outlines. Still, I find it useful.

[hviewlabs]

QUOTE(EJW @ Nov 14 2007, 05:03 AM)

When it comes down to it, a State Machine IS nothing more than a hard-wired Event Structure. Your data flow still flows to a decision maker which dictates what the next STATE (EVENT) will be.

Verbage appears to be the only hurdle here as to what it is called, an event or a state. The two really are the same albeit handled a bit differently.

Actually, keeping notions for state, event and action separate helps creating more flexible yet uniform architectures:

http://forums.lavag.org/Simple-Event-Drive...imer-t4687.html

The above architecture/pattern doesn't support hierarchical states though. LabHSM does (made 4 years before NI's Statecharts "module", mind you)

[mross]

QUOTE(hviewlabs @ Nov 15 2007, 07:44 PM)

Actually, keeping notions for state, event and action separate helps creating more flexible yet uniform architectures:

http://forums.lavag.org/Simple-Event-Drive...imer-t4687.html

The above architecture/pattern doesn't support hierarchical states though. LabHSM does (made 4 years before NI's Statecharts "module", mind you)

Hi Stan,

I am with you. If you don't have the vocabulary, then you can't manage the complexity that is possible in reactive systems.

During an intial state an event occurs which triggers an action that transitions the system to a new state that endures.

States have duration, this is their essence. What goes on during the state is exceedingly broad, it could be randomness - like white noise, or it could be no occurrences outside a range, or a count not having been achieved, but the common factor is a time duration.

The other words event, action, and transition do not have duration in all instances. Also the context is important. From the POV of a program, we often model events, actions, and transitions as having zero duration or at least a duration not worth consideration.

An event is a concurrence of states or other events, but may or may not have duration.

An action implies some intent which may or may not be successful, but a state does not have this property.

A transition has an associated transfer function. A state does not. A transition in a program may be viewed as instantaneous.

So events, actions, and transitions are distinct from states.

We can talk about a state of change or a transition state, but this just blurs what a state is in the context of programming.

Mike

PS - I have two references that are worth looking at. David Harel's (The Weismann Institute of Science) paper, "Statecharts: A Visual Formalism for Complex Systems," and "State Machines and Statecharts by Bruce Powel Douglass, PhD. (i-Logix). I think Stan or Paul Sullivan gave me these.

[hviewlabs]

QUOTE(mross @ Nov 16 2007, 11:52 PM)

PS - I have two references that are worth looking at. David Harel's (The Weismann Institute of Science) paper, "Statecharts: A Visual Formalism for Complex Systems," and "State Machines and Statecharts by Bruce Powel Douglass, PhD. (i-Logix). I think Stan or Paul Sullivan gave me these.

Yep. I did. I have them on the following page, as well as the link to Dr. Samek's excellent book that was my inspiration for LabHSM:

http://labhsm.com/links.htm

[EJW]

QUOTE(ned @ Nov 14 2007, 01:04 PM)

::SNIP:: I hope you don't find yourself in that situation. I've converted several applications to RT which depended heavily on passing a cluster of references to every front panel object through to every subVI, and because of this, separating the logic from the user interface was not simple. I think you'd find that replacing all your events would be similarly difficult ::SNIP::

I think one of the problems people are having here is that everyone assumes that all design patterns are created equal. Such as, they all HAVE to be able to be used in all sizes of programs.

A simple program, that does not do a whole lot, that only takes 1 programmer a month or less to write, could benefit from using the EVENT Structure as a state machine.

I have written programs that only require a day or two of programming, and writing it as a state machine took up most of the time. I did rewrite one as an event machine and not only was i able

to get it to work right without a bunch of hoops to jump through, it took me only half a day or less!

I agree a complex program that has hundreds of subvis that several people have worked on for 3 years would probably NOT work using the Event Structure. However, some of the failings

of the structure could be overcome by pushing the R&D guys to make a few changes. These changes could include;

1.. 'Lock Event' option on any event case, including user events

2.. 'Flush Events' , think about, if you "created' an event structure in labview, it would be a queued state machine, without the ability to use flush, and deque.

3.. 'Discard Event' on ALL events.

4.. Built in error event that could be called, with the option to resume where you left off once the error is handled

5.. Anything else that would ease the transition from a standard state machine to an event machine.

[ned]

QUOTE(ned @ Nov 13 2007, 09:31 AM)

See attached example. I think you'll see it's easier to set up, read, expand and debug.

Someone asked me by personal message for this file saved as 8.0, so I'm adding it here.

http://lavag.org/old_files/post-3989-1196442371.vi'>Download File:post-3989-1196442371.vi

[PeterB]

I'm reviving this thread to ask for ideas on how I can prove that using an Event Structure as State Machine (ESSM) using Value Signalling of Booleans (VSB) to change states is a bad idea using objective evidence.

Ideally I'm after ideas that I can code up in LV which show how an ESMM+VSB saturates one core on a CPU (making the FP unresponsive to user interaction). Its performance is then to be compared to an alternative architecture such as a Queued State Machine. All comparative tests to be run at say 1kHz in order to give a worst case scenario. One can easily achieve 1kHz by running 10 loops in parallel at 10ms loop time each, where each loop sets the value signalling property of a different boolean on the FP. I did this test at 1kHz and it surprised me when the UI was still responsive to my mouse presses.

I had one idea while I was typing this up. I am going to run say 10 of these ESSM+VSB in parallel sub-vi's to see how problematic it is. Up until now I only had just one ESSM+VSB and was trying to break it at 1kHz. Rather than show you the code right now, can you come up with an idea for me to try along these lines ?

My agenda is to discredit the idea of an ESSM+VSB because there are many reasons I don't like it, and I am declaring my bias against it. The reason I'm seeking this evidence is that I am being asked by my colleague to demonstrate using objective evidence why it is an unsuitable architecture to employ before enshrining it into a template/design pattern here at work for any size (small and large) project .

Here is my list of Cons:

• Changing states causes a context switch into the UI thread.
  ("so ?" comes the reply to my concern, "LV is efficient enough and today's CPUs fast enough to cope with this" !). My counter to this is in the next point.
• The UI thread(s?) only run on one core, and processor speeds aren't increasing much these days, but the # of cores are. So with many of these ESSMs running in a program (in multiple parallel tasks all in sub-vis) , the UI thread will get hammered and saturated, having no option to offload to the other cores. (note that code in an ES state doesn't necessarily run in the UI thread, but the act of changing to a new state causes a switch to the UI thread)
• Parallel programming is therefore discouraged as eventually the state changing requests will saturate the UI thread(s?)
• It looks unprofessional to have your FP/GUI activity (i.e. graphs/leds/text etc) stammer/freeeze/get jerky when one moves ANY window on the desktop.
• One can't probe states queued into the Event Structure (ES) prior to each state being transitioned to.
• Upon an error condition, to prevent already queued states from executing one must have a case structure in every event case to bypass code on error because one can't enqueue an Error State at the front of the ES queue and then flush the remaining queued states.

rgds

[K-node]

I'm reviving this thread to ask for ideas on how I can prove that using an Event Structure as State Machine (ESSM) using Value Signalling of Booleans (VSB) to change states is a bad idea using objective evidence.

Ideally I'm after ideas that I can code up in LV which show how an ESMM+VSB saturates one core on a CPU (making the FP unresponsive to user interaction). Its performance is then to be compared to an alternative architecture such as a Queued State Machine. All comparative tests to be run at say 1kHz in order to give a worst case scenario. One can easily achieve 1kHz by running 10 loops in parallel at 10ms loop time each, where each loop sets the value signalling property of a different boolean on the FP. I did this test at 1kHz and it surprised me when the UI was still responsive to my mouse presses.

I had one idea while I was typing this up. I am going to run say 10 of these ESSM+VSB in parallel sub-vi's to see how problematic it is. Up until now I only had just one ESSM+VSB and was trying to break it at 1kHz. Rather than show you the code right now, can you come up with an idea for me to try along these lines ?

My agenda is to discredit the idea of an ESSM+VSB because there are many reasons I don't like it, and I am declaring my bias against it. The reason I'm seeking this evidence is that I am being asked by my colleague to demonstrate using objective evidence why it is an unsuitable architecture to employ before enshrining it into a template/design pattern here at work for any size (small and large) project .

Here is my list of Cons:

• Changing states causes a context switch into the UI thread.
  ("so ?" comes the reply to my concern, "LV is efficient enough and today's CPUs fast enough to cope with this" !). My counter to this is in the next point.
• The UI thread(s?) only run on one core, and processor speeds aren't increasing much these days, but the # of cores are. So with many of these ESSMs running in a program (in multiple parallel tasks all in sub-vis) , the UI thread will get hammered and saturated, having no option to offload to the other cores. (note that code in an ES state doesn't necessarily run in the UI thread, but the act of changing to a new state causes a switch to the UI thread)
• Parallel programming is therefore discouraged as eventually the state changing requests will saturate the UI thread(s?)
• It looks unprofessional to have your FP/GUI activity (i.e. graphs/leds/text etc) stammer/freeeze/get jerky when one moves ANY window on the desktop.
• One can't probe states queued into the Event Structure (ES) prior to each state being transitioned to.
• Upon an error condition, to prevent already queued states from executing one must have a case structure in every event case to bypass code on error because one can't enqueue an Error State at the front of the ES queue and then flush the remaining queued states.

rgds

I am no expert on this, but wanted to point out AQ's response to where Event Queues run. In short, it is not necessarily in the UI Thread.

[PeterB]

I am no expert on this, but wanted to point out AQ's response to where Event Queues run. In short, it is not necessarily in the UI Thread.

Thanks Kugr, I already pointed that out in my post when I wrote "(note that code in an ES state doesn't necessarily run in the UI thread, but the act of changing to a new state (ed. via VSB) causes a switch to the UI thread)".

BTW I'd still appreciate any more major cons or coding ideas to throw against this ESSM+VSB proposal. My attempts to run 10 ESSM+VSB in parallel with their states changing every 10ms (for a total of 1kHz) didn't choke the UI thread. It took about 15-20 running in parallel at a total of 1.5kH-2kHz to saturate the UI thread. So, I guess if one assumes a safety buffer of 50% (1kHz*150%=1.5kHz) , then 1kHz is the upper limit for running such an architecture, but I had hoped it would be more down in the hundreds of Hz (i.e. a total of hundreds of state changes per second across the entire application) which is more of a realistic use case for a large application.

regards

[Val Brown]

"...I had hoped it would be more down in the hundreds of Hz (i.e. a total of hundreds of state changes per second across the entire application) which is more of a realistic use case for a large application"

DId you really HOPE for a lower rate choking the UI thread or was it the assumption that a lower rate WOULD choke the UI thread that originally drove your concerns about the alternative architecture? Maybe I'm missing something here but this sounds like a good outcome for most LV users.

Edited July 12, 2011 by Val Brown

[PeterB]

"...I had hoped it would be more down in the hundreds of Hz (i.e. a total of hundreds of state changes per second across the entire application) which is more of a realistic use case for a large application"

DId you really HOPE for a lower rate choking the UI thread or was it the assumption that a lower rate WOULD choke the UI thread that originally drove your concerns about the alternative architecture? Maybe I'm missing something here but this sounds like a good outcome for most LV users.

Yes, I hoped it would choke at realistic rates of a few hundred Hz because I am trying to show somebody here at work how much of a bad idea it is. I am openly and subjectively biased against the idea of using Value Signalling Booleans to change states in an event structure. (my preference would be to get them to use User Events, but they think those aren't simple enough for a new LV programmer to understand - bah!)

Using VSB in this fashion goes against so much of what I have learned about LV (i.e. that it is important to reserve the UI for UI stuff) that I'm sure it must be a bad idea. It is my job to convince another person where I work that it really is a bad idea using objective measures otherwise I have less legs to stand on as I oppose his efforts to use this in a template/design pattern for many of our future projects. Surely I'm not the only seasoned LV programmer for which this template rubs them up the wrong way !!

Help me out here guys, I need ammunition to oppose this evil idea.....

rgds