[Csantucci]

It's also the moment to provide some further general info about OR TCS scriptings and about TCS_AWS_UK.cs in particular.
When an OR TCS script is referenced (directly or through an .inc file) within an .eng file AND at the same moment the general option Disable TCS scripts is unchecked, OR does not execute the built-in default, MSTS-compatible TCS, which uses the parameters within the VigilanceMonitor(), OverspeedMonitor() and EmergencyMonitor() blocks of the .eng file. Instead it executes the script, which reads the parameters within the .ini file (in our case TCS_AWS_UK.ini) to configure itself. Such file therefore is, let's say it so, the .eng file for the OR TCS script.
Coming to the specific TCS_AWS_UK.cs script: I decided to implement into it not only the AWS management, but also to "clone" all default MSTS-compatible TCS, in order to have already exisiting TCS features of the UK rolling stock still available.
If you examine the TCS_AWS_UK.ini file, you will see that it is divided in blocks. The first block, called [General], lists the TCS monitors available in TCS_AWS_UK.cs and defines which ones are enabled.
The VigilanceMonitor (alerter) is enabled only if it is set to true in the .ini file AND if at the same moment the general option Alerter in Cab is checked.
The OverspeedMonitor is enabled only if it is set to true in the .ini file AND if at the same moment the general option Speed Control is checked.
The further blocks define the parameters for each monitor.
The parameters for the Emergency Monitor, Vigilance Monitor and Overspeed Monitor have the same meaning of those within the .eng file.
The specific parameters for the AWS Monitor are at the moment
Inhibited : at the moment it must be set to false
WarningTimerDelayS=3 : defines how many seconds the driver has to acknowledge the warning before automatic braking starts (remember signal beacons are 200 yds before distance signal)
BrakeImmediately : defines whether automatic braking occurs immediately, or only if driver did not acknowledge the warning in time
TrainStopBeforeRelease : defines whether the train has to be completely stopped to release brakes (of course also driver acknowledgement is needed)
ActivationOnSpeedLimitReduction : defines whether there is an AWS warning before a major speed reduction; this function to be enabled requires also the general option Speed Control to be checked in the OR options.
SpeedLimitReductionForActivationMpS : defines what is a major speed reduction (in meters per second). Default is 25 mph
BeaconDistanceToPostM : defines how many meters before the speed reduction post the warning is triggered. Default is 1186 meters.
AppliesCutsPower : if true, cuts power if an AWS automatic braking is started.

An obvious reminder: when you want to use a new version of the OR TCS script and of the related files, remember that you must do that for each trainset where you wish to have the new release.

[Csantucci]

Coolhand101, on 07 February 2020 - 02:42 PM, said:

Regarding shunt and calling on signals. I did notice on the MEP+, that if a semaphore stop signal has a combined siding signal. The AWS will initiate Clear, and play the bing/bell sound.

As of now, in case there are more than one semaphore signals coupled (one for straight away, one for siding), I let ding the bell if the enabled signal is not at stop. Is this correct? Or there isn't AWS in such a case? Mazbe I can modify this if required

Coolhand101, on 07 February 2020 - 02:42 PM, said:

I also notice that if a separate "Clack board" info signal is place on the same post as the semaphore stop signal, the AWS will also intiate clear and play the bing/bell sound.

Can you point me to a specific route and point? What is a Clack board? How is it implemented in the sigcfg.dat file?

Coolhand101, on 07 February 2020 - 02:42 PM, said:

I also notice that on the AWS3 MEP+ activity, as soon as I cancelled the AWS warning for the caution signal, the sunflower change from warning to clear( the next signal was a semphore stop signal set to clear ).

All of the above happen in a certain area on that activity( Approaching Boston station ). I admit that my version of MEP+ is slightly modified, so I shall test this thoroughly on the original version tomorrow.

OK, waiting for your further check results.

Coolhand101, on 07 February 2020 - 02:42 PM, said:

As it stands now, if a shunt/calling on/ siding signal is set to "normal". The AWS will see these as main signals and operate accordingly. There never has been AWS for these signals. Be interesting to see if this can be achieve, like the semaphore stop signals.

Can you mention at least a route, a position and a signal name for this? At the moment I have only MEP, Dorset and NWE and would like not to fill my SD-Card with UK routes :)
]

[Coolhand101]

Csantucci, on 08 February 2020 - 06:31 AM, said:

As of now, in case there are more than one semaphore signals coupled (one for straight away, one for siding), I let ding the bell if the enabled signal is not at stop. Is this correct? Or there isn't AWS in such a case? Mazbe I can modify this if required

There is no AWS at these signals with Shunt Disc or Siding Arm. However, in the MEP+ route, you can get a combined home/distant and siding signal all on one post. So the AWS should only operate for the distant signal only. Can this be done with the script?

Csantucci, on 08 February 2020 - 06:31 AM, said:

