UnitStateReq.OPERATIONAL has influence on Exec State machine

[MarvinW]

When I change the UnitStateReq to OPERATIONAL, as opposed to BACKBONE_CONTROLLED, then the backbone signals related to the Exec state machine are also not executed anymore it seems.

Today I learned this very surprising fact when I was debugging why a switch of operation modes would not trigger a unit's cancel as I expected. I always thought that the UnitStateReq only affects the Unit state, as the name also suggests, but not that it would also affect the Exec state. I guess this behavior is intentional. If so, then I would like to raise the point if this is really a good idea. Which use case exists where this is behavior desired?

If you think this is exactly how things should be, then I want to stress that this needs some documentation. I scanned the training book and couldn't find this mentioned (2019 version). Also I could not find a descriptive comment in the NxBase library where I would expect it. In particular the OpconUnitStateReq enum could use a serious hint that it also affects the behavior of the exec state machine. I was really surprised by this behavior and I thought I understood quite well how the framework works. Also debugging this was not easy at all.

[SteffenR- · Accepted solution]

If you set the UnitState explicitly to OPERATIONAL, it indeed means that you want to make this unit independent of the parent unit. Therefore the behaviour is intended.

Example use case:

You have a pump or belt motor that shall run always, independent of operation mode changes. You can put the UnitState to OPERATIONAL to prevent a cancel because of operation mode change.
Disadvantage is that you have to manage the cancel because of an emergency stop in your application.

A whole framework documentation is currently in work.