state diagram editor discontinued

[aggieNick02]

---

Ben wrote:

Hi Nick,

I hope you are not suprised to see me responding to this thread.

ANY SDE code that uses large data sets and takes advantage of "working in-place" to ensure multiple buffers are not required should demontrate this issue. Unless there is something that I am missing, there is simply no way to for multiple state of a SC to work on the same data "in-place"*.

---

Hi Ben,

Not at all surprised... I think I would be worried if you did not respond.

We fixed an inplaceness issue in the LabVIEW Statechart 8.6 release that should allow for working inplace (as long as all of the code you write is also in place, of course). Have you tried that and still had problems? We did a bit of testing with very large data sets and some code analysis to verify that the structure of our statechart "machine" was indeed inplace in 8.6.

(Genuine) thanks for helping Ben.

- Nick

[Ben]

---

aggieNick02 wrote:

...

We fixed an inplaceness issue in the LabVIEW Statechart 8.6 release that should allow for working inplace (as long as all of the code you write is also in place, of course). Have you tried that and still had problems? We did a bit of testing with very large data sets and some code analysis to verify that the structure of our statechart "machine" was indeed inplace in 8.6.

(Genuine) thanks for helping Ben.

- Nick

---

Way cool!

Now I'll have to try it again.

Ben

[aggieNick02]

Sorry about that Ben... you were the person that notified us of the issue so in some sense we fixed it "for you", so we should have communicated that it was actually fixed (I guess that message got lost somewhere). It is now fixed, so I hope it allows you to get more out of the module.

Thanks,
Nick

[geirove]

---

aggieNick02 wrote:

I have a few comments to try to help with the frustration:
 

---

geirove wrote:

2) It generates closed code (Not open LabView code), so you cannot search for references to VI's, globals etc.: You cannot navigate your code!

---

The semantics of statechart execution are complicated enough that the code we generate to run your statechart is not as transparent as the simple SDE-while loop with shift register/case structure/etc . The code you write (guards and actions) is still open and easily editable. You are correct that searching for references to VI's, globals, etc. in guard/action code does not work. We are working on making this better.

---

This is very serious: If you cannot navigate your code, you are lost in anything but the smallest demo program!

As for feedback: I sent more than 10 messages to  'Ching Phuong' last year detailing what was wrong with the StateChart Module, and why NI should keep the StateDiagram Toolkit. Nothing good came out of this as far as I can see.

Once again, I will beg NI to keep BOTH the StateDiagram Toolkit and the StateChart Module, as they serve different purposes.

And please fix the few bugs that are in the Toolkit: It will take any of your very capable programmers just a few days to do. 

I have said this before, but it cannot be said to many times: Introducing a new Tool or Feature puts a lot responsibility on NI: NI cannot simply remove a feature introduced a few years ago: What about the poor Programmers that are trying to support systems out there using these Features / Tools? 

Ditching the State Diagram Toolkit (or any introduced feature / tool) is a very bad Business decision: Who can then trust new features or tools: When will they be ditched? How can we  bet our business on using these tools?

I recently had to do some changes to a 20 year old PLS program. I had to buy a new version of the development environment: But guess what? No problems: Project compiled ok and I fixed the problem in matter of hours! That's what I call dedication; the kind of dedication the process industry we are serving relies upon.

The day LabView does not support the State Diagram Toolkit, my company will stop buying new versions of LabView: It is core to our business. We have developed a pattern for using that we so far have used in every project with great success.

[hurban]

hi geirove

I totally share your frustration about dropping this little tool that was ever so helpful for those who need to write well documented code that can be supported long-term. This is what our customers in the process control business expect and deserve !

It is good to know that there are a few others out there too who are as annoyed as I am about the situation. I will speak to our local NI-representative these days and try to push this issue a little.

regards

HU 

[geirove]

Hello,

Thanks for supporting my view! Funny, I am currently sitting here and doing 2 new Industrial Control Engineering projects using the State Diagram Toolkit (Concrete Slab Industry). One is a change to a project we finished back in 2007 using LV 8.2 and cFP 2120 modules: The Plant is moving to a new location, and changing the setup: It is NOT time or money to rewrite the complete system using the State Chart Module: Heck, it is not even possible to use LV version newer than 8.2! Why? Well if you search on Performance LV 8.2 / 8.5 and my name, you will see how National changed the RT OS (Pharlap OS) with a performance hit: Our program consumes 100% CPU power if we downloaded the 8.5 RT OS (or newer).

The second project is a new project where we use LV 2009 with the State Diagram Toolkit (SDT) installed. Why use the SDT again? To reap the fruits of all our previous work of course: We have a well proven pattern that works, and we are now able to finish projects much faster than we did before. Changing to the StateChart Module, much of this work would have to be done all over again! Whow pays for this? The Customer: No way. NI ...?! My company again (?): We have already invested considerable time and money in a framework that works: We now just have to get some payback for our investment.

Geir Ove

[hurban]

Hi again,

I didn't know about the performance drop in LV RT 8.5 ... valuable information, thanks !

Yes, its the same with me, I am using the SDT in practically every new project I start - simply because it is an ingeniously simple way of documenting the code. For example: I had a cooperation recently with a company in a distant town - me writing the real time components and they were writing the user interface (in Java). I simply sent them a screenshot of my state diagram and immediately they were able to control my logic without much further explanation - life can be so simple

Will keep you posted if there is any news on the SDT issue.

regards HU

[geirove]

Hello HU,

Forgot in my last posting this is how we do it:

http://objective.no/labview_process_control.htm

The example there uses the StateChart module, but it was abandoned! I will, when I get the time one day, redo that example with the State Diagram Toolkit, because that is what we use in the deployed code !

Got to run now: I am going up to one of the factories in Mid part of Norway (Trondheim) where we got some of stuff deployed 🙂