[Traindude]

@Darwin -- I've tested your Time Factor parameters, and they caused the brakes to never reapply after being released and recharged. Just thought you ought to know.

Also -- in my research on steam locomotive air compressor governors, I made a discovery that suggests that the pressure difference between AirBrakesMainMaxAirPressure and AirBrakesCompressorRestartPressure is much smaller for steam-driven air compressors than for those on diesel and electric locomotives. According to some PRR maintenance literature (attached to this message, turn to page 221, paragraph 8):

Quote

Note that the compressor governor [ ... ] responds promptly with a reduction in [main reservoir] air pressure of not to exceed 3 [PSI]...

So, if the maximum main reservoir pressure is 140 PSI, then the parameters would be:

AirBrakesMainMaxAirPressure ( 140 )
AirBrakesCompressorRestartPressure ( 137 )

However, depending on the brake pipe leakage rate parameter, this may cause the compressor to cycle on and off too frequently. I usually disable the brake pipe leakage on my locomotives. I just find it unnecessary.

Attached File(s)

•  PRR Locomotive Maintenance Instructions_split_1.pdf (40.31MB)
  Number of downloads: 135

[darwins]

The compressor research is interesting. It needs to be put together with your other findings on compressors. I remember reading in one of them about maintaining 20 psi above brake pipe pressure, but also about this being related to the brake controller position.
I have just tried apply, release, reapply a few times with some of the triple valves and have not experienced any problems with H, K, or UC valves. We may need to compare notes in a more detailed way to sort out any problems.

[darwins]

This is a description of present day distributors in use in Australia. (Source - dissertation from CQ University)

https://i.imgur.com/x36HOp8.jpeg
At present we can model Retarded Recharge (aka Uniform Charging) Accelerated Application and Graduated Release.

Accelerated Release is possible with the ABDX valve as this uses the Emergency Reservoir.

To model Accelerated Release with the WF 5, ES 500W1 and DB-60 (Australian version) we would need to add an Accelerated Release Reservoir function.

Finally I am confused as to the difference in modelling Quick Service Volume and Inshot. More complex in this case as the inshot in the present day Australian valves is "Reduction Ensuring" - that is taken directly from the brake pipe to the brake cylinder prior to the triple valve operating at the normal application speed.

Two previous posts related to inshot have suggested that the inshot used in UIC valves in the G position can be represented using the Quick Service feature. Another post describes a different inshot function in modern North American valves which requires a relay to be set.

What OR functions should be used to model an Australian valve like the WF5?

[Weter]

darwins, on 06 April 2024 - 11:14 PM, said:

Westinghouse A-1, 5-ET, 6-ET and 7-EL
for example:

Brake_Engine ( 0 1 0.1 0.2
NumNotches ( 5 
 Notch ( 0.0  0 EngineBrakesControllerBailOffStart ORTSLabel ( "Release" ) )
 Notch ( 0.2  0 EngineBrakesControllerReleaseStart ORTSLabel ( "Running" ) )
 Notch ( 0.5  0 EngineBrakesControllerHoldLappedStart ORTSLabel ( "Lap" ) )
 Notch ( 0.7  0 EngineBrakesControllerFullServiceStart  ORTSLabel ( "Slow Application" ) )
 Notch ( 1.0  0 EngineBrakesControllerEmergencyStart ORTSLabel ( "Fast Application" ) ) ) )

Hello, Darwin.
I wonder, does ORTSLabel do anything, being placed inside Notch () entries? For me - it doesn't (official testing version used)

[akioyamamura]

I'm trying to adjust the brake behavior of brazilian heavy hauly consists, and i'm facing a problem with the propagation of a brake application on the brake pipe.
For now, I'm satisfied with the brake pipe charging behavior, since i'm able to replicate the video below and many others videos of this engineer.

https://youtu.be/Dtu...Ms83DTUFnydFFnB

But speaking about the brake application, the BP pressure drops very slowly. An engineer friend of mine and me, are collecting different train applications in video to reach an average time. You can compare the video below with my simulation of the same consist. If I pick a 136 cars consist, it drops even more slowly.

