BACK by popular demand The LV State Diagram Editor! well I can dream can't I?

[Ben]

---

@RTSLVU wrote:

OMFG I never knew such a thing existed!

I WANT IT and I want it NOW!

That would make my life so much eaiser as probably 99% of my programs are a state machine.

---

Then PLEASE Kudo the Idea Titou post in the Idea Exchange.

With enough support we may get this excelent tool back into the mainstream.

Thank you!

Ben

[StephenB]

(Not a member of R&D)

Just curious... What about the module is unsatisfying?

[Ben]

TiTou wrote

---

I've created the idea.

---

WE piced up 13 Kudos on Friday and another 14 over the week-end for a total of 27 as of this AM.

Great start!

Thank you!

---

Stephen B wrote:
(Not a member of R&D)

Just curious... What about the module is unsatisfying?

---

0) Look at the post above by "RSTLVU" where they indicated they never new of such a thng but just one image has them saying

"

I WANT IT and I want it NOW!

That would make my life so much eaiser as probably 99% of my programs are a state machine.

"

So the power of the SDE is readily apperent. I have been poking computers for 36 years and the State Chart is still a diagram I can not read without first refamiliarizing myslef with the what is  Guard arghhh! in my day to day work I am not trying to get bonus points from some foramt CS type for how well I adhere to theory. I am interested in developing efficient code that clearly communicates what it does. I can use the SDE diagrams in formal designs were non-CS types can read and understand them.

THe get an idea of what the SDe was cpable of doing plese DOWNLOAD and look at the "SystemArchitecture5.ppt" that I attaced to reply #22 of this thread. I ask you to down load it so you can view the notes that go with each diagram in that doc. What you will find a complete design for an app cpable of charaterizing Thermophotovoltaic diodes using a rach-n-stack Agilent gear.

Then compare that design with an earlier design of mine that was done without the SDE "Application Design Rev A2.doc". What you should see a similar format approach and design. The second (designed earlier) was done using PowerPoint and I had to manually recreate the designs in LV. If I had to tweak the design, I would have to go back to the PP doc and update it. In the case of the SDE version, my documentation in the application was updated at the same time the code was changed.

THe approach you see used in those design...

Is the same design approached used to to document the Missle FIre Control Systems that I cut my teeth on when in the Navy, before Mealey and Moore were uttere in my presense.

1) Requires a CS degree to use it. All of the rules that resulted in the State Chart are just TOOOOO formal. Who cares if it "Meely or Moore" (spelling always questionable but those are the name I think goes with the frmal theory of what is a state what is a transition blah blah blah).

2) TOO restrictive! have to use the goofey window to develop the code that us is used.

3) Developed without an interest in performance. Sure it was supposedly "fixed" but since the ... stupid thing restricts me on how I handl e my code I can not count on being able to "fix" it myself. My code often demands performance either now or in the future and it seems a fools bet to tie my hands out of the gate.

4) Again reading the diagram requires a CS degree to understand the terminology.

I am sure I can think of more.

tst wrote;

---

I have no idea what the official reason was, but one good reason was that it uses external nodes. Those were abandoned when XNodes were introduced (which will themselves apparently be abandoned for some future tech). Maybe NI didn't want to bother rewriting it or supporting old tech.

---

There may have been other resons like bugs in the orignal that would require re-work even if all of those tiems you mentioned were OK.

For those who are not familiar with the XNodes...

An XNode is like an XControl but it lives on the Block Diagram. Both have the ablitity to run at edit time and in the cse of the SDE (State Diagram Editor), it would wire up your block diagram to math-up with the State Diagram you were drawing. A liitle trivia to go along... The first version of the SDE was realased withut password protection. WHen found it play a part in opening up scripting to those outside the Ivory Tower.

Thank you very much to those have added a Kudos in the Idea Exchange!

Ben

[Ben]

Re; CS types

I should clarify.

I have nothing against CS types. My wife earned a masters in CS and we get along fine. My reference in the above posts about CS are intended to refer to those that have studied computers science formally and have been exposed to the theory.

i hope that lcears that point up.

Ben

[JB]

Initially you had to buy the SDE separately. After about one year (?), this very useful toolkit became part of the LV installer and shipped for free. At this time, I began to use it intensely and have now developed many applications with it.

Unless I'm wrong, NI abandoned the SDE when they released the Statechart Module. That's why I suppose they tried to compel us to buy this new and very expensive module. I gave it a try some years ago. This module is very powerful but really not a replacement for the SDE.

