Path reservation fixes

[gfgit]

Some experiments with path reservation system.
Based on #113

Some issues already noted in #114

[reinder]

Maybe we can add some tests to check e.g. reservation and changing state of a direction tile while it is reserved.

[reinder]

I created a small test for the direction tile state change while it is reserverd, can you apply the patch to you branch?
0001-test-added-Direction-path-reservation-using-NX-and-c.zip

I zipped it because GitHub refuses to attach the PATCH file...but the error explains that PATCH is supported 🤷🏼‍♂️

[gfgit]

Hi, I've applied your patch.
Also I've noticed sometimes NX Buttons work even if block rail tile is not adjacent, like NX Button + straight rail + Block tile.
Sometimes it does not work. But when I read the findBlock() code I think it is supposed to never work.

[reinder]

Awesome.

It is indeed required to be adjacent to a block but, passive tiles are ignored. On the boardModified event a new graph network is built of the board. It only creates nodes for tiles that have a function, passive tiles like straight en curved rail pieces are ignored. So for a NX button there may be straight/curved rail pieces between them, but not something like a signal/turnout/direction control etc.

[gfgit]

What about bridges? In my test board it didn't work if a bridge was inbetween NX button and block tile. PS. Let's see ho replying by mail works out... Il 25 aprile 2024 19:39:20 CEST, Reinder Feenstra ***@***.***> ha scritto:

…

Awesome. It is indeed required to be adjacent to a block but, passive tiles are ignored. On the `boardModified` event a new graph network is built of the board. It only creates nodes for tiles that have a function, passive tiles like straight en curved rail pieces are ignored. So for a NX button there may be straight/curved rail pieces between them, but not something like a signal/turnout/direction control etc. -- Reply to this email directly or view it on GitHub: #115 (comment) You are receiving this because you authored the thread. Message ID: ***@***.***>

[reinder]

A bridge is a node (due to two seperate reservation paths), so that's why it doesn't work, That is a bug, a bridge is a passive tile so it should be allowed. Going to fix that.

[reinder]

If you merge/rebase latest master the bridge nx button issue is fixed :)

[gfgit]

Rebased on current master.
Some commits are really trivial fixes which could be merged already, while others contain more complex changes on which we should discuss.
If you want I can split in 2 distinct PRs

[gfgit]

Fixed missing include in blockpath.cpp
Also now trivial changes are moved in first commits while last commits contain complex changes

[reinder]

Nice improvements, I'm going to do some test with it :)

[gfgit]

Hi Reinder. Yes I should add an assert. But if you test the code and it works I could change this to avoud using QTimer which requires a new heap allocation every time we start it and instead use `QTimerEvent` and `startTimer()` `killTimer()` Functionality is the same and assert would become timer ID equal to zero. Il 11 giugno 2024 23:09:08 CEST, Reinder Feenstra ***@***.***> ha scritto:

…

@reinder commented on this pull request. > @@ -778,6 +768,61 @@ void BoardWidget::rightClicked() rotateTile(true); } +void BoardWidget::startHoldTimer(const std::shared_ptr<NXButtonRailTile>& nxButton) +{ + stopTimerAndReleaseButtons(); + + m_releaseButton1 = nxButton; + + m_timer = new QTimer(this); I suggest to add a `assert(m_timer);` here, to check if `m_timer` is `nullptr` as expected. -- Reply to this email directly or view it on GitHub: #115 (review) You are receiving this because you authored the thread. Message ID: ***@***.***>

[reinder]

Good suggenstion, QTimerEvent :)

Just did some simulations tests, it works as expected :)

I was thinking, should we log a warning if a turnout is modified externally an Traintastic corrects it? Should we also have some kind of max retry to prevent loops? and maybe Estop the train if the max retry count is reached and log an error then too?

For the path release, there must be some kind of delay I think, the train can still be on the turnout but already left the tail block. (Ideally we have occupy sensors on the turnout's too offcourse, but Traintastic should be able to handle both situations.)

[gfgit]

Yes we should log a warning when turnout is externally changed. But I don't know how to add a new log message...
As for the max retry count when it's reached maybe yes we E-stop the train. Although this is a strong action which might not be good for some users. Maybe we add a setting like "E-stop train if on path and turnouts are changed externally".

I think I've added the retry count logic to signals, if it's working fine I'll copy it also to turnouts.

For the path release, I bet very few layouts have dedicated occupy detectors for switches so yes we should workaround it with some kind of delay.
Better yet if we know the real train speed and it's real length we can estimate traveled space and so have a varying delay according to train speed and length plus a security margin.
We don't even have to know path length which would depend on turnout state in case of multiple possible paths for the same pair of NX buttons. We start to count from when exit block gets occupied, until train tail is inside the exit block and entrance block is free.

[reinder]

Yes we should log a warning when turnout is externally changed. But I don't know how to add a new log message...
I'll explain :)

To add a log message you need to add a enum value in [/shared/src/traintastic/enum/logmessage.hpp](https://github.com/traintastic/traintastic/blob/master/shared/src/traintastic/enum/logmessage.hpp).
In this case it is a train/board related message so it is in the 3xxx range, just use the next free number.
You also need to add at least an English term for the message in, as the server always uses English for the console log.

I've numbered all the log messages so it is easy to look up, in the source and if we receive a screenshot/log text in a language we don't understand :)

As for the max retry count when it's reached maybe yes we E-stop the train. Although this is a strong action which might not be good for some users. Maybe we add a setting like "E-stop train if on path and turnouts are changed externally".

Good suggestion to add a world setting for that, maybe we can add three options:

• Ignore
• Estop train (= default?)
• Stop world

I think I've added the retry count logic to signals, if it's working fine I'll copy it also to turnouts.

I didn't test that yet, but it seems fine, else we can improve it later :)

For the path release, I bet very few layouts have dedicated occupy detectors for switches so yes we should workaround it with some kind of delay. Better yet if we know the real train speed and it's real length we can estimate traveled space and so have a varying delay according to train speed and length plus a security margin. We don't even have to know path length which would depend on turnout state in case of multiple possible paths for the same pair of NX buttons. We start to count from when exit block gets occupied, until train tail is inside the exit block and entrance block is free.

Good suggestions/ideas! I think it is best we move that to a separate PR, then we can finish this one :)

[reinder]

Nice improvements!

Just some thoughts:

• The log message is Position externally changed while locked in a path shouldn't we add a separate message for the signal? (A signal has an aspect not a position.) Should it also be mentioned that Traintastic is going to correct it?
• When a Train is E-stopped, I think a error must be logged to explain why the train is E-stopped.

[gfgit]

• When a Train is E-stopped, I think a error must be logged to explain why the train is E-stopped.

Sure. I was thinking about moving the "stop all trains" code inside BlockPath since it's duplicated in Turnout and Signal.
But then the log output cannot know the reason it's been called. Will think more about it.

[gfgit]

Last things missing should be:

• Opt-out E-Stopping trains in World settings (should this be a Property<bool> inside World object?)
• Maybe also stop the whole World
• Delay for releasing path after train has freed entrance block

[reinder]

Last things missing should be:

* Opt-out E-Stopping trains in World settings (should this be a `Property<bool>` inside World object?)
* Maybe also stop the whole World

Yes, you can add a Property<> to the World for that, it will automagically appear in the World dialog, there aren't much settings yet, but for the future it is best to add it to the Trains category, as examples see server/src/traintastic/settings.cpp (The UI then will create a Trains tab with the setting.)

I think stop the whole world is also a nice option to have, so then we need an enum.

* Delay for releasing path after train has freed entrance block

That would be nice indeed.