[pschlik]

darwins, on 01 November 2023 - 06:52 AM, said:

Meanwhile another (small) bug:

ORTSMaxServiceCylinderPressure ( 64psi ) works fine for BrakeSystemType( "Air_Twin_Pipe" ) or BrakeSystemType( "Air_Single_Pipe" )

however it does not work with BrakeSystemType( "EP" ) in that case for a full service application the brake cylinder pressure rises all the way up to BrakeCylinderPressureForMaxBrakeBrakeForce( 77psi )

Hopefully it can be made to work for EP braked trains.

Interesting, I must need to add a check for the state of the EP wire. Hopefully I will have some time to investigate soon.

[darwins]

How would the Knorr Kkg brake valve be modelled in OR?

First as with all UIC valves we have no means of selecting G, P or R mode. So at present we a wagon has to modelled in just one mode.

Considering the G mode of the Kkg valve we have another choice, there is a manual Empty / Loaded switch. The brake force is not continously variable, it is either Empty force or Loaded force.

Looking at a performance diagram, we can see the lines C for brake cylinder pressure in the empty condition (max 3.0 bar) and the D lines represent brake cylinder pressure in the loaded setting. These are shown reaching a maximum of 5.0 bar.

https://i.imgur.com/fxOebIH.jpg

I am not clear from the description of how it works, using a two-chamber brake cylinder, if the pressure in the brake cylinder is 5.0 bar or if the force achieved is equivalent to a pressure of 5.0 bar. On bremsenbude.de there is a description of the brake valve, it is also possible to download a more detailed document and a technical document describing various brakes.

Looking at the brake forces available from the brake piston, the "Loaded" brake forces are about 2.5 times greater than the "Empty" forces. (Not 5/3 times greater as might be expected from the graph above.)

https://i.imgur.com/0tPyDU0.jpg

One way to model this in OR might be to use the relay valve ratio for the "Loaded" position.

https://i.imgur.com/CcwD2Jh.jpg

I presume everything about the brake performance gets multiplied by the relay valve value. Therefore would application and release rates and the quick service values need to be reduced by 3/5 as shown in red above in order for the loaded braking to be slower than the empty braking?

[Traindude]

Revisiting something I've mentioned in the past, but I'm still curious: Brake Friction and the heat, smoke and/or sparks generated from it.

Here's an example of a Big Boy descending Sherman Hill, with its freight cars' brake shoes smoking due to being pressed up against the wheels for an extended period of time.

If we want to model the heat dissipation of the brake shoes and its associated effects, obviously it involves two aspects:

1. The visual aspect (nothing more complicated that maybe one or more BrakeShoeSmokeFX emitters placed near the wheels), and
2. The physics and thermodynamics aspect--of which I am no expert! After doing some research, the heat energy generated from the friction can be calculated with E = F * d, where E = Thermal Energy, F = frictional force, and d = distance travelled by the point at which the friction is applied.

Although the thermal properties of the brake shoe material can be easily found out, finding the correlation between the friction, temperature, and energy is a mystery to me. Maybe someone more experienced than me can elaborate on that!

However, if we were to implement the heating up of the brake shoes and wheels, should the standard ORTSBrakeShoeFriction tags (Cast_Iron_P6, Hi_Friction_Composite, etc.) yield a hard-coded thermodynamics model? Do we allow flexibility for user-defined "heat curves", even on standardized brake shoe tags? Or do we let ORTS calculate the heat dissipation automatically?

Man, all this info is confusing! Hopefully there's someone out there who can clarify this for me.

[ATW]

I agree on the heat up curves an smoke FX as in ORTS we have not seen wheels heat up due to heavy brake drag or handbrakes.

I also wonder if the ORTSLabel for controllers will work for HUD because not all brake tokens do what they intend to do like for example Handle Off, Suppression. We also need the option key to cutout the Automatic brakes by switch or button as this is important for leakage test even though i do it by adding a notch to trainbrake controller in LAP position.

[darwins]

Quote

Although the thermal properties of the brake shoe material can be easily found out, finding the correlation between the friction, temperature, and energy is a mystery to me. Maybe someone more experienced than me can elaborate on that!

However, if we were to implement the heating up of the brake shoes and wheels, should the standard ORTSBrakeShoeFriction tags (Cast_Iron_P6, Hi_Friction_Composite, etc.) yield a hard-coded thermodynamics model? Do we allow flexibility for user-defined "heat curves", even on standardized brake shoe tags? Or do we let ORTS calculate the heat dissipation automatically?

Originally we had data for speed vs CoF.

Then Peter used the available data to make things two-dimensional = speed and pressure vs CoF.
There is data available about the effect of temperature as well.
Theoretically it could easily be three-dimensional = speed and pressure and temperature vs CoF.
That much could be hard coded for our four standard brake types.

(Good luck for anyone trying to simulate that for the oiled cherry wood brake blocks on the Montreal Metro!)

The stumbling block as you suggest is estimating the temperature. This has to do with contact surface and heat transfer as well as... How complicated do we want to make things? Special effects might be considered though...

[pschlik]

Sorry for the delayed follow-up, but I've finally created a sort of "New Triple Valve Features Vol. 2", which should appear in the next unstable version.

Highlights this time are...

Fixing edge cases people found, and some refactoring. I'm pretty sure this hasn't broken anything but do feel free to test existing content without any changes to see if the brakes work as usual. I also think I improved compatibility with EP systems but I did testing on equipment not actually meant for EP. For anyone with EP stock, give a try with some of the things that adjust brake pressures and see if that's actually changing what goes on in EP land.

