[darwins]

Yes, indeed on the old emu stock letting go of the deadman's was the fastest way to stop. (Same as on the London Underground.)

Since it seems a bit pointless having in OR a deadman's handle that has to be continuously held down, then I prefer not to put an alerter on those emus when writing OR files.
(Possibly emergency stop monitor could be used as an alternative - but there is no emergency stop button - maybe a second animation for the throttle - rotation is throttle and if emergency stop key is pressed the throttle springs up as if released - would have to be keyboard only not mouse control I think - could it work in 3D cabs? Is Mr Momsky reading this?)
Do you know which locos use emergency rate for AWS? I am guessing that would all be post 1980 designs? I may try to get some answers from a BR forum.
In the MSTS eng files there is:
DoesBrakeCutPower( 1 )BrakeCutsPowerAtBrakeCylinderPressure( x )
Either for a loco with TrainBrakesControllerMaxSystemPressure( 70psi ) BrakeCylinderPressureForMaxBrakeBrakeForce ( 70psi ) then BrakeCutsPowerAtBrakeCylinderPressure( 45psi ) seems about right or

Or for a loco with TrainBrakesControllerMaxSystemPressure( 70psi ) BrakeCylinderPressureForMaxBrakeBrakeForce ( 70psi ) then BrakeCutsPowerAtBrakeCylinderPressure( 38psi ) .
Firstly I am not sure how well either of the above currently functions in OR.
Secondly as things stand they do not allow for power being restored at a different pressure to that at which power is cut.
Thirdly I am not sure if they work at all with vacuum brakes.
Finally as you rightly say it would be good to have this based on brake pipe pressure (or vacuum) rather than brake cylinder pressure.

[Coolhand101]

For a loco with a 70 PSI brake pipe, a triple valve would of been used. This was set at 2.5 ratio. So a 20 psi reduction in the brake pipe allowed a maximum of 50 PSI in the brake cylinders or a 22 psi reduction would be 55 psi in the brake cylinders. These locos had no partial release from the train brake. However, the straight air brake took the air directly from the Main Reservoir. This could allow 100 PSI in the brake cylinders, but a limiting valve was in place to limit the BC pressure between 50 to 75 psi.

For a loco with a 72.5 psi brake pipe, a distributor was used. This allowed a Brake pipe reduction up to 26 psi for a full service brake( 65psi in the BC from the train brake ). As a result, a partial release could be made.

You will get some variations for the above figures, as I cannot remember the exact ratio of the distributor setting ( 2.5 to 2.7 ).

As for the AWS causing an emergency rate instead of a full service rate, some of the early A.C locos achieved this. I have to re-visit the loco docs site for more information on other locos.

It looks like Carlo script is coming along nicely :) :)

Thanks

[Csantucci]

Hi Coolhand and darwins,
again, thank you for the info. I don't think braking will be exactly as in reality, because of the difference of braking parameters in the various trainsets, and also because I believe that OR foresees now only an automatic emergency braking.
At the moment I won't cope with beacons: I'd like to publish a simple working solution in reasonable time.
I have two further questions:
1) In which state is the sunflower when the train starts the run, i.e. it hasn't yet passed over a beacon?
2) Is there a picture of the (real) cab of the NWT Class 150 where the acknowledge pushbutton can be seen? Or is this pushbutton quite a standard as shape and colour?

[darwins]

Csantucci, on 25 January 2020 - 11:29 AM, said:

Hi Coolhand and darwins,
again, thank you for the info. I don't think braking will be exactly as in reality, because of the difference of braking parameters in the various trainsets, and also because I believe that OR foresees now only an automatic emergency braking.
At the moment I won't cope with beacons: I'd like to publish a simple working solution in reasonable time.
I have two further questions:
1) In which state is the sunflower when the train starts the run, i.e. it hasn't yet passed over a beacon?
2) Is there a picture of the (real) cab of the NWT Class 150 where the acknowledge pushbutton can be seen? Or is this pushbutton quite a standard as shape and colour?

There is a class 150 cab view here.
The button is centre stage.
I do not know the answer for the sunflower question though.

[Csantucci]

Thanks Darwins,
that was again very useful.
Today I dedicated few time to the feature, but I could add the automatic braking (at the moment emergency braking) if the button is not activated. Next step is to add the button handling, which I think will require an addition to the main OR code. Such code already has very useful generic sound events dedicated to the train control system scripts, but no dedicated, generic (in the sense that the TCS can assign them to any function it needs) cab controls. I think I will try to add such feature to the OR TCS code.