Can you point me to a specific route and point? What is a Clack board? How is it implemented in the sigcfg.dat file?

A Clackboard( I should of said Clack Box ) is a old Route Indication Theater box, used mostly with semaphore stop signals. The Clack Boxs in MEP+ are "info" signals, so this is quite puzzling, because with just a semaphore stop signal, there should be no AWS.

Csantucci, on 08 February 2020 - 06:31 AM, said:

OK, waiting for your further check results.

My modified version, just adds correct speeds for the Era with static stencil speed boards and a few extra signals.

If you play your AWS3 MEP+ Test activity, you will see the clack box just before Boston station. And the other problems I mention earlier seem to happen just before Boston station in MEP+ on your test activity.

If not, then it could be my modified version that I'm referring to, but I still have the original MEP+ mini-route. So I well test this today.

One other thing I changed for semaphore stop signals was the "SignalNumClearAhead" to 4, I got fed up seeing the advance starter/Starter at danger when there was nothing in the block ahead. This was causing the distant signal to always be a caution. This mostly happens when there are more than three semaphore stop signals in the signal section. Also, ALL the signal scripts are in the OpenRails route folder.

Csantucci, on 08 February 2020 - 06:31 AM, said:

Can you mention at least a route, a position and a signal name for this? At the moment I have only MEP, Dorset and NWE and would like not to fill my SD-Card with UK routes :)

I probably need some help from other members, as my Dorset coast route is also modified.

However, in most of the signal scripts I have seen. Shunt signals can be "normal" type or "Shunting" Type.

Here is the MEP+ ground Disc shunt signal:-

SignalType ( "BR_M_Ground_Dolly"
	
		SignalFnType ( NORMAL )
		SignalLightTex ( "ltex" )
		SemaphoreInfo ( 0.5 )
		SignalFlags ( SEMAPHORE )

		SignalLights ( 2
			SignalLight ( 0 "Red Light"
				Position ( -0.125 0.060 0 )
				Radius ( 0.03 )
				SignalFlags ( SEMAPHORE_CHANGE )
			)
			SignalLight ( 1 "Green Light"
				Position ( -0.135 0.033 0 )
				Radius ( 0.04 )
				SignalFlags ( SEMAPHORE_CHANGE )
			)
		)
		SignalDrawStates ( 2
			SignalDrawState ( 0
				"Red"
				DrawLights ( 1
					DrawLight ( 0 )
				)
				SemaphorePos ( 0 )
			)
			SignalDrawState ( 1
				"Green"
				DrawLights ( 1
					DrawLight ( 1 )
				)	
				SemaphorePos ( 1 )
			)
		)
		SignalAspects ( 2
			SignalAspect ( STOP				"Red" )
			SignalAspect ( RESTRICTING				"Green" )
		)
		SignalNumClearAhead ( 1 )
	)

I've just check the orignal MEP+ signal cfg and all the shunt signals are "Normal" Type.

Thanks

[darwins]

I think we are now reaching a stage where we have to be happy with what the TCS script can offer.

It certainly offers much more than we have had in the past and allows for some variation between different trains.

I think in that Coolhand will have to put up with some signals that should have AWS not being able to have AWS at present. It seems there is some variation as to if the type of stop signal that he described has AWS or not, no doubt depending on local needs and signalling arrangements.

Equally, thinking about historical times, I will have to put up with some signals that should not have AWS being given AWS anyway, those on bidirectional lines around large stations and junctions and on single track.

These issues will only be properly resolved when AWS beacon locations can be added to routes.

The latter I suspect also applies to the distance of the AWS beacon from a speed reduction point. I note that in Carlo's script the warning is given at a fixed distance from the speed reduction. In real life the distance of the warning would surely depend on the speed reduction required.

[Coolhand101]

darwins, on 08 February 2020 - 08:05 AM, said:

I think we are now reaching a stage where we have to be happy with what the TCS script can offer.

It certainly offers much more than we have had in the past and allows for some variation between different trains.

I think in that Coolhand will have to put up with some signals that should have AWS not being able to have AWS at present. It seems there is some variation as to if the type of stop signal that he described has AWS or not, no doubt depending on local needs and signalling arrangements.

Equally, thinking about historical times, I will have to put up with some signals that should not have AWS being given AWS anyway, those on bidirectional lines around large stations and junctions and on single track.

These issues will only be properly resolved when AWS beacon locations can be added to routes.

The latter I suspect also applies to the distance of the AWS beacon from a speed reduction point. I note that in Carlo's script the warning is given at a fixed distance from the speed reduction. In real life the distance of the warning would surely depend on the speed reduction required.

Of course, this is a godsend. MSTS/OR never had a proper AWS.

Yes the distance was called the service braking distance. It did vary, I got my slam door trains braking performance almost prototypical with an average 0.065%g deceleration rate. So at 90mph on the straight to a dead stop should take around 4500 feet!