Real situation:
https://youtu.be/IcL...TMdrfMbaP453RHd

Simulation:
https://youtu.be/zR9F3KwOlQ4
https://youtu.be/CFJvKYUKbdY

Is there any way to modify how the BP drops in brake application without compromise the charging behavior, based on my brake settings attached?
Thank you.

Attached File(s)

•  brake settings.zip (1.91K)
  Number of downloads: 109

[pschlik]

I would not be surprised if the equipment used has accelerated application. Accelerated application will speed up applications beyond what can be achieved with brake propagation alone, and is basically a necessity for mile long trains.

Give these settings a try:

	ORTSAcceleratedApplicationFactor ( 1.5 )
	ORTSAcceleratedApplicationMaxVentRate ( 2psi/s )

I know this works well for the ABDX brake equipment, but you can change the accelerated application factor to whatever number you need to get the right application rate.

Also, I would be very surprised if your equipment doesn't have quick service. This will speed up that first application from 90 psi to 84 psi by a lot.

	ORTSQuickServiceLimit ( 10psi )
	ORTSQuickServiceApplicationRate ( 15psi/s )
	ORTSQuickServiceVentRate ( 2.5psi/s )

[pschlik]

darwins, on 02 May 2024 - 11:53 PM, said:

To model Accelerated Release with the WF 5, ES 500W1 and DB-60 (Australian version) we would need to add an Accelerated Release Reservoir function.

Finally I am confused as to the difference in modelling Quick Service Volume and Inshot. More complex in this case as the inshot in the present day Australian valves is "Reduction Ensuring" - that is taken directly from the brake pipe to the brake cylinder prior to the triple valve operating at the normal application speed.

Two previous posts related to inshot have suggested that the inshot used in UIC valves in the G position can be represented using the Quick Service feature. Another post describes a different inshot function in modern North American valves which requires a relay to be set.

What OR functions should be used to model an Australian valve like the WF5?

With the latest unstable version, I have added support for dedicated accelerated release reservoirs. If you use ORTSEmergencyResQuickRelease ( 2 ) then the quick release behavior will be activated (same as if you set this token to 1) but the emergency res will not be used for emergency applications. While it is still an emergency reservoir by name, by function it becomes an accelerated release reservoir.

I also knew the quick service simulation was a bit hacky so I completely rewrote that. Anyone using it previously probably won't notice much change, the same tokens apply, but I did add the more realistic behavior that some brake pipe air will be used to pressurize the brake cylinder up to the ORTSQuickServiceLimit pressure. This should give more realistic pressures after an initial application, assuming all your tokens are set realistically.

For a recap, ORTSQuickServiceLimit sets the brake cylinder pressure up to which quick service will be active. ORTSQuickServiceApplicationRate can be used to set an enhanced application rate for the brake cylinder when below the quick service limit. And, if the brake system is so equipped, ORTSQuickServiceVentRate can be used to set the maximum rate of brake pipe venting during quick service which speeds up how quickly an initial application travels the length of the train. If ORTSQuickServiceVentRate is set to something other than 0, this enables both the venting behavior and the brake pipe sending air into the brake cylinder behavior. The Australian brakes tend to use all of these features with a quick service limit of 10 psi. The exact values of the other tokens are less important but a reasonable guess would be a quick service application rate around 15 psi/s and a quick service vent rate at most 5 psi/s.



At this point, I'm about caught up with what I wanted to do to the triple valves. One last thing will be investigating support for animated brake cylinders-the simulation now has the ability to calculate the brake cylinder motion so might as well let 3D modelers make an animation based on the simulation. No clue how the animations work though so that may require a test subject to give it a shot.

[Weter]

Hello.
Brake gear's animation would be great improvement!
Are bar/min units available in testing versions already?

[pschlik]

bar/min can be used as a pressure unit in the unstable version, but not in testing.

[Weter]

Thanks.
I'll wait.

[pschlik]

