[Csantucci]

Hi stefan, i'm not at home now. SEquentially the wp comes after the rp.

[Stefan PAITONI]

Hi,
I think the problem arises every time a WP is on the same TrackNode and after the reverse in the activity. I'm trying to check this now.

Thanks

Stef

[Stefan PAITONI]

Carlo,

Could you, when you have time for, retry with a shorter train.... ?
I try the activity with a very short train and it seems OK. Before the commit, I would like to know if it's OK with the current version.

Regards

Stef

[roeter]

disc, on 01 September 2014 - 12:07 AM, said:

Alternative paths are only processed at stations stops? As at my example, the trains have 3 passing paths to choose from (location linked paths enabled), but still can't do that pass. Perhaps this is connected with signalnumclearahead number in sigcfg?

Deadlock processing and alternative paths have nothing to do with station stops, and nothing with SIGNUMCLEARAHEAD either.
It looks to me what is happening in the situation described above is due to a flaw in the signal definition for the signal protection that switch.

It looks to be very similar as a situation described in this thread.

The deadlock processing, and for that matter most of the signalling logic, does not work directly on the signals, but works through the TrackCircuitSections.
In short, the logic prevents the train to 'clear' the route ahead. It assumes that if a train does not have a cleared path, the signal which gives access to that section will stop that train.
But, as you state, the signal shows a restricted aspect and therefor does not stop the train. The opposite train has not yet cleared its path through the switch, so there is nothing to stop the train going into the single track section and so cause a deadlock.

The problem is likely to be in the signal script of that particular signal. It seems to me this signal is at 'STOP' when not enabled, and when enabled (that is, a train is attempting to clear the signal) it checks the BLOCK state.
If the BLOCK state is BLOCK_CLEAR, the signal clears normally, otherwise it clears to restricted. That is wrong. Even if enabled, when the BLOCK state is BLOCK_JN_OCCUPIED the signal should remain at STOP and not be allowed to clear. I know there are a number of signal definitions which have this particular flaw.

Regards,
Rob Roeterdink

[Csantucci]

Stefan PAITONI, on 01 September 2014 - 06:26 AM, said:

Carlo,

Could you, when you have time for, retry with a shorter train.... ?
I try the activity with a very short train and it seems OK. Before the commit, I would like to know if it's OK with the current version.

Regards

Stef

Hi Stef,
with a shorter train it's OK with x.2448. The train reverses, moves to the waiting point and then stops there, then moves to the last waiting point and then proceeds to end of path.
With a longer train in fact two more critical situations are generated:
- the reverse point is moved farther than the preset location to clear the diverging switch
- when the train stops on the reverse point, it is also already on the waiting point.
(I create critical activities with the expressed aim to test the program under all conditions :sign_thanks: )

Regards

Carlo

[Stefan PAITONI]

OK,
The problem seems to be in a situation where your locomotive has not reach the reverse point but the back of the train reach it. So the train must stop without clearing the reverse point and no way to go further.
Tomorrow morning, I will upload a little correction to put the WP on the reversed part of the route. But this do not correct your problem with a long train.

Regards

Stef

[disc]

roeter, on 01 September 2014 - 07:31 AM, said:

Deadlock processing and alternative paths have nothing to do with station stops, and nothing with SIGNUMCLEARAHEAD either.
It looks to me what is happening in the situation described above is due to a flaw in the signal definition for the signal protection that switch.

It looks to be very similar as a situation described in this thread.

The deadlock processing, and for that matter most of the signalling logic, does not work directly on the signals, but works through the TrackCircuitSections.
In short, the logic prevents the train to 'clear' the route ahead. It assumes that if a train does not have a cleared path, the signal which gives access to that section will stop that train.
But, as you state, the signal shows a restricted aspect and therefor does not stop the train. The opposite train has not yet cleared its path through the switch, so there is nothing to stop the train going into the single track section and so cause a deadlock.

The problem is likely to be in the signal script of that particular signal. It seems to me this signal is at 'STOP' when not enabled, and when enabled (that is, a train is attempting to clear the signal) it checks the BLOCK state.
If the BLOCK state is BLOCK_CLEAR, the signal clears normally, otherwise it clears to restricted. That is wrong. Even if enabled, when the BLOCK state is BLOCK_JN_OCCUPIED the signal should remain at STOP and not be allowed to clear. I know there are a number of signal definitions which have this particular flaw.

Regards,
Rob Roeterdink

Actually the dispatcher sets the route to deadlock, the AI train does not goes through a switch which is set against it.
But the best explanation is to show some screenshots:

The upper one is made with version 2194, the lower is the newest, 2448. The route is the same, the activity is the same, at first the paths are set correctly, my train is directed to the middle track, the AI train to the right track, and a switch at the signal exit is set against it. In old version, the player enter to the station, then when the WP for AI train is passed, after pressing 2x ctrl-m (as until that the AI is handled like a static consist) the AI train enters too, then after the AI cleared of the switch, the player gets the path to continue.
But in newest version, everthing is wrong.
And that restricted/stop and proceed or whatever called, state can only appear if the train requests permission to pass red signal, and there is a static consist in the next block. But the player train isn't static.

[Csantucci]

Stefan PAITONI, on 01 September 2014 - 09:07 AM, said:

OK,
The problem seems to be in a situation where your locomotive has not reach the reverse point but the back of the train reach it. So the train must stop without clearing the reverse point and no way to go further.
Tomorrow morning, I will upload a little correction to put the WP on the reversed part of the route. But this do not correct your problem with a long train.

Regards

Stef

Sorry, but I don't understand what you mean. When you say "the train must stop" you mean that it must stop for the WP or for the RP?
My activity has the WP AFTER the RP, as I wrote. So I don't understand your correction.
By the way, as I wrote, things worked well up to x.2442.

Regards

Carlo

[Stefan PAITONI]

Hello Carlo,
First, but it's not important, I don't have the USA2FreightCement wagon ! I replace it by a USA2Freight8.
For me, your reverse location is a little bit too far for your train.

http://media.fotki.com/1_p,rsgrrqbtrqsbssfxgtwwsbrkgfsg,vi/wtfdwdfsgxwdgkgrtstxrdqbdfqsg/8/1305058/13222089/test01-vi.jpg
Your tain must fill between point A and B. With your train, when the last car reaches the Point B, your engine didn't reach the point A. So, due to the last car, your train must Stop, but the train hasn't reaches the reverse. With a shorter train, or by moving the reverse between the junction and its current location, giving more place for your train, it works.

You confirm ?

Regards

Stef

[Csantucci]

Hi Stefan,
sorry that I used cars that aren't standard. I have now replaced them with the ones you have used, so we are in the same conditions.
RP don't work as you say. With your clear picture I will try to explain.
To perform a reverse action in enhanced compatibility mode two conditions must be met (one is not enough), when there is no signal in between:
1) the head of the train, referring to the actual direction, must reach the reverse point (in our case the last freight car must have reached point A)
2) the tail of the train, referring to the actual direction, must have passed the reversal switch (in our case the engine must have passed point C).
This is exactly what happens. If you look at the run, the last freight wagon runs farther than point A, but the engine doesn't reach point A. Reversal is performed when engine has passed point C.
And there is no train stuck. The train performs the reversal and continues running in the opposite direction. Only, something wrong happens to the WP's in this case.

Outside enhanced compatibility mode only condition 2 is necessary.