[Coolhand101]

Csantucci, on 25 January 2020 - 11:29 AM, said:

1) In which state is the sunflower when the train starts the run, i.e. it hasn't yet passed over a beacon?

Before the driver sets the cab up( Master switch/Reverser at off), the sunflower is black( Clear ).

When the cab is setup( Master switch/Reverser to On/Neutral/E.O, the AWS is activated and once the driver resets the AWS, the sunflower goes to the caution display.

As the Master Switch/Reverser has no 'off' setting in OR, the sunflower should then be at caution on simulator start.

Thanks

[Stijn D.C.]

Hello,

I remember that BVE4 and Open BVE have AWS futures on it. Maybe this is usefull for prospection ?

[Csantucci]

I'm not far from conclusion of a first test release, but I have further questions:
1) How can I identify semaphores (which are not connected to the AWS) in the sigcfg.dat file? Are they all signals that have this line

SignalFlags ( SEMAPHORE )

?
I see that there are also distance semaphores that can switch between yellow and green. Are they connected to the AWS?

2) It is not easy at all to identify where the speed warning posts are located in a route, because OR considers them as standard scenery items. So to locate the point where the AWS warning is triggered due to a major speed reduction I can rely only to the position of the speed reduction post. Is there more or less a standard distance between speed warning post and speed reduction post?

3) Is the alerter alert sound different from the AWS warning sound? Can I find or derive somewhere the alerter alert sound?

4) What is the behaviour of the sunflower when the AWS warning is triggered as advance speed restriction warning? Is the sunflower activated also in such case? And if yes, when does it return to black? Before next signal set to clear?

[Coolhand101]

Hi Carlo.

Member roeter should be able to answer your first question 100%. I'm unable to view signal scripts today.

The majority of Distant semaphore signals had AWS when the system was introduced.

The distance between the advanced warning boards and actual speed board, is the service braking distance of the train. For the UK this did vary, but for a average distance, I would say between a mile and a mile and quarter.

The alerter sound was a "beeping" sound. I will check UKTS for the sound.

The "sunflower" at an advance warning speed board shows the same caution display and also the same warning sound. It will show black again only on a green signal.

Thanks

[darwins]

Hi Carlo

In semaphore terms AWS was only placed at distant signals. (That includes of course those which combined both a stop signal and a distant signal.)


That should I think translate as for any semaphore signal which I would presume to have SignalFlags ( SEMAPHORE ) AWS is only present if the signal definition includes SignalFnType ( DISTANCE ) it is not present for any other type of semaphore signal.


The problem is looking at some MSTS signal files for colour light signals, there seems to be at least one that includes SignalFlags ( SEMAPHORE ) in the definition, which rather confuses things.I can find no easy pattern for colour light signals where the general rule would be that all colour light signals have AWS except 2-aspect colour light home signals, information signals (feathers and repeaters) and shunting signals.

There might be another way to look at things though, which should exclude the majority of signal types that need to be excluded.

