[markus_GE]

A simple question, as the title says: Are signals no able to apply speed restrictions to a train?

Asking this because I remember some time ago there was talk of signals not being able to do so, though the limits will be displayed in the view of the track ahead in track monitor. THey would, according to this quite old information not be set as a speed limit indicated in the top part of TM.

I´ve never come across a situation where this might be important, usually removing any speed restrictions from routes signalled according to the GCOR (know the limits by heart). On the LE Surroundings, however, which is available on TS.com, I did not remove them and went into emergency a few times with the overspeed light on when misinterpreting one of the Austrian signal aspects. Checking with TM, the indicated limit there was trackspeed, on not the 40 km/h limit the signal apllies. At km/h, however, I went into emergency. So, the overspeed monitor must have checked against the 40 km/h limit, while the TM didn´t show it.

Second question, is this a bug?

Cheers, Markus

PS: Don´t ask about my bad mood today - I just came home from my maths finals!

[James Ross]

My understanding is that the TM should be showing the current max speed across both the track and the signals, although I have seen some weirdness occasionally where the TM shows me passing a lower speed limit and not updating the displayed limit so there might be a few bugs lurking.

[roeter]

Speed limits set for a specific signal aspect are applied and shown in the track monitor.
Difference with MSTS is that a speedsign which indicates a higher speed limit will lift the allowed speed limit. In MSTS, such limits can only be raised (or lifted) by the next signal.

So, as far as I'm aware, there is no bug.

Regards,
Rob Roeterdink

[Csantucci]

In my opinion it's MSTS that is more prototypical here.

[roeter]

That's been discussed many many times before - and it's six of one and half a dozen of the other : some situations MSTS is more prototypical (restricted aspect and speed due to next aspect), some situations OR (restricted aspect and speed due to low speed over junction).
But - as explained before - in the first situation the driver can maintain low speed himself whatever the system does, in the second your stuck to 15kph for a long time just you went across a switch at the start of that section - if you had come on straight to that section you could have been going 150kph or something. Is that prototypical?

Regards,
Rob Roeterdink

[Csantucci]

Good route builders add in the second case a virtual signal that raises allowed speed. This is an excerpt of one of the standard sigcfg files we use here:

Skip(---------- Segnale Virtuale (di tipo NORMAL) per Ripristino Velocità Max ----------)
	SignalType ( "RIPRVEL"

		SignalFnType ( NORMAL )

		SignalDrawStates ( 1
			SignalDrawState ( 0 "Nothing" )
		)
		SignalAspects ( 4
			SignalAspect ( STOP			"Nothing"	SpeedKPH ( 0 )   )
			SignalAspect ( STOP_AND_PROCEED	        "Nothing"	SpeedKPH ( 160 ) )
			SignalAspect ( RESTRICTING		"Nothing"	SpeedKPH ( 120 ) )
			SignalAspect ( CLEAR_2		        "Nothing"	            	 )
		)
		SignalNumClearAhead ( 1 )
	)

(Ripristino Velocità max = reset to max speed)
The Bernina has also a provision to avoid this second case. And also in reality somewhere there are posts that indicate the point where the train can accelerate after passing a junction.

[markus_GE]

 Csantucci, on 09 May 2014 - 11:03 AM, said:

Good route builders add in the second case a virtual signal that raises allowed speed. This is an excerpt of one of the standard sigcfg files we use here:

[...]

That´s what LE Surroundings also does. Yet, for some cases, the OverspeedMonitor of some locomotives (not tested many) does not recognize it, if the speed is lifted by a speedsign after being lowered by a signal. This is, in my opinion a bug, as well as the one occasion I cited when TM showed a higher speed than was actually allowed.

Anyway, I´ll just go ahead and keep removing my signal speed indications in the signalling systems I know more or less by heart or have charts of ;)

Cheers, Markus

[disc]

RW/TSXX have a simple trick for this. The signal speed limit starts at the 0 link of the signal (which is set to the track closest to the signal), and ends when the path link passed. Isn't that possible here? As i see MSTS routes also use this link method for signals.

[Jovet]

The situation is actually pretty complicated. The current signaling framework (i.e. sigcfg.dat) isn't equipped to deal with all of the prototypical possibilities that speed limits can be enforced by a signal indication. These include:

• Speed limit begins at the signal and lasts only through the interlocking/OS.
• Speed limit begins at the signal and lasts to the next signal.
• Speed limit begins at the signal and lasts until the exit signal.
• Speed limit is implied to begin at the signal but the train may begin to slow to comply once passing the signal.
• Speed limit is implied at the next signal but not at this one.
• Speed limit begins at this signal and a second speed limit begins at the next signal.

To make matters even worse, these situations can vary by signal aspect. One signal aspect may apply a speed restriction to the interlocking, but the next more-restrictive signal aspect may extend that all the way to the next signal. There's no graceful way to handle all of these in the current signaling framework. It is something for OR to handle more gracefully on its own in the future.


IIRC, MSTS maintains two internal speed limits: that set by the speed limit marks, and that set by the NORMAL signals. The current actual speed limit applied to the train is the lower of the two. That is, a speed limit marker increase can't cancel a lower signal speed limit... which is prototypical.

[gpz]

Case 1 is the current OpenRails behavior, I think, which is fine for me, since in my country we have such kind of signals.

Case 2 and 3 seems to be the same. It was the MSTS behavior, but in my country it is not the way how the signaling system works, and weird workarounds needed to be applied in MSTS routes to overrule this.

Case 4 can be programmed by the new TCS script, works fine in OpenRails now.

Case 5 and 6 worked in MSTS, and also works in OpenRails.