News:

Simutrans Chat Room
Where cool people of Simutrans can meet up.

[Bug] Trains inching forward at 1 km/h when switching from cab signalling

Started by CK, December 10, 2019, 09:40:14 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

CK

Occasionally when trains switch from TVM to absolute block (a situation which, to my knowledge, doesn't exist anywhere in the real world) they inch forward at 1 km/h if the semaphore choose signal is at danger, rather than stopping at the signal and waiting for clearance. Even when the signal clears the train will continue inching forwards until it's about halfway past the signal (and has caused lots of delays on the network).

It seems to occur most frequently near Wilingpool Herring Gardens on the Bridgewater-Brunel server.

freddyhayward

Have you been able to recreate this in a smaller save? I tried but couldn't.

CK

I have been able to reproduce the behaviour in a save (but I'm not sure where to upload it). It occurs near Swafwell Greenfields (which was designed to somewhat mimic Wilingpool Herring Gardens)

freddyhayward

I think I managed to isolate the problem. It has nothing to do with signalling technology but rather the behaviour of 'end of choose' sign. When a train's scheduled platform is both blocked by an 'end of choose' sign (which is useful for managing through and terminating trains) and a path to it cannot be reserved (which is normal on any busy railway), the choose signal will let the train through at 1kph, reading 'clear - alt. route'. I've attached a save here to demonstrate.

Mariculous

Edit: could not have a look at the save before. From the description it sounds like the end of choose being placed at the platform but it isn't, thus my post had some wrong assumptions :(

I guess this can be divided into two seperate bugs that happen pretty often, no matter the working method:
The first seems to berelated in this case but the second does not kick in here, there seems to be yet another bug here.

  • The "illegal-working-method-state" bug.
      Trains will always continue at 1km/h when they are at some kind of illegal signalling state.
      Multiple situations can cause such an illegal working-method state and we have to handle these differently but we should always warn the player or at least the server admin when this happens, so it's easier for us to locate and fix these.

  • The "Signals/Signs at station platforms" bug.
      Signals/signs at a platform often don't work completely correct. While the signals work fine for the next block, it seems these are often missinterpreted or ignored for the prvious block.
    E.g. here, the end of choose seems to be misssinterpretted. This issue does not seem to be related in that case.
    Another issue appears with token block signalling. When the exit signal (or end-of-signalling sign) of a token block is on a station and it is not another token block signal. In that case the train will correctly switch working method and reserve the new block but won't free the previous (token) block

When a train is entering that illegal-working-method-state, we should start some exception handling, which should in any case include logging to stdout/stderr/logfile, so we can better seek and fix these errors.

Another illegal-working-method-state issue that I have found yet, appears when a signal is deleted while a train is driving towards it.
It's not a situation that would happen exactly like this in the real world. However, malfunctionous signals exist in the real world, which is essentially the same as a driver does not get any signal information at a point where he would expect such.

One way to handle that issue in the real world is to call the operator who will give a command to the driver depending on his information about the following section. (Wait, Continue drive-by-sight, continue or whatever)

Ingame we should simply set a train that is missing signal information on its route to drive-by-sight, as implementing an own command/order working method would be overcomplicated for that rare case.

CK

Quote from: freddyhayward on December 15, 2019, 09:22:59 AM
I think I managed to isolate the problem. It has nothing to do with signalling technology but rather the behaviour of 'end of choose' sign. When a train's scheduled platform is both blocked by an 'end of choose' sign (which is useful for managing through and terminating trains) and a path to it cannot be reserved (which is normal on any busy railway), the choose signal will let the train through at 1kph, reading 'clear - alt. route'. I've attached a save here to demonstrate.
Not necessarily. I've managed to make it occur at both choose signals and just after a normal TVM signal not long after it switched from moving block.

Mariculous

I started seeking that bug observing the exact behavior of the train and set some breakpoints in a debug build.

So first the observation:
The moving towards the choose signal will slow down for the mistakenly clear-showing choose signal in absolute block working method.
It will pass that signal at only 1 km/h
It will stay at that speed until it reaches (9,5)
At that point it will switch to drive_by_sight and start accelerating
It will correctly stop in front of the train in the station

I had posted a -maybe- related situation a few months ago, where a signal falsly did not switch to "Danger".
However, I did not have trains falling into illegal-working-method-state at that signal.
I could not reproduce that but I when trying to reproduce it I got a save where trains are ignoring an absolute block stop signal that was showing "Danger" but without slowing down.
In two of these three (freddyhaywards save included) cases, the falsly entered occupyed block was blocked by a train waiting for schedule at a platform. The third case, well I don't know as I never saw it happening live.

However, all these situations don't seem to fith what CK reported, so could you please attach the savegame where you reproduced it here?
In the meantime I will have a further look at what happens in the uploaded save.

freddyhayward

Quote from: CK on December 15, 2019, 01:19:42 PM
Not necessarily. I've managed to make it occur at both choose signals and just after a normal TVM signal not long after it switched from moving block.
What do you mean by this?

Mariculous

I just found out why vehicles move at 1 km/h when their state is illegal (and what that illegal state is) but did not find out yet what exactly causes that state nor why the signals state is mistakenly clear.

1. After start, the convoy knows its whole route from the depot to the platform when it leaves the depot.
2. It also knows the so called "next_stop_index", which is in this case immediately 8, becase the signal at index 2, which would be next_stop_index=3, is in sighting distance from the depot and clear.
3. It will drive to the first signal (accelerating) where it will switch from LEAVING_DEPOT to DRIVING but that switch of state does not seem to have an effect here.
4. From there on it will drive towards the choose signal and should update its next_stop_index as soon as being in sight for the "clear" choose signal but that won't happen for reasons that are hidden somewhere else in the code.
5. When passing the choose signal, the next_stop_index will still be 8, but that's less than the trains current_route_index. So the difference becomes negative, which will cause some undefined behavior in calc_acceleration and calc_move.

The reason why deleted signals will cause approching trains to continue at 1 km/h seems to be the same.
There is no signal at danger in that tile so the convoy won't stop but also next_stop_index won't get updated as we don't see a "clear" signal.

calc_move is pretty complex, thus I won't go into the details of it.
The following lines give us the slow movement:

if (x > xlim && v < V_MIN){
// don't stop before arrival.
v = V_MIN;
a = v / dt_s;
x = dx + _calc_move(a, dt_s, v0);
}


We should not enter calc_acceleration at all when next_stop_index<current_route_index, as this is already an illegal state.
Instead we should do some emergency action.
In case there is no signal nor a platform at all at that next_stop_index-1 tile, we should assume it was removed thus changing the train to drive_by_sight working method.
In case there is a signal, we have most likely a serious problem in the signalling code. We should log this, warn the player about it and immediately stop the train or teleport it to a depot to -at least- prevent deadlocks.

Signalling is handled in the vehicle_base_t::do_drive, more precisely in vehicle_t::hop_check and rail_vehicle_t::can_enter_tile.
I will have a detailled look at what's going on here later.

CK

QuoteHowever, all these situations don't seem to fith what CK reported, so could you please attach the savegame where you reproduced it here?
I can't attach it as 859 kB apparently is too large for this board. I hope this works.

Mariculous

Not sure what you have uploaded there.
It's a gzip archive with some file in it. I would expect a .sve to be honest.

Edit: It seems that file is a sve but you have just dropped that ending for some reason. I could load it but will need to wait for my debug system to be setup again, I'm currently reinstalling a newer OS.

Edit2: It seems your testmap reproduces exactly the same case as freddyhaywards reproduction save:
end-of-choose in front of the platform, platform is still occupyed by another train, the choose signal will falsly show clear, train won't see that green signal, thus next_stop_index won't be updated, train will continue at 1 km/h after that signal.
As freddy mentioned this has nothing to do with the TVM->absolute block switch. Replace the TVM signal with any other stop signal and the Semaphore choose signal with any other choose signal and you will get the same issue.

CK

Quote from: Freahk on December 16, 2019, 07:30:11 PM
Not sure what you have uploaded there.
It's a gzip archive with some file in it. I would expect a .sve to be honest.

Edit: It seems that file is a sve but you have just dropped that ending for some reason. I could load it but will need to wait for my debug system to be setup again, I'm currently reinstalling a newer OS.

Edit2: It seems your testmap reproduces exactly the same case as freddyhaywards reproduction save:
end-of-choose in front of the platform, platform is still occupyed by another train, the choose signal will falsly show clear, train won't see that green signal, thus next_stop_index won't be updated, train will continue at 1 km/h after that signal.
As freddy mentioned this has nothing to do with the TVM->absolute block switch. Replace the TVM signal with any other stop signal and the Semaphore choose signal with any other choose signal and you will get the same issue.
It also occasionally occurs just north of the switch when approaching the station from the north side, generally when a train is approaching from there.

Mariculous

Oh well, ye didn't see that.
The situation also does not seem to be related to the absolute block signal but to the switch from moving block to cab signalling.
Didn't have a look at what's happening there in the code yet, but the track reservation tool tells that story.
Trains are moving towards the TVM board correctly in track circuit mode.
However, they again should switch their working method as soon as the TVM board comes in range and accordingly update their next_stop_index to the end of the next block as soon as it's clear.
Opposing to this, the train continues in moving block until it reaches the TVM block. At that point, it will change to cab signalling but won't update the reservation up to the end of the block.
At the end of the reservation it will continue at 1 km/h not reserving any blocks ahead.

That situation seems to happen more or less randomly. It does not seem to be related to one of the following blocks being blocked or not.

I'll have a look at the physics code in this case on wednesday or at the next weekend but I expect the physics part to be just the same for both situations.
I will also try to seek the main issue in the signalling code at that time.
Didn't I say "I don't want to try to understand signalling code" a few months ago? Well... things change.

As signalling code is extremely crazy and I don't want to break anything, I am not sure if I will try to fix this. However, when the bug is located in the code, it should be much easier for someone who is used to the signalling code to fix it.

Junna

I have a related problem: a chose signal at a station that has some of the platforms behind an End of chose sign (for through services), will pass the signal at danger at 1km/h, until it reaches the next signal, instead of using the chose signal as a regular signal, as they should. The chose signal will invariably display a red aspect, though it will be passed, as I said. I think this applies to all directions, though I only remember west-to-east being observed.

jamespetts

I have split this into its own topic, as it is very important for me to be able to manage the work of bug fixing that each bug report is strictly in its own topic.

Are you able to upload a reliable reproduction case for this? That would be most helpful. Thank you.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.


Junna

I do have it reproducible, however, the save game is 1.2GB. As far as I know there is no change of working method. Just a station with 3 end platforms, for which the chose signal is to work, and two through platforms, for which it isn't. Trains with destinations beyond the end of chose sign are the ones affected. The one's terminating seemed to behave fine.

jamespetts

Unless I have either a saved game or a set of instructions, which, if followed, will reliably reproduce the bug, I am afraid that it will be impractical for me to look into this.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

freddyhayward

Quote from: jamespetts on January 10, 2020, 11:27:15 AM
Unless I have either a saved game or a set of instructions, which, if followed, will reliably reproduce the bug, I am afraid that it will be impractical for me to look into this.
I have attached a minimal save here with the bug occurring at a through station, and another at a terminal station in the thread linked above.

DrSuperGood

Can Junna please confirm that the save freddyhayward posted demonstrates the same issue.

Junna

Yes, this looks like the same issue.

Edit: btw, this issue was not present at the version of the nightly released in late september that I had been using until recently.

jamespetts

I believe that I have now fixed this - I should be grateful if you could re-test with the next nightly build.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

jamespetts

Also, I have merged this with the other topic, since the same reproduction case was provided by both and, if there are two issues (which is doubtful), they cannot meaningfully be distinguished by reproduction cases.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.