If a signal definition includes SignalAspect ( APPROACH then it should have AWS. That includes all variations such as SignalAspect ( APPROACH_1 and SignalAspect ( APPROACH_2 and so on.
For any signals that do not have an APPROACH aspect then there is no AWS.


For modern traction I believe the AWS is at the speed reduction post or slightly before it - although this is a relatively recent thing - that is both speed reduction posts and AWS for speed restrictions.
It would seem reasonable to assume that in the days before speed reduction warnings were posted then there would be no AWS for the speed reduction -- except by means of a fixed signal.

[Csantucci]

Thank you. In fact I think the best approach is to consider for AWS warning all signals having at least an aspect that is neither STOP nor CLEAR_2. Unfortunately looking for this in a simple way is not something which is implemented in OR now, so I am studying what would do the best way to do it, trying to implement something that could be useful also for other TCSs. As of now in effect there is no possibility for the TCS script to have info about distance signals, and this is an info which is useful also for other TCSs. I will also ask roeter to be a consultant in this.

[darwins]

Finding distant signals (and other warnings) would be vital for most TCS.
If OR can read distant signals then it would also be good to add them to the track monitor. Yes I know I can see all the home signals two miles ahead, but driving steam the distant was usually positioned at what would nowadays be called the braking point - usually about 800 yards before the outer home on level track on fast routes - stopping distance from around 70 mph with vacuum brakes.

[roeter]

For my general view on this issue, see this post.
As for this particular script, for now I would limit it to NORMAL signals, that would cover all modern continouos block MAS systems.
However, even in these systems not all signals set by OR as NORMAL would have AWS, for instance shunt signals in yards and sidings would not be equiped with AWS. To make this distinction, you could opt for a check on the type of signalhead available in the signal, allthough that would require a list of applicable signalheads to be provided per route one way or the other.

Regards,
Rob Roeterdink

[Csantucci]

INSTRUCTIONS TO GET THE ALPHA VERSION OF THE AWS TCS OPERATING

Preparation

Download and install https://www.uktrains...orm_fileid=4488 (NWT150 DMU) into the mep miniroute
Download and install https://www.uktrains...orm_fileid=5692 (cabview for NWT150) into the mep miniroute by Graham Parkin
The NWT150 has been wisely suggested by Coolhand, because it has a usable sunflower. However without the AWS TCS it works unproperly.

Download file mep_AWS_demo_pack.zip Rev.10 from here http://www.interazio...loads/index.php , unpack and install it into your Train Simulator folder for the MEP mini-route install

The pack must be run with OR NewYear MG rev. 53 or later.

For interested people such file includes:
- modified cabview (.cvf file named 2000_aws.cvf), with addition of the animation of the alerter reset button (files are added in the CABVIEW folder of the NWT150)
- AWS bell and beep sounds, and the TCS_AWS_UK.sms file that manages them; the AWS bell sound is the "bing" sound available in https://www.uktrains...orm_fileid=4053 , by James Horgan (files are added in the SOUND folder of the NWT150)
- modified .eng files, located in the OPENRAILS folder within the NWT150 folder; the modified .eng files refer to the new cabview and include a line
Include ( "AWS_eng.inc")
which includes the references to the script files; such AWS_eng.inc file is also included in the pack and resides within the Openrails subfolder. Its content is as follows
ORTSTrainControlSystem( TCS_AWS_UK )
ORTSTrainControlSystemSound( TCS_AWS_UK.sms )
ORTSTrainControlSystemParameters( TCS_AWS_UK.ini )
The first line refers to file TCS_AWS_UK.cs, which is the script file itself, and which resides within the SCRIPT subfolder of the NWT150 folder
The second line is self-explanatory
The third line refers to the file that contains the configuration parameters of the script file.

To run the AWS script file you must use OR NewYear MG rev. 52.4 or higher, which can be downloaded from here http://www.interazio...loads/index.php .
To enable AWS operation you must uncheck general option "Disable TCS scripts"
If you want to have also the speed reduction warning check (which applies if there is a speed reduction of more than 25 mph) you must check general option "Speed Control"
If you want to have also the alerter you must check general option "Alerter in cab"

The file includes also the files for two short test activities, that is TESTAWS1 and TESTAWS3. TESTAWS1 operates in a light signals environment, while TESTAWS3 operates in a semaphore environment.
AWS warning acknowledgements occur by pressing the Alerter Reset key or by clicking the AWS reset button with the mouse.

There are uncovered points:
- the AWS braking is stronger than in reality
- shunting NORMAL signals are not excluded (but there are very few)
- the AWS experts could find other flaws.
I am grateful for any comment.
I'm neither sure I manage correctly the case where a speed warning signal is between a speed reduction warning post and the speed reduction post.

You may of course try the pack also in other routes, but you will have to build the test activities by yourself.
You may also play (with some caution) with the configuration parameters of the .ini file.


It is possible to equip other trainsets with the AWS, and therefore to run existing activities using AWS, however if such trainsets don't have Alerter Reset button and operating sunflower there won't be visual cab interaction.

I wish to thank Coolhand and darwins for the many suggestions and explanations. Some support by you is probably still needed.
I credit also gpz and Serana, which developed a well generalized TCS script framework, again Serana for his script for the French TCSs, that I used as guideline to develop my one, and also roeter for his well-organized actual track section structure, that allowed me easily to get the needed data.

[Coolhand101]

I have been waiting for this for quite some time. Unfortunately, I am still using XP so cannot test this brilliant addition for OR ATM. I'm sure Darwin will test this 100% and maybe a video demo can show the AWS in action.
Many thanks for making the AWS Carlo. I will speed up the time to get my new PC with windows 10.

Thanks