Skip to content

Navigation Menu

Sign in
Sign up

Enhancement Idea: Improving ECC Transition Editing Experience #2285

vikash1703 started this conversation in Ideas
Discussion options

@azoitl and @4diac community

I was exploring the ECC transition editing in Eclipse 4diac IDE and noticed one usability gap.

Right now, while defining transitions, we have to manually type everything like:
REQ [x > 10]

This works, but it has a few issues:

If an event or variable is not defined, it just shows an error (like "REQ is undefined")

There is no suggestion or help while typing

Users need to remember exact names from the interface

I tried this myself — for example, to use a condition like x > 10, I first had to manually create the variable x : INT in the Interface tab, then go back to ECC and type:
REQ [x > 10]

So overall, the flow feels a bit manual and error-prone.

I was thinking of improving this by adding a small content assist feature directly in the transition editor. For example:

When editing a transition, it can suggest available events (REQ, INIT, etc.)

It can also suggest variables (like x) and operators (>, ==, etc.)

So instead of typing everything, the user can select from suggestions

This would make it easier especially for beginners and reduce small errors.I have attached a video for refrence if we can do like this.

SampleVideo.1.mov
You must be logged in to vote

Replies: 3 comments 19 replies

Comment options

In that case, I would suggest to have a look at org.eclipse.fordiac.ide.gef.editparts.InitialValueCellEditor, where we already provide a rich editor with content-assist functionality based on Xtext. It is used, among other places, for editing initial values in the FB network editor, see also org.eclipse.fordiac.ide.gef.editparts.InitialValueDirectEditManager.

You must be logged in to vote
10 replies
Comment options

@vikash1703 the cell editor that @mx990 mentioned is normally also the basis of any pop editor in the graphical editor. So what you see in the property sheet can be the basis for bringing the same features to the canvas.

Comment options

@vikash1703 the cell editor that @mx990 mentioned is normally also the basis of any pop editor in the graphical editor. So what you see in the property sheet can be the basis for bringing the same features to the canvas.

Hi @azoitl and @mx990,
I have gone through InitialValueCellEditor and InitialValueDirectEditManager and understand the pattern. I will update my proposal accordingly.

Comment options

Hi @azoitl and @4diaccommunity

I was testing the 'Online Monitoring' in the ECC editor and noticed something. While I can see the variable values updating in the watch window, the ECC diagram itself stays static. I mean, the active state doesn't highlight or glow, and there's no visual animation on the transitions when the logic moves.

I saw nxtSTUDIO tool this tool follow same IEC 61499 standard nxtSTUDIO have this 'Live State Highlighting' which makes debugging much easier. Since I am already looking into the ECC editor's usability, do you think adding this kind of visual feedback during monitoring would be a good addition to my proposal? Or is there already some setting for this that I missed?

Comment options

@vikash1703 this would be a very good extension to your proposal. This is something that we would really need and would help our users a lot.

Comment options

@vikash1703 this would be a very good extension to your proposal. This is something that we would really need and would help our users a lot.

@azoitl Thanks for the clarification i will explore more and update you as soon as possile.

Comment options

Hi @azoitl and @mx990

So I actually went ahead and tested the online monitoring myself to understand the gap better.
I set up a simple E_RS block, deployed it to local FORTE runtime, and opened the ECC editor while it was running. The FB was live — but the ECC diagram was just sitting there, completely static. No state was highlighted, no transition moved. I had to rely entirely on the watches window to understand what was happening internally.
I then looked at nxtSTUDIO (which follows the same IEC 61499 standard) and they have this Live State Highlighting — the active state visually glows and you can literally see the logic moving in real time. I've attached both screenshots for reference.
After this I went into the source code to understand where this could be added. Here is what I found:

ECStateEditPart.java — already has a highlightTransitions() method. I think a similar setActiveState(boolean) could be added here to change the state color during runtime.
ECTransitionEditPart.java — already has a highlight(boolean) method for selection feedback. Same pattern could work for runtime animation.
ECCEditor.java — this could be the place to hook into the monitoring data and update the EditParts when active state changes.

Is this the right direction to think about the implementation? Also wanted to ask — would it make sense to include small code snippets showing this approach in the proposal?
nxtSTUDIO_refrence

4diac_image_ecc

You must be logged in to vote
0 replies
Comment options

In general you are on the right track. There a few things that I think you should know and consider:

As debugging is an add on feature we have not put it into the existing editparts or drawings. Debugging information should be on top of the existing editor and independent. With that we can independently develop both. The highlighting features that you find are helping users to edit the ECC. If we would use these for debugging and change it as the editing features change it would break debugging. Therefore we use the org.eclipse.fordiac.ide.gef.graphicalAnnotationStyle extension point to provide additional information for debugging. You can have a look at the org.eclipse.fordiac.ide.deployment.debug.ui.annotation.WatchValueAnnotationStyler for a reference how we do that in a FB network.

We have two different options for debugging:

  1. Online monitoring of running applications on 4diac FORTE instances
  2. FB interpreter and debugger inside of 4diac IDE

While the first option is very nice to see how application work it has some limitations on what a user can do (e.g., because of safety concerns we do not have breakpoints).

The second option is in respect of debugging much more advanced. There we are interpreting the FB in 4diac IDE. Therefore we have access to all variables, all intermediate results and you can perform classical debugging operations like break-points and stepping. The UI for doing this on algorithm level is already very advanced what you could look into how to bring this to ECCs.

To invoke the interpreter you can right click an on FB and select Debug As -> Debug FB Type

You must be logged in to vote
9 replies
Comment options

2. For highlighting an ECState in a diagram — what visual style would work best?
Like a colored border or glow effect?

For starting I would keep it simple. First get the basic infra up and running. A simple rectangle would just be fine. As this would then be an own editpart improving later. When that works we can discuss different options.

If this interests you can take this even a step further and think how a stepping mode in ECC could look like. That means we are in a state get an input event and we would like to step through the transitions, actions to see how transitions are evaluated and which one is taken. And if we are really fancy then when stepping into an algorithm switching to the ST code and back.

But first things first! Having the current state shown is already an amazing step forward.

Comment options

  1. For highlighting an ECState in a diagram — what visual style would work best?
    Like a colored border or glow effect?

For starting I would keep it simple. First get the basic infra up and running. A simple rectangle would just be fine. As this would then be an own editpart improving later. When that works we can discuss different options.

If this interests you can take this even a step further and think how a stepping mode in ECC could look like. That means we are in a state get an input event and we would like to step through the transitions, actions to see how transitions are evaluated and which one is taken. And if we are really fancy then when stepping into an algorithm switching to the ST code and back.

But first things first! Having the current state shown is already an amazing step forward.

Hi @azoitl and @mx990

Thanks for the detailed feedback! The whole picture is very clear to me now and this gives me a solid roadmap for my GSoC proposal.

Comment options

@azoitl

I have submitted my proposal now i am thinking to start my work and not wait for result what you think where i can start to fix the spline issue or this enhancement part ?

Comment options

We are always happy for contributions so feel free to start here. If you want you can also consider implementing a different spline if you think that would make the whole thing better.

Comment options

We are always happy for contributions so feel free to start here. If you want you can also consider implementing a different spline if you think that would make the whole thing better.

@azoitl Thanks for the support i am exploring spline part and how i make it better.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Category
Ideas
Labels
None yet

AltStyle によって変換されたページ (->オリジナル) /