[darwins]

I have been trying to reproduce the release of triple valves from this diagram (front of train):

https://i.imgur.com/34iDTNW.jpeg

At the start the air brake pipe is overcharged and this excess pressure at the front of the train drops away fairly rapidly.
During this time the pressure in the air brake pipe at the rear of the train is gradually rising (like this):

https://i.imgur.com/vZirV9x.jpeg

That "overcharge" at the front of the train spreads out along the train, just as it would if there was no equalising reservoir present.
Why does it do that?

The answer seems to be that we have missed something from the model, at least for older types of driver's brake valve.
That is the function of the feed valve.

Look at this description for the Westinghouse No 4 driver's brake valve:

https://i.imgur.com/BfNTsQR.jpeg

In the RELEASE (OverchargeStart) position air goes directly from the Main Reservoir to the Air Brake Pipe - without passing through the feed valve!
So the front of the train can be overcharged.

When the brake handle is moved to the RUNNING (ReleaseStart) position, air must pass through the feed valve. So if the feed valve is set to 70 psi, then even if the Equalising Reservoir has risen to 78 psi, no more air can enter the Air Brake Pipe until pressure in the brake pipe at the front of the train has fallen below 70 psi. The extra air that was at the front spreads out along the brake pipe speeding up the release.

The same may not apply to more modern driver's brake valves or modern day locos with push button overcharge. We may need to check this.

[Weter]

ER is being discharged down to set "max sustem pressure" on running position too.
Adjustable Stabilizer walve is in charge for that.
324-th 394-th and 395-th work the same way.

Also note BC pressure drop distinctions between first and last cars of the train.
This distributors function is essential for smoothing longitudinal forces in train: front cars BC release is significantly slower, than rear.

[pschlik]

This is related to the larger issue of not having any 'unequalized' train brakes controllers. To get an overcharge that ignores the equalizing res...we need to have controller settings that ignore the equalizing res (duh).

The best thing I've come up with for the "release" position is to set a high overcharge pressure but also set a high overcharge elimination rate so that the equalizing res rapidly returns to normal and forces the brake pipe to follow. The current setup really only makes sense for the European style of overcharge where it's nice and controlled.

I'm gathering together a list of things that seem to be missing from the train brake controller, probably going to investigate this all in the shorter term, likely after messing with particle effects.

