Wrong context menu displayed in state diagram editor

[becktho]

Hi all

Just recently I discovered a strange behaviour. When editing a state diagram I get the wrong context menu. If I want to add a state, I right click in the white area. Usually the menu should just contain one item (New State). Now I see the menu as you can see in the picture. I absolutely don't understand why. I repaired LV as well as the State Diagram Toolkit itself, but no change in behaviour.

I can work, but as you might understand it's absolutely annoying.

Maybe there is one out there who can help me.

Thomas

Message Edited by becktho on 08-26-2008 02:25 PM

[becktho]

Hi all

Finally I could manage to solve it on my own. I "just" had to disable the web server in the LabView development environment.

Would still be interesting to knwo why the enabled web server influences the state diagram toolkit.

Thomas

[TCPlomp]

Thanks for the workaround, I think this is one of the reasons NI ditched SDE (unfortunatly).

Ton

[Ben]

---

becktho wrote:

...

Would still be interesting to knwo why the enabled web server influences the state diagram toolkit.

Thomas

---

The SDE user interface is just a Picture Control with enough scripting behind it to manage the states and their transitions.

The options you saw were the standard option available on control when the web-server is enabled.

It would have been interesting to know if it acted the same way if working form the project as opposed to outside the project.

I think the SDE was dropped because someone decide the State Chart was the same only better. (far from it!).

Ben

[becktho]

Hi Ben & TonP

Both of you say that the SDE was dropped. As I still use LV8.0 I did not know this.

Is there the possibility to edit SDE-VIs with the State Chart? If I switched to the latest LV-version - are my state diagrams "lost"?

Thomas

[Ben]

You can still get a copy of the SDE but it no longer ships with the Developers Suite.

No the SC does not let you get at your SDs.

I last used in in LV 8.2 and it worked fine. I have not to use it since then.

Ben

[becktho]

Well that sounds not that good. As we get these update packages every three months, I don't want to look for a separate toolkit which is not included in the developer suite.

And as I have a few vi's using the sde, this might be the source for a little work. Either get rid of the complete SDE/SC topic or switch to the SC at all.

We'll see what I'm gonna do...

Anyway - thanks for your support Ben.

[geirove]

---

Ben wrote:

The SDE user interface is just a Picture Control with enough scripting behind it to manage the states and their transitions.

The options you saw were the standard option available on control when the web-server is enabled.

It would have been interesting to know if it acted the same way if working form the project as opposed to outside the project.

I think the SDE was dropped because someone decide the State Chart was the same only better. (far from it!).

Ben

---

NI ditching introduced tools after just a few years shows NI's lack of support for serious (long term) work done in LabView. I have customers ditching LabView beacuse of this attitude, and going back to PLS platforms.

For us, the State Diagram Toolkit is an essential part of how we write software. As Ben says, the StateChart Module is NOT a replacement for the State Diagram Editor:  There are multiple problems with The State Chart Module:

1) You cannot port existing applications (Where's the Respect for previous work done in LabView ?)

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!

3) It generates code that uses way to much memory: We tried to port 12 State Diagrams that where running on a cFP 2120 with 128 MB memory: It had 40 MB free memory running the State Diagrams. We ran out of memory after porting 6 State Diagrams to State Charts. And WHY should we have to do this work manually?

Debug Mode does not work in the State Diagram Toolkit when running the app from a Project: You have to use a "Main Application Instance", which does not always work for us because we loose the Project Settings (Conditional Disable Symbols).

We have reported this Bug, and it should have been an easy fix. It never gets fixed, like other bugs reported against the State Diagram Editor. Instead NI keeps pushing ever more new features: Who dares to use them? When will they be ditched? Where's NI's commitment to existing customers?

Geir Ove

[aggieNick02]

I have a few comments to try to help with the frustration:
 
First, while the SDE is not actively sold/shipped anymore, it still does work. If you have developed apps with the SDE, we have not required an upgrade or migration to the new Statechart Module (SCM). However, the Statechart Module is a much more powerful and full-featured tool within which to develop state machines. If there is something that the SDE lets you do that the SCM does not, then that is something we need to work on. We eagerly will listen to and try to act on your feedback.

To the specific points:

---

@geirove wrote:

1) You cannot port existing applications (Where's the Respect for previous work done in LabView ?)

---

We have given serious thought to this. The problem is that it the interfaces for a SDE entity and a Statechart are not the same. If you understand the semantics of statecharts and state diagrams, it is a fairly straightforward process to translate one to the other. However, it is not an easily automatable thing. I agree some guidance from us on how to perform a migration would be useful.  

---

@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.

---

@geirove wrote:

3) It generates code that uses way to much memory: We tried to port 12 State Diagrams that where running on a cFP 2120 with 128 MB memory: It had 40 MB free memory running the State Diagrams. We ran out of memory after porting 6 State Diagrams to State Charts. And WHY should we have to do this work manually?

---

If you can provide some examples of a state diagram that "explodes" when turned into a statechart, they would be extremely helpful and allow us to do what we can to make things better in a future release. I can understand your frustration at something like this. If you are able to provide examples, you can either post them here or we can get in touch privately if you prefer to not post files publicly. Please let me know.

---

@geirove wrote:

We have reported this Bug, and it should have been an easy fix. It never gets fixed, like other bugs reported against the State Diagram Editor.

---

The SDE was developed before the introduction of projects and application instances, which is probably why it has this issue. I can understand that this issue is frustrating/annoying.

[Ben]

---

aggieNick02 wrote:

...

---

@geirove wrote:

3) It generates code that uses way to much memory: We tried to port 12 State Diagrams that where running on a cFP 2120 with 128 MB memory: It had 40 MB free memory running the State Diagrams. We ran out of memory after porting 6 State Diagrams to State Charts. And WHY should we have to do this work manually?

---

If you can provide some examples of a state diagram that "explodes" when turned into a statechart, they would be extremely helpful and allow us to do what we can to make things better in a future release. I can understand your frustration at something like this. If you are able to provide examples, you can either post them here or we can get in touch privately if you prefer to not post files publicly. Please let me know.

...

---

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"*.

Just trying to help,

Ben

* If I had a good way to work in-place in a SC I'd start using it myself.