[jugondavidlisto]

Hi Angelo,

with the renaming of the platforms to simulate two different stations it seems to be working as expected thanks.

[Angelo Rosa]

Perfect jugondavidlisto :)

[joe_star]

Hello,

Something I noticed recently while playing around with attach/detach commands, regarding timetable mode honoring end points specified.

From what I noticed, Timetable mode seems to ignore where I set the end point for the path, but runs the train as far along the straight track as it can and stops just before an upcoming node (assuming the track is free).

On the other hand, if I specify a dummy path for the detached portion, still within the same portion of track as where the previous train stopped, the detached portion does not move away from the original portion.

Is this expected/known behavior?

[joe_star]

Weter, on 31 March 2024 - 06:30 AM, said:

Hello.
Is it for just uncouple, but not leaving a platform?

Hello, no platform related, its at end of service on siding

You can see in the video below the scenario in action. The turntable is static so I doubt a factor here.

https://youtu.be/o2uS0JBPDeM

a) If I set the dummy path for the detached loco prior to the switch entering the turntable, the loco detaches then does nothing
B) Even if I set the dummy path end point just a few meters past the leading end of the switch (i.e. before the turntable), the locomotive moves to the end of the track section as seen in the video, rather than stopping at where I defined the end point of the path

[Weter]

B issue is known: path is being extended till the end of block of track.

[Laci1959]

Weter, on 31 March 2024 - 09:48 AM, said:

B issue is known: path is being extended till the end of block of track.

Unfortunately.

Such mistakes should be corrected instead of ambitious plans.

[Weter]

There is no such logic there. Alas.

[roeter]

Laci1959, on 31 March 2024 - 10:26 AM, said:

Unfortunately.

Such mistakes should be corrected instead of ambitious plans.

That a path is always extended to the next node (end of track section) is not a mistake, but is quite deliberate.
On signaled tracks, one generally wants to stop the train at the signal. If the end of path was used rather than the end of the section, one would have to place the end of path point quite accurate to make it look as if the train was stopped at the signal.
Another reason is that, in timetables, paths are often used for more than one train. If end of path position would be used, one would have to work out for which trains that path might be used, which of those trains is the longest and ensure that the end of path position is placed thus that even the longest train would clear all switches at the rear.
Furthermore, when the path ends on a section which has a platform, the end of path position would not be used anyway as the platform position would override this.
So, to make behaviour consistent and avoid having to set end of paths very accurate to get the train to stop at the proper position, it was decided to always extend the path to the end of the section (so upto the next node).
Clearly, one can't have it both ways, so there can indeed be situations where this is not ideal.

But there is an important lesson here.
When something is not working as one would like in a particular situation, don't immediately cry "error". Timetables are complex, and there are many different situations, and the implemented behaviour could well have been set up with such different situations in mind, as is the case here.
Also, do not immediately cry "change". Behaviour which has been quite deliberately set up in a specific manner to cover certain situations, and which has been around for such a long time, should not be changed simply because there might be another situation where the selected behaviour does not work out properly. Changing that behaviour after such a long time will likely cause severe problems for existing timetables.
So, rather than crying "error" and "change", think in terms of "improvement" and "extention".
In this case, a new qualifier for the #path field, e.g. named "$UsePathEnd", could sort this issue and allow users to choose, either to let the system work out the stop position as implemented now, or use the path end as new option.
Such extentions and additions are generally far more useful than to change existing behaviour based on a very specific situation.

All that is now required is to find a developer willing to implenent such a new qualifier. I'm afraid I cannot help you there, I am no longer active as code developer.

Regards,
Rob Roeterdink

[Laci1959]

Quote

Hello.

I can't really agree with that. In Hungary, the train must stop at the Stop sign. Even if the end of the train hangs out. Until then, the next train waits in the space (block) or at the other station. If the train has moved on, the following train can also move on. That is why the traffic attendant works at the railway station to solve such things.
Most European countries use such a sign.
The extension is also an improvement for me. It solves the problem and for me that's the point.
I don't want to derail the thread, but this phenomenon also exists in Activity mode, unfortunately. Or at least something similar. We struggled a lot with it years ago before it got good. In fact, he made the program route the so-called LOOSE consist and set the railway signal free. It had to be deleted because the Activity was not good.

Sincerely, Laci1959

[Weter]

One problem, I've encountered with such behavior was: the distance to switch's blades tips, where train stops, is too short, and train blocks adjacent exit of the switch.
This way, the offered option to take path's end point in account for particular case would be really needed.

[Laci1959]

Quote

When something is not working as one would like in a particular situation, don't immediately cry "error".

Hello.

One more thing about Mr Roeter's writing. Everyone experiences the above phenomenon, but they don't know what to think and are surprised. Maybe if it had been explained in the manual, no one would have called out an error.
However, I would like to ask if the route of a train that arrived earlier on a neighboring track goes to the railway switch, what happens to the switch?
1. Nothing happens, the railway switch will be for me.
2. The railway switch switches to the part of the train standing on the other track, which travels only up to this point.

Sincerely, Laci 1959

[joe_star]

Hello,

Another observation which may have some relationship to above but in an opposite way. I noticed that if at the start of my activity the train is already within the same track section as the station platform, a stop is triggered even if the train is still a great distance from the platform (up to 800m). I don't see this behavior at other stations (albeit timetable mode is a little less strict with the station distances than activity mode I believe).

Anyone else observed this? Is my supposition true that the reason is because the train is already on the same track section as the platform is?

[joe_star]

I've been having the following issue using the $wait command for overtaking/passing on one of my routes.

Assume train A is supposed to wait for train B at the wait point. Now right behind train B is train C which is following close (1 signal back). I notice more often than not, train C is also allowed to pass the waiting train, often the behavior of which is undesirable.

Where the passing track also has a platform, setting a wait for train C against train A is necessary to stop it at the last signal prior to passing train A. If the passing track has no platform then the only choice is to set a follow command. In this case, it is also not feasible where train A later on has to follow train C sometime in the future (I have not yet experimented with the time triggers yet)

Just wondering if anyone else has had similar experience on their timetables. I suspect there is something signaling related causing this.....

[joe_star]

Weter, on 26 December 2024 - 05:20 PM, said:

Hello.
So, all three (A,B and C) are going in the same direction?

Yes. Thats correct. All 3 trains are in the same direction with train C

Also I found that the trigger commands do not work past midnight! E.g. if your train starts at 23:00 & you want a wait or follow command to be triggered at 01:00 the next day, this is assumed by the system that the trigger is applied from 01:00 of the day the train started (which is in the past)

[Weter]

We have "next day" command.
Not sure, would it help in Your case.