Two stage brake pressure, specifically systems where brake pressure depends on speed. User input required is ORTSTwoStageLowPressure ( x ), which defines the pressure limit in the 'low speed' portion of the two stage system. The brake pressure at high speed remains limited by the tokens already in the code (ORTSMaxServiceCylinderPressure, ORTSMaxTripleValveCylinderPressure, BrakeCylinderPressureForMaxBrakeBrakeForce). Note that this explicitly assumes the brake cylinder pressure at low speeds is lower than all other limits. To define the speed at which the system changes from low pressure to high pressure, ORTSTwoStageIncreasingSpeed ( x ) defines the speed at which the vehicle will change from low to high force when accelerating, and ORTSTwoStageDecreasingSpeed ( x ) is the speed where it changes from high pressure to low pressure when decelerating. If both speeds are the same, only one needs to be defined. All of these default to 0, which just disables the behavior. The current setup also results in the low pressure limit being bypassed in emergency, I have no idea if that's accurate.

The high speed reducing valve, which simply requires defining the pressure that the valve activates at: ORTSHighSpeedReducingPressure ( x ). If the output of the triple valve were to go above the set pressure, it gets vented back down to that pressure. But if the venting is overpowered (eg: by an emergency application) the venting rate will be reduced, allowing brake cylinder pressures to remain above the set limit temporarily. I've tried to reduce the number of user-inputs required for this feature, opting to estimate things like the exact rate of venting. Please do test this and see if it feels like brake cylinder pressure is vented too quickly or too slowly. Since not all equipment has such a valve, the default setting is 0, which turns off the feature.

Uniform release, which works nearly the same as uniform charging implemented previously...except instead of slowing down aux res charging, brake cylinder release is slowed. This behavior is activated when the brake pipe is a certain amount higher than the aux res during release, defined by ORTSUniformReleaseThreshold ( x ): the default value is 3 psi which is what is used on the real equipment with this feature, so there shouldn't be a need to manually define this. What really matters is exactly how much slower brake release becomes, use ORTSUniformReleaseRatio ( x ) [unitless quantity!] to decide that. The number entered here will divide the release rate when uniform release activates; ORTSUniformReleaseRatio ( 2 ) would halve the release rate when the brake pipe climbs quickly. If set properly, this will help the brakes at the front and rear of the train release in around the same amount of time. By default, the ratio is set to 0...which just disables uniform release (wouldn't want to divide by 0!)

Separate application rates for emergency and service applications! Previously I wasn't sure if this was justified but I see there are plenty of situations where this would be accurate. In step with my other changes, rather than adding a new token for the emergency application rate specifically, there is now ORTSMaxServiceApplicationRate ( x ) [MaxApplicationRate ( x ) will govern the application rate in emergency]. If this isn't defined, it is assumed to be equal to MaxApplicationRate.

This one's useful with high emergency application rates; I've also tossed in quick action. If ORTSEmergencyQuickAction ( 1 ) is set (default is 0!), then during emergency applications brake pipe air will be sent to the brake cylinder at a rate specified by MaxApplicationRate. This should allow triple valves without emergency reservoirs to produce emergency application pressures higher than full service and will speed up emergency applications if ORTSEmergencyValveActuationRate has been set properly. Recommended NOT to use this with large values of ORTSEmergencyDumpValveRate as the dump valve will steal air that should be sent to the brake cylinder.

[Traindude]

This may use some features not already implemented in the "newly added" triple valve features, but here's a few diagrams of the modern 26C passenger brake system used by modern Amtrak and commuter railroads in the US:

Amtrak Air Brake Handout: 26C HEP Brake System
Amtrak Superliner (I) Maintenance Training Manual (turn to page 133)

From what I can tell, the "main reservoir pipe" is only there to convey MR air to cab/control cars on the opposite end of the consist. For now, the "Twin Pipe Air" system used with the original MSTS Acela and HHP-8 is the closest we have to this.

Also, has there been any work in regard to why adding "Distributing_Valve" to a locomotive with a 6ET or 8ET brake system causes the brake pipe to drain completely after the brake handle has been lapped?

[Traindude]

Weter, on 06 February 2024 - 04:45 PM, said:

pneumatically-actuated doors, wipers. horns/bells, sanders, etc&

Maybe for wipers/horns/bells/sanders, but not for pneumatic doors necessarily. On older single-pipe stock that had pneumatic doors, the air was drawn from the main brake pipe. A check valve and separate reservoir was needed so that opening the door did not trigger a brake application. The same can be said for the pressurized potable water systems for the car restrooms and dining car kitchen.

[Weter]

Wow, how many variants of pneumo-systems! Thanks for telling :good:
And (I've forgot it, doing post before) - pantographs and large contactors/group switchers (controllers, revercers) on EMU needed compressed air too.

[Laci1959]

Traindude, on 06 February 2024 - 05:43 PM, said:

Maybe for wipers/horns/bells/sanders, but not for pneumatic doors necessarily. On older single-pipe stock that had pneumatic doors, the air was drawn from the main brake pipe. A check valve and separate reservoir was needed so that opening the door did not trigger a brake application. The same can be said for the pressurized potable water systems for the car restrooms and dining car kitchen.

Hello.

In Hungary, for historical reasons, the control cars had a main air tank. When released, the brake valve released air from the main air tank of the control car into the brake line. The control car's air horn was also operated from here.
Story After the Second World War, a German motorcar remained in Hungary. The malfunctioning mechanical equipment was removed and the brakes were used to convert it into a control car. Since it had a main air tank, it was obvious that it was used. They were pushed by steam locomotives type 424 and 324 in suburban traffic.

Sincerely, Laci1959