Thanks

[Coolhand101]

darwins, on 08 February 2020 - 12:21 AM, said:

The nice thing about Carlo's script at the moment is that it seems to be a small addition that can be added to individual locomotives.

This means that it should easily be possible to customise it to suit different trains.

Some of the variations in individual trains may need to be built into the script - others might be better as part of the eng file rather than part of the script. Variations in different stock that I am aware of so far might be:

Brake is applied immediately vs 3-5 seconds delay before brake application begins

Air brake pipe pressure is dropped to full service level (45 psi) vs ABP pressure is dropped to emergency level (0 psi)

Driver can regain control anytime warning is cancelled vs

When brake application begins driver can only regain control when speed is below 5 mph vs

Train must come to a halt and there is a delay of 40s, 60s or 120s before the controls are unlocked

Power is not cut vs
Power is cut by drop in brake pipe vacuum or pressure vs
Power is cut


BR AWS (with Sunflower) vs GWR ATC (without Sunflower)

I am sure Coolhand can also suggest how it could form the basis of modern TPWS as I am less familiar with this.

I not to fond of modern railways. My main era interest is between the 1960s to 1990s. However I can answer a few things.

Not all signals have TPWS, they are place at risk identified areas. Mostly all controlled signals have it, as well as speed restrictions with large speed reductions. The TPWS is split into two sytems. The first grids are place at a distance well before the signal or speed restriction. This distance is designed to stop a train no more than 200 yards after the red light ( The overlap ). However, most of today's trains can stop before the red light with a TPWS intervention. So, the train must be under a predetermined speed in order to avoid the TPWS.

The other grids are place beside the signal( not speed posts ), so if the train is under the required speed to stop at the signal, but doesn't. The TPWS will activate again. This system has a 99.9% achievement rate.

Once the TPWS was activated, the train must come to a stand, then press the AWS button, then wait 60 seconds for the brakes to release. I believe this time delay does not exists for a couple of years now. Also the TPWS brake application was instant.

Trains with the Westcode 3-step brake( All classes from 142 to 159, 313 to 322 and 455 to 456 ) had a 60 second delay if the drivers brake handle went into emergency, or if the AWS activated the emergency brake, this could be as long as 2 mins. I'm unsure if this still applies on today's UK railways?

On the old Slam doors trains, the AWS would apply the brakes at the emergency rate. I believe the brake pipe had to fall from 70psi to 50psi, before the AWS could be reset. However, the brake pipe could be vented to zero in that time and take much longer to recharge the brake, so normally, you would probably be at or near a stand when the brakes start to release.

When MSTS bin allow a sort of AWS, I would give it a 3 second delay to mimic the brake pipe value. Can this be done with the script now? allowing a time delay before the brakes can release? Or better still, the brake pipe value?( 20 PSI was the full service brake - 20psi x 2.5 triple valve = 50 PSI in the brake cylinders ).

Thanks

[darwins]

A time delay after the train has stopped is in existing MSTS parameters for overspeed monitor, vigilance monitor and AWS monitor. It is also one of the variables Carlo mentioned in how we can edit the code earlier.

Not sure about a time delay from the start of the brake application though. I think either that or the brake pipe value or the train speed is beyond what can be done now and may have to be something new in OR and possibly in the eng file.
Originally I believe GWR ATC / BR AWS was only at signals and that AWS for speed reductions came at a later stage - do you know when that was? If not perhaps the answer is in Red for Danger or in Railway Accident reports.

[Coolhand101]

darwins, on 08 February 2020 - 10:11 AM, said:

Originally I believe GWR ATC / BR AWS was only at signals and that AWS for speed reductions came at a later stage - do you know when that was? If not perhaps the answer is in Red for Danger or in Railway Accident reports.

Yes that is correct. I believe they where introduced for speed reductions when the Morpeth curve accident happened.

https://en.wikipedia...ents_at_Morpeth

Thanks

[darwins]

Thanks. The date looks fairly convenient for OR modelling purposes.
It means we can use a script without warnings for speed restrictions on steam and BR green era diesel and electric, but include the speed restriction part on BR blue era and subsequent models.

[Coolhand101]

darwins, on 08 February 2020 - 11:41 AM, said:

Thanks. The date looks fairly convenient for OR modelling purposes.
It means we can use a script without warnings for speed restrictions on steam and BR green era diesel and electric, but include the speed restriction part on BR blue era and subsequent models.

You can turn the speed warning restrictions off for AWS from the OR options for now.

I have a lot of these static speed warning boards in a dozen or more routes. They do very in length, but the morpeth boards only applies for line speeds above 70/75 mph.
I already have a fixed yellow signal which is on approach 2. I can bury this signal right under the static AWS ramp or use the ramp shape as that signal. For routes that have no warning boards, I can turn on the speed restrictions for AWS.

Thanks