[pschlik]

Aha, Apply does work like that. I do have to agree that the ability to set custom names for controller positions would be incredibly useful as it is a bit odd seeing "Apply" after suppression, though the behavior is in line with the real thing.

However, implementing this revealed a slightly different issue: the triple valves on my train were going into emergency when using this quasi 'handle off' position!

A typical control valve should only go into emergency when a very fast pressure drop is detected (perhaps the pressure drop rate to trigger an emergency in psi/s could be a wagon parameter, eg "ORTSEmergencyPressureDropRate( 10 psi/s )"), but OpenRails seems to be detecting any reduction below the full-service pressure, no matter how slow of a reduction, as a reason to go into emergency mode. (Even 63 psi causes everything to go crazy!)
https://i.imgur.com/zAEJ7t9.png

Luckily though, this is not the end of the world and is easy to recover from, as OpenRails is missing a key safety feature; vent valves. (At least on modern equipment) a control valve going into emergency mode will also be associated with that control valve emptying the local brake pipe to atmosphere (this could also be a parameter such as "ORTSEmergencyVentValve( 1 )") which dramatically speeds up the propagation of an emergency brake application, especially on long trains (the emergency brake on a long train in ORTS can be pitifully slow due to the lack of this feature.) As far as I know, the reset of any vent valves is generally time-based, keeping them open for 60 seconds or so, which should ensure the train has stopped before the brakes will be allowed to release (and again, if someone feels their equipment should reset slower or faster, this could be a good parameter like "ORTSEmergencyVentValveTimer( 60 )"). For the impatient people out there, you can always use the brakes initialize command!

[cesarbl]

 pschlik, on 19 November 2020 - 10:21 PM, said:

A typical control valve should only go into emergency when a very fast pressure drop is detected (perhaps the pressure drop rate to trigger an emergency in psi/s could be a wagon parameter, eg "ORTSEmergencyPressureDropRate( 10 psi/s )"), but OpenRails seems to be detecting any reduction below the full-service pressure, no matter how slow of a reduction, as a reason to go into emergency mode. (Even 63 psi causes everything to go crazy!)

Some time ago I noticed this and tried to change it. However, the instant pressure drop is sometimes unstable, so maybe a (simple) filter has to be applied.

Additional features for distributors like the quick application you mention are interesting, but there's a pending brake system refactoring which would be worth doing first.

[darwins]

Quote

there's a pending brake system refactoring

That sounds big and that sounds important. Would you be able to give us a heads up of what the aims for that will be?


I understand that in the code, all (train and engine) brakes are at the moment based on the framework of the Westinghouse Automatic Air brake. That made it very difficult for Peter to get a decent model of the Automatic Vacuum brake system which in its most common form has neither a main reservoir nor an equalising reservoir. At the moment I am very pleased to see Manual braking arrive in Open Rails and I am also pleased to see a start on "mixed braking" - allowing steam brakes on a locomotive and vacuum brakes on a train. Hopefully in future it will be possible for locomotives to have a straight air brake as the independent brake but provide vacuum braking for the train.

[joe_star]

 darwins, on 20 November 2020 - 04:01 AM, said:

That sounds big and that sounds important. Would you be able to give us a heads up of what the aims for that will be?


I understand that in the code, all (train and engine) brakes are at the moment based on the framework of the Westinghouse Automatic Air brake. That made it very difficult for Peter to get a decent model of the Automatic Vacuum brake system which in its most common form has neither a main reservoir nor an equalising reservoir. At the moment I am very pleased to see Manual braking arrive in Open Rails and I am also pleased to see a start on "mixed braking" - allowing steam brakes on a locomotive and vacuum brakes on a train. Hopefully in future it will be possible for locomotives to have a straight air brake as the independent brake but provide vacuum braking for the train.

Another item on my wishlist as well to update many of the indian railways older locomotives and rolling stock.

[Lamplighter]

Then there are the new locomotives.
There is a train brake integrated into the combi throttle lever. This applies to both the electrodynamic brake and the air pressure brake.
The lever has the first position "I agree - release the parking brake", followed by "drive - increase thrust", then the position "idle - 0", followed by both types of brakes (edb + air) and the last "fast brake".
This is the solution of modern European locomotives (Siemens, Bombardier, Alstom, Skoda and others).

[darwins]

Another thought on brake system refactoring

At the moment the train pipe leak rate is an eng file property - hence a function of the locomotive.

Would it be possible for ORTS train pipe leak rate to become a property of individual wag files.

Some goods wagons might leak more than others.

Passenger cars, which are generally better maintained should have a slower leakage rate.

The values for each vehicle would then add up to a total for the train in the same way as things like brake pipe volume.

[Weter]

Yes, different rates, depending of consist would be better.
(single loco, short passenger, long goods)
But computing resources demands...

I've red somewhere, that it's quite difficult to calculate 50 triple valves simultaneously,
but if I have 50+ trAins running in my timetable at the same time?

Maybe just coefficient for avaerge leak rate-correction, depending on number of cars, their design and condition?

[darwins]

Good thought Weter, but could it be calculated once for each consist - and stored as a constant until any change is made by adding or removing wagons? Also I doubt the triple valves and such things are calculated for AI traffic - only for just the player train - as AI traffic uses more simplified physics.

[Weter]

Hope so...
Maybe - during coupling...
The pressure change during automatic pneumo brakes working cycle:

t₁-overcharge; t₂-normalizing; t₃-running; t_4,6,8-apply steps; t_5,7-lap; t₉-release.
Pressure curves: P_тм=BP(head/tail) P_тц=BC
Pressures: t₁-overcharged; t₂-t₃-normal; t₈-t₉-service.
t₁-t₂-soft tempo discharge; t₃-t₄, t₅-t₆, t₇-t₈ - discharge steps at service tempo.

[Laci1959]

 darwins, on 22 November 2020 - 04:55 AM, said:

Another thought on brake system refactoring

At the moment the train pipe leak rate is an eng file property - hence a function of the locomotive.

Would it be possible for ORTS train pipe leak rate to become a property of individual wag files.

Some goods wagons might leak more than others.

Passenger cars, which are generally better maintained should have a slower leakage rate.

The values for each vehicle would then add up to a total for the train in the same way as things like brake pipe volume.

I think it works, you just need to set it up in the Wagon section.
AuxilaryLeakRate ( 0.1bar/s )
This is set for a bit strong leakage for testing.