Because the SDE is no longer supported (but it still works up to LV 2011 SP1), I use the JKI State Machine for new applications but I have to maintain many VIs using the SDE.

[SteveChandler]

---

WE piced up 13 Kudos on Friday and another 14 over the week-end for a total of 27 as of this AM.

Great start!

Thank you!

 Ben

---

Not bad. Since we can only kudo an idea once, it might be a good idea to also comment on the idea. I think the discussions must play a more important role in decisions than the number of kudos. It is probably a good idea to be specific as to why it is a good idea and not a simple "mee too!".

[Ben]

---

@Steve Chandler wrote:

... It is probably a good idea to be specific as to why it is a good idea and not a simple "mee too!".

---

Good point!

I added some more comments to the idea this morning. looking at those that added Kudos to that idea ... a virtual who's who of LV.

For the sake of completenes I will copy and paste my "Ode to a State Diagram" below (orignal thread is here).

---

 Part two of two.

Start of Ben's "Ode to a State Diagram"

I love thee state diagrams, let me count the ways (W. Shakespear ?).

I develop the designs of most of the applications that come out of my shop. This means that I have to start with a bunch of "fluffy cloud" pictures my customers give me into a set of requirements for VI's that will be developed to implement the solution. The state diagrams I devlelop help me "catch a cloud and pin it down" (How do You solve a Problem Like Maria?", Sound of Music).

State diagrams are great for documenting in an understandable form what an application will do before it is developed.

They serve as guides to discussions of the approaches that will be used. This is when I tell customers, "See,the data will not be saved until you hit save, if there is a power failure before that, the data will be lost. Are you OK with that?"

Once refined and accepted the designs then serve to control scope creep. Any request that requires the State Diagrams (SD's) be changed, is big warning that the scope is changing.

The SD's also jump start the code requirements! As I document what needs done in each state of the application, I am in effect describing what the code that executes in that state is required to do. Each state can (depending on the complexity) become a unique sub-VI who's VI documentation is the documentation for that state.

The discusion of a sub-VI's functionality is never complete without a mention of the data coming into it and the data it returns. This is where the SD drives the data analysis portion of the design. LV after all does implement a data flow paradim (sp?). No code in LV can be implemented properly without concideration being given to dataflow. While specifying the functionality of a state, I am asking myself
"Where am I going to keep that I/O reference?",
"Where is it needed?",
"Who is going to be writting to it?",
"Is this going to be a memory pig?",
etc.

The results of this questioning lets me structure the applications data. (This is another story)

So...

When I am done with the SD and everything is documented, I end up with an application I can then turn over to developers that may not understand the complexities of the application, but can develop all the required sub-VI and have them all work together as expected.

General Note:
The image included is a screen shot of the LabVIEW State Diagram Editor (SDE). The SDE is not required to devlop SD's but simplifies their development. I have used paper and pencil to develop SD's for code written in C. MS Paint and MS PowerPoint for LV before the SDE was released.

The SDE in its current form is primative.
It does not have a "undo". You can not select more than one object at a time and allign them. You can not have more than one SDE screen open at a time (in LV 7.1).
It is primative.

Having said that, let me go on to say,

It is great!

It has simplified my life greatly.

I now can work in a LV environment. I do not have to edit diagrams in PP and then import and paste in diagrams. They are included.

I can watch my ideas in execution highlighting more where my "fluffy clouds" come to life.

I can quickly move from the design view of the SDE to the LV code by clicking on a state or one of the transitions.

I can step into someones cube that is "drawing up my clouds" and quickly figure out why those "lightning bolts" are coming from.

Warning:
SD should not be over-used! They are an excellent way to slow down your code. If you can "see" the LV code, write it in LV!

SD's and event structures do work together but "These things must be done delicately" (Wicked Witch, Wizard of Oz).

I hope this helps,

---

Thank you,

Ben

[danil33]

Quite Interesting

Hope we may be able to bring it back

[Ben]

Well it looks like we are still moving up.

Thanks to all.

I noticed this week-end that Jeff Kodosky (The Father of LabVIEW) has added his kuods to the idea.

So now that idea's Kudoers are truely part of the "Who's Who of LabVIEW".

Are YOU art of that list?

This is your chance.

I'll try to post some more ideas to support the SDE in the idea thread.

Ben

[danil33]

---

I noticed this week-end that Jeff Kodosky (The Father of LabVIEW) has added his kuods to the idea.

---

Wow! It's a good news