• "Unequalized" notch tokens for actions (apply, release, overcharge) that ignore the equalizing reservoir value, to allow creating systems without an equalizing res (the equalizing res will probably still exist to serve as the feed valve, but can be removed from cab views to make it look like there's no ER)
• Adjustable feed valve to let you change the released brake pipe pressure by +/- 20 psi (or a custom min/max with new tokens)
• Train brake mode selector to allow for cutting in/out application and release and swapping between graduated release and direct release, so you can finally use the PASS, FRGT, CUT-OUT selector
• Cab view controls for these things, plus cab view controls to show the current feed valve pressure, the current reduction in brake pipe pressure, and the target EQ pressure for the given train brake setting
• Also wondering what could be changed to better represent some automatic brake notches, like how Amtrak puts the suppression notch in the middle of the service zone (currently not possible to replicate this and get the correct ER pressures in the suppression notch)

[Weter]

Hello, Phillip.
Nice to hear.
Let's say, ER allows driver to set needed "target" BP pressure quickly, then valve will decrease/increase pressure in BP automatically, and also may maintain it in "lap with feed" position.
As it was said, adjustable reduction valve sets "normal" BP pressure, as driver have defined it (higher for long freight in mountains), then manage ER pressure slow reduction within BP overcharge elimination to said normal value, or lets MR air to go to BP for leaks compensation.
ER acts by means of equalizing piston, connected with valve, letting compressed air either in to BP, or out of BP to atmosphere.

[darwins]

Quote

I'm gathering together a list of things that seem to be missing from the train brake controller, probably going to investigate this all in the shorter term, likely after messing with particle effects.

• "Unequalized" notch tokens for actions (apply, release, overcharge) that ignore the equalizing reservoir value, to allow creating systems without an equalizing res (the equalizing res will probably still exist to serve as the feed valve, but can be removed from cab views to make it look like there's no ER)

Have a look at how Peter has coded vacuum brakes, or may be talk to Peter. Normally vacuum brakes do not have an equalizing reservoir. He has done a pretty good job of making them appear not to have an equalising reservoir, though there might still be one hidden in the code somewhere!

[darwins]

I am having problems with the two unstable versions released today.

Version U2024.04.27-0208 works fine with new brake system properties like:

Comment ( ===Triple Valve Properties=== )
MaxReleaseRate ( 20.0psi/s )
MaxApplicationRate ( 50.0psi/s )
ORTSMaxServiceApplicationRate ( 6.0psi/s )
MaxAuxilaryChargingRate ( 1.0psi/s )
ORTSBrakeInsensitivity ( 0.05psi/s )
ORTSInitialApplicationThreshold ( 2.0psi )
ORTSEmergencyValveActuationRate ( 6.0psi/s )
ORTSEmergencyQuickAction ( 1 )
ORTSEmergencyDumpValveRate ( 0 )
ORTSEmergencyDumpValveTimer ( 0 )

Comment ( ===Brake Cylinder Properties=== )
Comment( one 8 x 12in cylinder. )
Comment ( Piston travel adjusted to give correct triple valve ratio )
ORTSAuxiliaryResCapacity ( 1620in^3 )
ORTSCylinderSpringPressure ( 4.0psi )
ORTSBrakeCylinderDiameter ( 8in )
ORTSBrakeCylinderPistonTravel ( 8.25in )


When I try to use this with versions from 30 April then OR crashes and the log file warns

Warning: Auxiliary reservoir on car D:\Open Rails - CTN Test Route\trains\trainset\~CTN-NYC-HW-Green-Test\~BrakeTest-Coach.wag appears to be too small for the brake cylinder(s). Consider increasing the auxiliary reservoir size, reducing cylinder size, or using a supply reservoir to provide sufficient cylinder pressures.

Logs attached.

Attached File(s)

•  OpenRailsLog-a.txt (17.58K)
  Number of downloads: 135
•  OpenRailsLog-b.txt (26.63K)
  Number of downloads: 130

[pschlik]

Odd that there's no error related to crashing. The log definitely should not be spammed with the aux res size warning for the same wagon over and over, that bit of code should only run once per wagon. (That said, the warning is probably wrong for those brake cylinder settings anyway, since that aux res is more than big enough.)

I'll have a look later.

[darwins]

It is a train of 20 identical wagons - hence the "spamming".

[pschlik]

Looks like I assumed the initialize code ran once when the wagon was loaded, then was copied to other wagons. In reality, it runs every single time even after the data has been copied, which is not what I built for. Also there was potential for a division by 0 error which is probably what caused your crash. All good in the next version.

Testing your settings on my end, I find that the default brake cylinder piping volume is a bit low and equalization pressure is quite high-you might want to add in a TripleValveRatio ( x ) token so the program can provide a better guess of the piping volume to give the pressures you want.

[Traindude]

Is anyone experiencing this lately? When I make a brake pipe reduction of 3 PSI, then instead of the brake cylinder showing an increase of 7-1/2 ( 3 * 2.5 = 7.5 ) PSI, it goes up to 15 PSI. Here are my triple valve settings:

Comment ( ===Triple Valve Properties=== )
TripleValveRatio                                ( 2.5 )
MaxReleaseRate                                  ( 4.0psi/s )
MaxApplicationRate                              ( 7.0psi/s )
MaxAuxilaryChargingRate                         ( 1.2psi/s )
ORTSBrakeInsensitivity                          ( 0.05psi/s )
ORTSInitialApplicationThreshold                 ( 2.0psi )

[Weter]

Hello.
Didn't see ORTSInitialApplicationThreshold parameter before.

[darwins]

At this point, now that many advanced features of triple valves are working, I think we may need to go back and check the operation of the plain triple valve in OR. Perhaps, before we had different kinds of triple valve, the plain triple valve was set up to operate more like a quick acting triple valve.
Let me explain:

Air Brake Tests (1904) - https://archive.org/...ol&view=theater
p172-3 details quick acting triple valve.
"Application to whole train of 50 cars was made in about 6 seconds, compared with 17 seconds for the common triple."


Using the data from The Air Brake (1908) https://archive.org/...relat00compgoog
I have spent about a week trying to approximate the behaviour of the H and K (quick acting) triple valves in OR.

First thing to note is that some of the default factors in the eng file must be changed to achieve this.
The best values that I have come up with so far are:

ORTSBrakePipeTimeFactor ( 0.005 )
ORTSBrakeServiceTimeFactor ( 4.8 )
ORTSBrakeEmergencyTimeFactor ( 0.4 )

These values will give a very good approximation to service application and release behaviour when used with appropriate values for the triple valve. Such as:

Triple Valve Ratio ( 2.5 )
MaxReleaseRate ( 20.0psi/s )
MaxApplicationRate ( 50.0psi/s )
ORTSMaxServiceApplicationRate ( 6.0psi/s )
MaxAuxilaryChargingRate ( 1.0psi/s )
ORTSBrakeInsensitivity ( 0.05psi/s )
ORTSInitialApplicationThreshold ( 2.0psi )
ORTSEmergencyValveActuationRate ( 16.7psi/s )
ORTSEmergencyQuickAction ( 1 )
ORTSEmergencyDumpValveRate ( 0 )
ORTSEmergencyDumpValveTimer ( 0 )

With regard to emergency applications, this model reproduces the brake cylinder pressure changes with reasonable accuracy (the important bit!) with the brake cylinder at the rear of the train reaching maximum pressure in 6 seconds. The behaviour of the air pressure in the brake pipe in OR is however very different to that shown in the tests:

https://i.imgur.com/tRDAOgo.jpeg

Note in the diagrams, it seems all the way along the train, there is a sudden drop of 20psi/s or more, (from 70 psi to 50 psi) at 1s on the first car, at 2s on car#25 and at 3s on the last car.

This "pressure pulse" passing along the brake pipe, may be due to the quick acting mechanism where air from the brake pipe goes into the brake cylinders, before the air from the auxiliary reservoirs is used. There is nothing so abrupt as this when I look at the changes in OR.

Unfortunately I do not have a similar diagram for the older plain triple valve.

What I find in OR is that emergency application of plain triple valves is too fast. Even using MaxApplicationRate ( 6.0psi/s ) there is maximum pressure in the brake cylinder at the rear of a 50 car train in 10 or 11 seconds. This applies even though not all of the valves are in Emergency mode - the brake pipe pressure gradient means those at the front go to Emergency but most only go to Apply. The plain triple valve I have defined as:

Triple Valve Ratio ( 2.5 )
MaxReleaseRate ( 20.0psi/s )
MaxApplicationRate ( 6.0psi/s )
MaxAuxilaryChargingRate ( 1.0psi/s )
ORTSBrakeInsensitivity ( 0.05psi/s )
ORTSInitialApplicationThreshold ( 2.0psi )
ORTSEmergencyValveActuationRate ( 15.0psi/s )

To stretch the emergency application time to the ideal of 17 to 20 seconds at the rear of the train would require a big increase in ORTSBrakePipeTimeFactor [ and an increase in ORTSBrakeEmergencyTimeFactor combined with a reduction in ORTSEmergencyValveActuationRate ]. Such changes would mess up all the other triple valves in use.

Hence my thought that in emergency application, the plain triple valve is behaving like a quick acting triple valve and possibly some of the default code may need to be reviewed.

[Weter]

Hello.
Looking as a brake wave's propagation (sudden low pressure "pit"), which rolls along the train pipe, being smoothen with time and distance.
Imagine circles on water surface, and cut only one radius.

[darwins]

Thanks for fixing the above bug. Sorry to say I have now found another.

Regarding ORTSHighSpeedReducingPressure ( 60psi )

From U2024.04.27 onwards there is no additional cylinder pressure available during applications.

Application was working correctly in U2024.04.26, but brakes do not release as ABP does not rise above 60psi.

In fact the problem of releasing the brakes seems to go back a long way...

U2024.03.07 is the most recent version in which the brakes can be fully released after an emergency application if ORTSHighSpeedReducingPressure ( ) is used.

[pschlik]

To simulate what you're looking for there we'd need a dramatically different brake pipe simulation that considers the momentum of air in the pipe. Not even sure that's feasible to be done in real time. So for the time being, if you get the brake pipe propagation rate right for service applications it'll be far too fast for emergency applications, and vice versa. Since you shouldn't be using the emergency brakes all that often it's best to get things right for regular applications.