variable assignment on transition influences transistion from current-state

[Pieter Smurf]

given the following state machine:

we would expect the two following state-sequences:

somefunc returns !1: A->B->C0->D

somefunc returns 1: A->B->C1->D

But, when running the following SCTUnit tests:

@Test
operation branchTest0(){
    mock ifc.somefunc() returns (0)
    enter
    assert active(main_region.StateA)
    proceed 1 cycle
    assert active(main_region.StateB)
    assert(ifc.testvar==0)
    proceed 1 cycle
    assert(ifc.testvar==1)
    assert active(main_region.StateC0)
    proceed 1 cycle
    assert active(main_region.StateD)
    exit
}
@Test
operation branchTest1(){
    mock ifc.somefunc() returns (1)
    enter
    assert active(main_region.StateA)
    proceed 1 cycle
    assert active(main_region.StateB)
    assert(ifc.testvar==1)
    proceed 1 cycle
    assert(ifc.testvar==1)
    assert active(main_region.StateC1)
    proceed 1 cycle
    assert active(main_region.StateD)
    exit
}

The execution order is different, it seems to be A->B->C0->D in both cases.

When swapping the transition priority in stateB it works as expected. This seems strange to me as I expect the ifc.testvar assingment only to happen on else.

When changing the transition assignment from 1 to 2 it again works as expected (with the exeption of the var not being 1, but 2)

[Rene Beckmann]

Hey Pieter,

sadly I can't see a statechart. Did you try to attach an image? Without it, it's hard to really judge the situation.

Regards,

René

[Pieter Smurf]

strange, I do see one, but I attached it here as well.

[Rene Beckmann]

Hey Pieter,

I can see your statechart now. You used "else" on a regular state, which is not supported, as explained in the documentation:

https://www.itemis.com/en/yakindu/state-machine/documentation/user-guide/sclang_statechart_language_reference#sclang_reaction_trigger_else

"else" and "default" triggers are only meant for "Choice" states. In your case, "else" was on the transition with the highest priority, which is then always taken. The simulation shows the same behavior.

Regards,

René

[Pieter Smurf]

Ok, in that case I expect to get an error on my state machine, but it is allowed to do if [!ifc.testvar==1] instead of the else?

[Rene Beckmann]

Yeah, we talked about that internally and decided we should add a validation for this.

You can of course use [!(ifc.testvar==1)] or [ifc.testvar!=1] and all that usual stuff. The idiomatic way would be to put [ifc.testvar==1] on the transition with the higher priority (number 1) and just "always" on the transition with priority 2. 

[Pieter Smurf]

yea, but for someone who is not used to the sclang always seems to be always, no matter what.

Not always, if there are no other higher priority paths to take.

The documentation only says else is intended for choice not limited to choice.

"The else trigger is intended to be used for the outgoing transitions of choice pseudo states... ...It can only be be used in transitions and implies the lowest evaluation priority for that transition."

I'll think about which solution suits better here.

[Rene Beckmann]

Okay, I get your point. It's always interesting to hear how users interpret parts of the documentation, and your thoughts are very valid. 

You can think about the always trigger like a guard that is always true, like [true]. These two constructs act the same. Transitions are generally evaluated and eventually taken in order of their priorities, no trigger can overwrite this behavior in any way. If transition (1) is taken, transition (2) will never be evaluated, no matter if the trigger is always or whatever, a bit like a row of if-blocks each containing a return statement.

[Pieter Smurf]

If I could make a suggestion, it might be nice to have the error message  on else-usage mention something like "did you mean always?"

On top of that, a warning if always and else do not have the lowest priority might be nice as well, since it is implied not explicitly set. (the order needs to be corrected manually in state/choice properties)

[Thomas Kutz]

We added some validations for exactly these things, for example when a transition can never be taken because of an "always" transition with higher priority. These validations will be available in the upcoming release (probably next week).

[Pieter Smurf]

Nice, I am looking forward to see things fixed.