Adding extra animation types proved to be smoother than I expected. I can imagine there will be more room to add simulation-driven animations in the future (engine radiator fans and dynamic brake fans come to mind). My very limited testing involved rewiring the mirror animation on an engine to act like brake animations, so I'm not sure these work exactly as expected when given an artistic touch but that's what I need test subjects for (I'm sure there's someone out there who wants to try animating the brakes on their train cars).

Here's the run down:

• Brake Cylinder Animation: Use an animation matrix with a name that begins with ORTSBRAKECYLINDER (if you need multiple animated brake cylinders, names like ORTSBRAKECYLINDER1, ORTSBRAKECYLINDER2, etc will work, this is true of all the shape animations)
• Handbrake Wheel Animation: Animation matrix name beginning with ORTSHANDBRAKE
• Brake Rigging and Brake Shoe Animation: Animation matrix name beginning with ORTSBRAKERIGGING

Use ORTSBRAKECYLINDER for any brake equipment that ONLY moves when the brake cylinder moves and does NOT move when the handbrake is applied (typically, this is the brake cylinder itself, but sometimes the brake cylinder is actuated by the handbrake!)
Conversely, use ORTSHANDBRAKE for any brake equipment that ONLY moves when the handbrake is applied but does NOT move when the brake cylinder moves (typically, this would be the handbrake wheel because the handbrake wheel does not spin when the train brakes apply...looking at you, TSW).
Finally, ORTSBRAKERIGGING is for all the other brake equipment-the things that can be moved by BOTH a handbrake application and automatic brake application (typically, this is the brake levers and brake shoes, but sometimes the brake cylinders fit into this category).

On equipment with disc brakes, you can use these animations to animate brake applied/released indicators too!


There are a few things to consider setting up these animations. For the animations driven by brake cylinder travel (that is, ORTSBRAKECYLINDER and ORTSBRAKERIGGING), the selected animation frame will depend on the simulated brake cylinder travel. This means that you really should use the advanced brake cylinder parameters ORTSBrakeCylinderDiameter and ORTSBrakeCylinderPistonTravel to give reasonable animation in response to the simulation. You can use the animations without the advanced brake cylinder simulation but it may not look as convincing. Now, the values assigned to the animation keys are vital, as the animation key itself represents the amount of brake cylinder travel. So a key value of "8" doesn't mean 8 seconds like in other animations, it means a brake cylinder travel of "8" (the value is normalized, so 8 doesn't actually have units, it isn't a number measured in inches or meters).

The animation values to consider are:

• 0 - brakes fully released, no brake cylinder motion
• 8 - the brakes are applied enough for all slack to be removed from the brake rigging; any brake shoe animation should set the brake shoes to touch the friction surface at the 8 keyframe (after this, the brake shoes should not move, but other components can still move due to flexibility in the rods and levers)
• 10 - the brake cylinder pressure is 50 psi/3.5 bar, this animation should represent the 'normal' amount of brake cylinder travel; note that the animation will run up to the 10 keyframe over 1 second whenever the brakes are applied on trains without advanced brake cylinder simulation (also, for ORTSBRAKERIGGING objects, the handbrake will set the animation to the 10 keyframe)
• 16 - the maximum possible brake cylinder travel allowed in the simulation, occurs around 200 psi brake cylinder pressure (ie: shouldn't ever happen); if your animation looks good up to the 16 keyframe you are good to go for everything the sim throws at your train car

Note that these rules do NOT apply to the ORTSHANDBRAKE animations. Those behave like a normal two-state animation where the keyframes represent time.
Also, there is no need to make an animation that covers the entire range of motion of the brake equipment. If you want something that just shows the brake cylinder extending enough to take up slack and nothing more, then simply don't define any keyframes greater than 8. If you don't think you need 8 individual animation frames, simply skip the keyframes that seem unneeded. OR is smart enough to smoothly animate in between missing keyframes, and will stop the animation when it reaches its maximum value.

[pschlik]

And what I hope is the final feature addition for this round of updates, I have added the ability for the relay valve ratio and inshot to change with freight animations so you can represent another type of load proportioning equipment.

Unlike other load/empty physics settings, it's not realistic for the relay valve ratio to change continuously with the load of the wagon (it's either on or off), so the switchover from empty mode to loaded mode happens automatically at 25% cargo capacity.

