[PerryPlatypus]

Allow me to display this issue with screenshots:

In Screenshot 1, (2016-05-28 02-42-50), my train is on the left, the empty coal train. The two engines just coming through the switch are my DPU's, so my direction of motion is towards the camera. I am going rather slow because the siding is going to be a tight fit, so I am easing it toward a stop. However, the signal for the AI in the foreground has already cleared for him to depart! In real life, that signal should not clear until the rear end of my train has cleared the signal on the siding (that dwarf signal in between the two tracks).

In Screenshot 2, my train is the one with the visible locomotive on the right track, while an AI train is cruising past on the left. Just as before, I have already gotten a signal to depart (the dwarf signal on the right showing a yellow) while the rear of the AI train is still within the interlocking. This signal should not have cleared until the AI's last car was clear of the signal in the lower left, to the left of my lead locomotive.

Additionally, signals usually have a few seconds of delay time, so these signals should not be clearing until AT LEAST the last car of the opposing train has cleared the interlocking, plus realistically an extra couple seconds.

At high speeds, this effect is not as noticeable, but I have had several occurences where I am running a slow train up a mountain grade and my last car has nearly been hit by an AI train that starts rolling while my last car is still within the interlocking.

Attached thumbnail(s)

• 
• 

[engmod]

What version tsection.dat are you running?

[edwardk]

I have to wonder if it is the signal object. If you load up the route under the route editor, you will find the signal objects for each signal sitting on the track. its possible some of those objects may need to be moved closer or possibly pass the signal.

Edward K.

[PerryPlatypus]

I tried both Build 38 and the new Build 46, I encounter the same issue with both.

As for the signal objects, these particular screenshots are on a route of mine, and the signal object in the Route Editor is right next to the visible object. And this is an issue that I have noticed on all routes, not just this one, so it is not dependent on the location of the interactive signal object.

Are other users experiencing correct operation of signals? This issue is most noticeable with a relatively slow-moving train to notice when the signal changes, which is when the rear car is just barely clear of the switch, but still has a couple cars to go until clear of the opposite-facing signal. This is why it is most often an issue in mountainous territory with lower speed limits.

[Csantucci]

There is no interlock between the dwarf signal and the high one. The high signal opens when the last wagon has physically cleared the switch. There is some distance parameter regulating that, and one of these parameters is the ClearanceDist one (in meters), that is present in tsection.dat. To this parameter OR adds 15 meters. You may increase ClearanceDist for the switches of your interest.

[roeter]

 PerryPlatypus, on 28 May 2016 - 02:11 PM, said:

In real life, that signal should not clear until the rear end of my train has cleared the signal on the siding (that dwarf signal in between the two tracks).

That, typically, is one of those things which differ depending on where you are.
In real life here, on this side of the ocean, that most certainly is not the case. The switch may be set and the signal for the AI cleared as soon as the train in the siding has cleared the clearing distance of that switch. That has nothing to do with the location of any signal in the siding. There may even be no signal at all, or it may be much further down the siding due to further switches on that track.
But it's just the clearing of the switch, usually detected through track circuits, that allows other moves to be routed over that switch.
As an aid to drivers, there is usually some kind of marker to indicate the clearing distance - it could be a white beam, a white or red-and-white small pole or something similar.

Regards,
Rob Roeterdink

[Jovet]

 roeter, on 31 May 2016 - 02:06 AM, said:

The switch may be set and the signal for the AI cleared as soon as the train in the siding has cleared the clearing distance of that switch. That has nothing to do with the location of any signal in the siding. There may even be no signal at all, or it may be much further down the siding due to further switches on that track. But it's just the clearing of the switch, usually detected through track circuits, that allows other moves to be routed over that switch.

I think in the US it would depend on the complexity of the interlocking. In the OP's example, the interlocking consists of all the track (including the switch) bounded by all of the signals. No change in routes through the interlocking can be effected while any part of the interlocking is occupied. But if the interlocking were more complex, such as maybe a chain of progressive switches, or a level crossing (diamond), then the interlocking would be split into multiple circuits. At its core, it's a cost to convenience-efficiency ratio.

[PerryPlatypus]

It would not bode well for me to simply change the Clearance Distance value, as this only would affect my installation, and if I wish to produce a route for sale (Which I am) it will behave differently on different users' computers (not good). Furthermore, at different locations where the route builder may be using the same switch shape, the signals may be spaced closer or further from the switch, so this would still result in non-prototypical performance (the route builder would have to intentionally place all signals the same distance from the switch, regardless of whether this is how it is set up in the real world).

Here is how I propose this should be dealt with. Refer to the first screenshot in this thread when I refer to the "Train on the Left" and "Train on the Right", as they appear in the screenshot:

A. If Open Rails detects a signal that is aimed AWAY from the switch (a signal that would apply to a train that is moving towards the switch, in this case either of the two signals facing the camera), and that signal is within, say, 500 meters of the switch, then OR will not throw the switch and open the route off of any other track until the rear of the train that has just cleared the switch has also cleared the aforementioned signal. In this case, since the dwarf signal is within 500 meters of the switch points, and is along the path of the Train on the Left going into the siding, then the route for the Train on the Right holding the main would not be cleared until the rear end of the Train on the Left has cleared the dwarf signal. This rule would mean that Open Rails would search along the path extending away from the switch until the first signal is reached. It would not apply to any signals beyond the first signal which may also be in the 500 meter range. As mentioned before, the signal would have to be one that is aimed away from the switch, so that the only signals affected would be ones that control movement of a train heading TOWARDS the switch.

B. If Open Rails does not find a signal within that 500 meter range, then it would resort to the current method, wherein it would allow the route to be opened through the switch as soon as a train is beyond the Clearance Distance as written in the tsection.dat

Please let me know what you think of this proposal, and if you need any clarification. I do think this is worth looking into, as this is affecting many, many routes and making them perform unrealistically. Since this apparently does not fall into place with European practice, where switches can apparently throw immediately after a train clears, I would like to suggest what I described be implemented as an Experimental Option named something like "Make Interlockings be Protected By Signals" or something else, and this option could be turned On and Off. Additionally, the 15 meter fudge factor for the Clearance Distance that you mentioned could also be adjustable, and that way we can have a more realistic time delay after a train clears a signal; at most interlockings, the signals do not change immediately. Perhaps a subset of the Experimental Option I mentioned would be a "Interlocking Timeout" option, where you could set a time (in seconds) for a switch to throw after the train has cleared. Tied in with what I have already described, this would mean that once the train has cleared the signal located after the switch, the countdown would begin; this is how it works in the real world, with interlockings having a timeout before the switch can throw. I do strongly urge you to consider this request, as I believe it to be important for realistic North American operation, and I'm sure many other countries around the world.


Additionally, if a route maker wished to "divide" the interlocking, an invisible dummy signal could be placed at the break point of the interlocking. This dummy signal would allow the route to be opened through the interlocking for another train once the rear end of the first train has cleared the dummy signal. I think Jovet will likely understand what I am trying to say with that, at least I hope. I do not wish to come across as a crazy person. ;)

[ATW]

Since it takes time for a dispatch to line a train an signal systems to cycle... How about some new signal function parameters where a user for certain chosen signals add a delay time parameter till signals can go from RED to green or yellow?

Train clears switches but signal won't change until set delay time script seconds have passed. This would save time an effort from making too many waiting points. I would set my delay time to 30 seconds for realism before my signal changes from a Stop indication.

[Jovet]

I suggest that 500 meters is too far. I think 100-150 meters from a switch makes more sense, but if a second switch is found, then the 100-150m distance is repeated, etc.