Transition priorities

[James Christensen]

There is an active discussion in the 61499 Maintenance Team about
transition priorities - 61499-1 says that transition conditions
following the active step are evaluated in the order in which they
appear in the Src or XML declarations, but there is no prescribed
graphical notation for showing the order of transition evaluation. The
consensus so far appears to be that this is a "tool issue" to be
described as an example in 61499-2. So I was wondering, what kind of
representation might a tool use? One possibility is to precede the
transition condition in the graphical ECC with its priority number in
some kind of bracket. I tried angle brackets, but these did not look
so nice; curly brackets seem to look a bit better. Attached is a
(trivial) example. Does this look OK to you, or do we have to go for
something more difficult like a number next to the origin of the
transition line where it emerges from its source EC State?

Best regards,
Jim C

[James Christensen]

See attached figure - a little less trivial example - Jim C

--
Best regards,
Jim Christensen

[Eccles]

That looks ok to me.
The only other thing you might do is display the priority with
mouseover text - but of course that won't print.
Maybe (?) omit the number if there if there is only one condition.
Displaying the number with the condition is logical.
You'll risk layout problems if you try to put it somewhere else.
FWIW ...
Neil

On Sep 15, 12:31 pm, James Christensen <james.h.christen...@gmail.com>
wrote:

> See attached figure - a little less trivial example - Jim C
>

>  E_DEMUX.png
> 5KViewDownload

> Jim Christensen- Hide quoted text -
>
> - Show quoted text -

[James Christensen]

Thanks for the suggestion, Neil. Attached are the examples with this
implemented. It does make for less clutter and more clarity. It's fun
to watch the transition priorities change when I use the Move Up/Down
buttons! But then I am easily amused.

I had also thought of maybe not showing priorities when transition
conditions are mutually exclusive. Then I thought better of it because
that may actually conceal the user's intent, e.g., to evaluate the
most frequently cleared transitions first for run-time efficiency, for
instance in the "Basic" example where INIT might occur only once or
twice, but REQ may happen many times, e.g., if it is being fired
periodically.

--
Best regards,
Jim Christensen

[Eccles]

Nothing beats being amused (genuinely amused) by your own
creations ... ought to me more of it. Einstein's "happiest thought"
was entirely his own.

Yeah ... and trying to determine mutual exclusivity, in the general
case, could be harder than it first seems (?)

Cheers,
Neil

On Sep 16, 11:34 am, James Christensen <james.h.christen...@gmail.com>
wrote:

> Thanks for the suggestion, Neil. Attached are the examples with this
> implemented. It does make for less clutter and more clarity. It's fun
> to watch the transition priorities change when I use the Move Up/Down
> buttons! But then I am easily amused.
>

>  Basic.png
> 1KViewDownload
>
>  E_DEMUX.png
> 3KViewDownload

> >> > Jim C- Hide quoted text -

[Alois]

Jim,

would it be possible to give the priority numbers and the brackets a
different backround color and/or formatting (e.g., italic, or a little
smaller and up shifted like a square sign).
This would better show that it is not part of the transition
condition.

Maybe it would be also good to allow to select with a preference
option of priorities should be shown. So that people can focus on the
general ECC structure if necessary.

Just my first thoughts on this issue.

Best Reagards,
Alois

On Sep 16, 3:34 am, James Christensen <james.h.christen...@gmail.com>
wrote:

> Thanks for the suggestion, Neil. Attached are the examples with this
> implemented. It does make for less clutter and more clarity. It's fun
> to watch the transition priorities change when I use the Move Up/Down
> buttons! But then I am easily amused.
>
> I had also thought of maybe not showing priorities when transition
> conditions are mutually exclusive. Then I thought better of it because
> that may actually conceal the user's intent, e.g., to evaluate the
> most frequently cleared transitions first for run-time efficiency, for
> instance in the "Basic" example where INIT might occur only once or
> twice, but REQ may happen many times, e.g., if it is being fired
> periodically.
> --
> Best regards,
> Jim Christensen
>

>  Basic.png
> 1KViewDownload
>
>  E_DEMUX.png
> 3KViewDownload

[James Christensen]

Have a look at the attached examples. To me, it looks like just doing
the priorities in gray on white makes them unobtrusive enough so that
we shouldn't need an option to suppress them. Ain't RAD fun?

--
Best regards,
Jim Christensen

[James Christensen]

Oops, the first example with unselected nodes didn't attach right.
Here's another try...

[Eccles]

I would call that a useful improvement.
Neil


On Sep 19, 6:11 am, James Christensen <james.h.christen...@gmail.com>
wrote:

> Oops, the first example with unselected nodes didn't attach right.
> Here's another try...
>

>  Basic.png
> 1KViewDownload

> >>> >> > Jim C- Hide quoted text -

[James Christensen]

Per Alois's suggestion, I've also added a "drawingStyle" option to the
Preferences. If the "Plain" drawing style is chosen, the transition
priorities not drawn, and the background color for non-selected
elements is white instead of the bluish-gray. With that style I can
produce plain vanilla drawings for the new draft of the Standard.

With the "FBDK" style, the grayish shading will be used for elements
that can be selected (non-selectable elements will have the plain
white background), and transition priorities will always be displayed.

--
Best regards,
Jim Christensen