Here's an example for a random coal gondola I had. This one uses 50% brake cylinder pressure when empty.

    ORTSMaxBrakeShoeForce ( 31300lb )
    MaxHandbrakeForce ( 32000lb )

    ORTSFreightAnims (
        MSTSFreightAnimEnabled ( 0 )
        WagonEmptyWeight( 28.9t-us )
	
	Comment ( NEW PARAMETERS! )
        EmptyBrakeRelayValveRatio ( 0.5 )
        EmptyBrakeRelayValveInshot ( -15psi )

        ORTSDavis_A ( 87.35lbf )
        ORTSDavis_B ( 0.289lbf/mph )
        ORTSDavis_C ( 0.144lbf/mph^2 )
        ORTSWagonFrontalArea ( 120ft^2 )
        ORTSDavisDragConstant ( 0.0012 )
        EmptyCentreOfGravity_Y ( 1.377 )
        IsGondola( 1 )
        UnloadingStartDelay ( 5 )

        FreightAnimContinuous (
            IntakePoint ( 0.0 6.0 FreightCoal )
            Shape ( COAL_LOAD.s )
            MaxHeight ( 0.0 )
            MinHeight ( -2.2 )
            FreightWeightWhenFull ( 114.1t-us )
            FullAtStart ( 0 )

            Comment ( NEW PARAMETERS! )
            FullBrakeRelayValveRatio ( 1.0 )
            FullBrakeRelayValveInshot ( 0psi )

            FullORTSDavis_A ( 258.5lbf )
            FullORTSDavis_B ( 1.43lbf/mph )
            FullORTSDavis_C ( 0.0504lbf/mph^2 )
            ORTSWagonFrontalArea ( 120ft^2 )
            ORTSDavisDragConstant ( 0.00042 )
            FullCentreOfGravity_Y ( 2.251 ) 
        )
    ) 

Note how I defined the brake shoe force outside of the freight animation block; I don't want the brake force to change depending on the cargo load I want the brake pressure to change instead. Also note that -15 psi inshot, that's typical for American freight cars when empty (remember that "negative" inshot allows pressure to increase to the setting, but then stops increasing until the relay valve provides sufficient pressure to overcome the setting).

For static freight animations, the empty state will use whatever parameters have been set elsewhere in the wag file, but you can still use FullBrakeRelayValveRatio and FullBrakeRelayValveInshot in the FreightAnimStatic block.

[Traindude]

I like what I'm hearing so far, but as I started to retrofit the tender for my one-piece Challenger with the necessary parts, there's one issue that remains -- hierarchies.

Depending on the equipment in question, the levers and rods can be either attached to the vehicle main frame (MAIN) or to a truck (BOGIE). However, for levers and rods that connect a body-mounted component to a truck-mounted component, which part do you parent it to? The body or the truck?

[pschlik]

Whatever looks most convincing. I'm not about to implement inverse kinematics to handle flawlessly connecting rods and pins so there will be clipping or separation in some circumstances.

But I would figure the most visually appealing approach for the rigging components you are thinking of is to attach them to the main body. The thing to consider is that people are more likely to see a rod moving in a way that makes no sense (eg: rotating with the bogie and sticking out of the frame) than they are to notice a rod not moving when it should move.

[Traindude]

pschlik, on 14 May 2024 - 05:40 AM, said:

Whatever looks most convincing. I'm not about to implement inverse kinematics to handle flawlessly connecting rods and pins so there will be clipping or separation in some circumstances.

But I would figure the most visually appealing approach for the rigging components you are thinking of is to attach them to the main body. The thing to consider is that people are more likely to see a rod moving in a way that makes no sense (eg: rotating with the bogie and sticking out of the frame) than they are to notice a rod not moving when it should move.

Understood. Maybe save the IK stuff for the new shape format discussion, but eventually it'll make animating our models a whole lot more realistic.