[pschlik]

cesarbl, on 26 April 2023 - 10:42 PM, said:

Absolutely thanks for this information. Is this a standard feature, or do some valves reset when they detect a low BP pressure (e.g. below 1 psi)?

I know it's standard on modern US freight stock, but anything else could be different for all I know. Maybe it would help to have a token such as ORTSEmergencyDumpValveTimeout ( 120s ) so the user could adjust this as needed to match the real-life rolling stock (default setting could be 0 seconds, which would result in the valves resetting immediately when the BP pressure < 1 psi, while higher delays would hold the BP at 0 psi for longer).

cesarbl, on 26 April 2023 - 10:42 PM, said:

This would require some graphical modifications too, which are not my most liked area. However the recent F9 proposal looks pretty good, so I could even try to do it myself.

The updated F9 proposal would be a good opportunity to implement partial opening of anglecocks. But if you really wanted to avoid changing anything graphical, a partially open anglecock could be coded to show up identically to a fully open anglecock, making the process invisible to the player (except they will avoid undesired emergency applications). But that begs the question of automating the process (eg: toggling the valve state partially opens the anglecock for 10 seconds, then fully opens/closes afterward) or leaving it manual (eg: toggle button must be pressed twice, first press will change to partially open/closed, second press will change to fully open/closed depending on the original state). Might need a spec written!

cesarbl, on 26 April 2023 - 10:42 PM, said:

If the default works for DP units, please use it. This feature was intended to be used for European MUs where there are passenger cars between locomotives (so not directly attached), but their compressors are synchronized (as the rest of MU signals). Also, I don't think that "the compressor will be synchronized for all units, even DPU", since I am explicitly checking that the locomotive is in RemoteControlGroup == 0 (MUed units).

That makes sense, I was figuring there would be some type of train where syncing compressors even between coaches would be realistic. I guess not everything is useful for me in USAland.
As for why I could see remote units turning on their compressor in sync with the front-looking at the source code tells me that RemoteControlGroup = -1 when disconnected from MU, = 0 when 'in front of the fence' (ie: DPU mode is Sync), and = 1 when 'behind the fence' (ie: DPU mode is Async). That means that a DPU can indeed be in control group 0! So compressors sync up unless you move some of the locomotives to the back of the DP fence, which I guess isn't the behavior you had in mind?

cesarbl, on 26 April 2023 - 10:42 PM, said:

Do you have ORTSDynamicBlendingForceMatch ( 1 )? This is required for the partial Bail-Off to work correctly. I tested this feature extensively for several trains, and I couldn't reproduce the issue. I know where the almost-instant pressure increase comes from, but that part of the code shouldn't be triggered when you have partial bail off.

I'm not actually sure, I made some of these files 2 years ago so I forget what's in them. I know I definitely had DynamicBrakeHasAutoBailOff( 1 ) in there as your documentation said that was needed, maybe referencing force match in the documentation for partial bail off would help. I'll check force match after work. If all fails I can send over my F40PH engine file (everything I use is custom so it's entirely possible I've created an edge case the code isn't prepared for).


Oh and I have another bit of scope creep for you to consider: The current implementation of TrainPipeLeakRate isn't very good, as the leak is considered to come exclusively from the player's locomotive (it's also an engine-only token, ugh). Of course, in real life there's a little bit of leak from every single train car, and I think that's another thing that could be simulated properly now. The distinction of where the leak comes from does matter for operations-when the leak comes from every vehicle, it can be observed that the EOT brake pipe pressure on a long train will settle at a value lower than the lead brake pipe pressure, which results in worse braking performance at the rear. If the leak is simulated as coming from the locomotive only, this just doesn't happen. I figure that would have to be yet another new token that goes in the wagon( section (ORTSTrainPipeLeakRate?), allowing each wagon to constantly lose a little bit of pressure.

[cesarbl]

Quote

So compressors sync up unless you move some of the locomotives to the back of the DP fence, which I guess isn't the behavior you had in mind?

Ah, I see, thanks. I wasn't sure about how DP works. The default value is adecuate for DP units, so just don't set it to 1 for them. RemoteControlGroup = 0 is also used for regular MUed units.

Quote

maybe referencing force match in the documentation for partial bail off would help

Thinking about it I'm not sure about whether ForceMatch is causing the issue. If it is I'll add it to the manual. If that doesn't solve it, I'll test it if you send me the files.

Quote

Oh and I have another bit of scope creep for you to consider: The current implementation of TrainPipeLeakRate isn't very good, as the leak is considered to come exclusively from the player's locomotive (it's also an engine-only token, ugh). Of course, in real life there's a little bit of leak from every single train car, and I think that's another thing that could be simulated properly now. The distinction of where the leak comes from does matter for operations-when the leak comes from every vehicle, it can be observed that the EOT brake pipe pressure on a long train will settle at a value lower than the lead brake pipe pressure, which results in worse braking performance at the rear. If the leak is simulated as coming from the locomotive only, this just doesn't happen. I figure that would have to be yet another new token that goes in the wagon( section (ORTSTrainPipeLeakRate?), allowing each wagon to constantly lose a little bit of pressure.

Agreed. I found it really weird to see it implemented at the Engine() section.

Quote

I know it's standard on modern US freight stock, but anything else could be different for all I know. Maybe it would help to have a token such as ORTSEmergencyDumpValveTimeout ( 120s ) so the user could adjust this as needed to match the real-life rolling stock (default setting could be 0 seconds, which would result in the valves resetting immediately when the BP pressure < 1 psi, while higher delays would hold the BP at 0 psi for longer).

Okay, so I added ORTSEmergencyDumpValveTimer (default 120s), and sound trigger 252 for valve actuation. It should be available at the latest unstable release. Could you test it to see if that works as expected?

[darwins]

Very much agree with comments above about brake pipe leakage. It really should be a factor of every wagon. Not a problem to add them all up and leak from the front if that is the easiest way for the code to work. However the same loco will experience very different leakage when coupled to newly shopped passenger carriages as opposed to worn and battered goods wagons. With vacuum brakes leakage tends to be much greater than with air brakes. So whilst there is relatively little drop in brake pipe pressure between the front and the rear of a train in an air brake system, there may be a difference of up to 3 in Hg between the front and rear of a vacuum braked train - depending on train length and how leaky the vehicles are.

[Laci1959]

Quote

Oh and I have another bit of scope creep for you to consider: The current implementation of TrainPipeLeakRate isn't very good, as the leak is considered to come exclusively from the player's locomotive (it's also an engine-only token, ugh). Of course, in real life there's a little bit of leak from every single train car, and I think that's another thing that could be simulated properly now. The distinction of where the leak comes from does matter for operations-when the leak comes from every vehicle, it can be observed that the EOT brake pipe pressure on a long train will settle at a value lower than the lead brake pipe pressure, which results in worse braking performance at the rear. If the leak is simulated as coming from the locomotive only, this just doesn't happen. I figure that would have to be yet another new token that goes in the wagon( section (ORTSTrainPipeLeakRate?), allowing each wagon to constantly lose a little bit of pressure.

Hello.

It was like this in the MSTS days, and it even worked. It was called AuxiliaryLeakRate. It probably fell victim to the "Let's see what MSTS does and do the opposite" principle, like so much else.
I would like them to consider keeping the name of the token. They would save me a lot of work.

Sincerely, Laci1959

Ps. Isn't that what ORTSBrakeInsensitivity is for? Or I misunderstood this token.

[pschlik]

cesarbl, on 27 April 2023 - 07:43 AM, said:

Okay, so I added ORTSEmergencyDumpValveTimer (default 120s), and sound trigger 252 for valve actuation. It should be available at the latest unstable release. Could you test it to see if that works as expected?

The emergency valves reset properly now, and with a quick edit to some of my .sms files the emergency brake sound trigger worked just as expected.
However, I noticed something odd with the brake simulation on twin-pipe systems: when the brake pipe pressure reaches 0 the brake valves automatically swap from emergency to just apply (unlike with single pipe where the valves change from emergency to release only after the brake pipe pressure is restored). Don't know why that happens. This basically bypasses the valve timer entirely.

cesarbl, on 26 April 2023 - 10:42 PM, said:

Do you have ORTSDynamicBlendingForceMatch ( 1 )? This is required for the partial Bail-Off to work correctly. I tested this feature extensively for several trains, and I couldn't reproduce the issue. I know where the almost-instant pressure increase comes from, but that part of the code shouldn't be triggered when you have partial bail off.

I can now confirm that I do indeed have force match turned on in my F40PH. My actual problem is that I mistakenly had set my engine to use ORTSDynamicBrakeHasPartialBailOff ( 1 ) instead of ORTSDynamicBrakesHasPartialBailOff ( 1 ). My brain was not used to pluralizing "dynamic brakes" in this context so I straight up had a syntax error. I know what I'm doing, I swear! After correcting my syntax, the behavior was significantly better than before! However, I still have some concerns as that brake cylinder craziness shouldn't be happening regardless of the brake settings.

Anyway, I tried enabling and disabling various blended braking parameters to see the results with a full service application, here's what I saw:

• No additional parameters: Train brake application provides max brake cylinder pressure and 56% dynamic braking (only 56% dynamic braking is used due to the way I set up the locomotive brake, that's not a bug)
• Only ORTSDynamicBrakesHasAutoBailOff ( 1 ): Train brake application causes 56% dynamic braking, and brake cylinder pressure rapidly alternates from 0 to 79 psi
• Only ORTSDynamicBlendingForceMatch ( 1 ): Train brake application provides both max brake cylinder pressure and max dynamic braking (force match compensates for my weird loco brake setup, which allows max dynamic brakes to be used)
• Only ORTSDynamicBrakesHasPartialBailOff ( 1 ): Train brake application provides max brake cylinder pressure and 56% dynamic braking (exact same behavior as no additional parameters, which I assume is intended behavior)
• Both auto bail off and force match: Train brake application causes max dynamic braking, and brake cylinder pressure rapidly alternates from 0 to 79 psi (unlike the case without force match, max dynamic braking is used)
• Both auto bail off and partial bail off: Train brake application provides 63 psi brake cylinder pressure and 56% dynamic braking (this suggests that force match is not a requirement for partial bail off, as no rapid brake cylinder changes occur, but I agree that force match helps)
• Both force match and partial bail off: Train brake application provides both max brake cylinder pressure and max dynamic braking (same results as the case with force match only)
• All three turned on: Train brake application prioritizes using dynamic braking, and if max dynamic braking isn't enough then additional brake cylinder is added as needed (basically, this setup works exactly as I'd hope)

Conclusion: Auto bail off has been broken and is causing the brake cylinder to go crazy. Adding in partial bail off only works if auto bail off is on, and partial bail off negates the issues caused by auto bail off.

So while partial bail off is working as intended, I would still hope auto bail off gets some attention as this is a regression from before. And for the record, there are some legitimate use cases for the 'dumb' auto bail off behavior. In my case, many modern freight locomotives will automatically bail off an automatic brake application when the slightest dynamic braking is applied (on the flip side, applying 15 psi or so of independent brake will reduce dynamic braking to minimum on these locomotives: loco brake takes priority over dynamic brake, dynamic brake takes priority over train brake) and auto bail off is the best approximate for this behavior in Open Rails. Seeing my freight locomotives produce rapidly changing brake cylinder pressures is just weird and annoying.

[Laci1959]

Hello.

Speaking of mixed braking. According to the handbook, the percentage of dynamic brake force follows the brake pipe pressure of the train. I'm not sure this is correct. Hungarian locomotives designed in the 1970s had a mechanical rack and pinion connection between the train brake and the dynamic brake lever. So it was proportional to the position of the arm. If the driver moved the lever of the dynamic brake to the zero position during the braking cycle (broken the mechanical connection), the dynamic brake did not work until the end of the braking cycle.
But the world is big and there are many types of locomotives.
Stadler's modern motor trains (EMU) have reversed the situation with mixed braking. The dynamic brake is the primary brake, followed by the air brake. But only if the driver presses or keeps the white button on top of the train/brake lever (combined controller).
In the BrakesEngineControllers ("Train,Independent,Dynamic,Blended") listing, the word Blended means blended braking. Maybe setting the correct order could be the solution as below.
1.) BrakesEngineControllers ( "Train, Blended, Dynamic, Independent," )
That is, the train brake controls the dynamic brake in some way. Any parameters would be good for the mechanical connection?
2.) BrakesEngineControllers ( "Combined, Dynamic, Blended, Train, Independent," )
That is, the dynamic brake controls the air brake via the computer. It would also be good to have some parameter for turning the air brake on and off. I know the keyboard combinations are finite, and there may not even be any left.
I would also like to add that the word Combined refers to the combined thread and brake lever.

Sincerely, Laci1959

[cesarbl]

Hi Laci,
What you are talking about is what I call "Train Blending". That is a different feature, which is just the train brake controller being able to command dynamic brakes of the whole train. This is also possible in OR, but it requires custom Brake Controller scripts, since modern trains have this feature with different variations which are difficult to cover.

The blending we are talking about is "Local Blending". Here, each locomotive reacts to brake pipe pressures, but it applies dynamic braking instead of train braking where possible. For this, locomotives typically measure the pressure that the Triple Valve is demanding, and isolates it from the brake cylinder while dynamic braking is active.

Quote

However, I noticed something odd with the brake simulation on twin-pipe systems: when the brake pipe pressure reaches 0 the brake valves automatically swap from emergency to just apply (unlike with single pipe where the valves change from emergency to release only after the brake pipe pressure is restored). Don't know why that happens. This basically bypasses the valve timer entirely.

It was unimplemented for twin pipe systems. I uploaded a simple modification for them.

Quote

So while partial bail off is working as intended, I would still hope auto bail off gets some attention as this is a regression from before. And for the record, there are some legitimate use cases for the 'dumb' auto bail off behavior. In my case, many modern freight locomotives will automatically bail off an automatic brake application when the slightest dynamic braking is applied (on the flip side, applying 15 psi or so of independent brake will reduce dynamic braking to minimum on these locomotives: loco brake takes priority over dynamic brake, dynamic brake takes priority over train brake) and auto bail off is the best approximate for this behavior in Open Rails. Seeing my freight locomotives produce rapidly changing brake cylinder pressures is just weird and annoying.

Yes, it was a regression. I think I fixed it, so please test next Unstable release.

[darwins]

There was a proposal at one time from one of the developers to add a parameter

ORTSTrainBrakeControllerDynamicBrakeApplication ( x1 y1 x2 y2 )

All trace of this seems to have disappeared from the ET forums subsequently. I am still wondering if this could be implemented. Or is there another way to add a controller like this:

Brake_Train ( 0 1 0.1 0.2
NumNotches ( 8
Notch ( 0	0 TrainBrakesControllerReleaseStart )  Comment ( Release / Running )
Notch ( 0.2  0 TrainBrakesControllerEPHoldStart )  Comment ( Hold EP )
Notch ( 0.3  0 TrainBrakesControllerEPHoldStart )  Comment ( Regeneration I )
Notch ( 0.4  0 TrainBrakesControllerEPFullServiceStart  )  Comment ( Regeneration II and EP )
Notch ( 0.5  0 TrainBrakesControllerEPFullServiceStart ) Comment ( Regeneration III and EP )
Notch ( 0.6  0 TrainBrakesControllerHoldStart ) Comment ( Lap Air )
Notch ( 0.8  0 TrainBrakesControllerFullServiceStart ) Comment ( Apply Air )
Notch ( 1.0  0 TrainBrakesControllerEmergencyStart ) Comment ( Emergency ) ) )

In this case "Regeneration I" is dynamic brake only with no use of EP/air, but ( Regeneration II and EP ) and ( Regeneration III and EP ) were blended brake positions. There was no difference between them - possibly the design was changed before the trains went into service or intended to be changed later. Finally the air brake positions were intended for emergency use in case of failure of the EP system and were not blended. The proposal previously was to achieve this by adding something like this in the eng part of the eng file:

ORTSTrainBrakeControllerDynamicBrakeApplication
(
0.0 0
0.1 0
0.2 1
0.5 1
0.6 0
1.0 0
)

Where the left column is the brake handle setting and the right column is the proportion of dynamic brake blending.

[cesarbl]

Quote

ORTSTrainBrakeControllerDynamicBrakeApplication
(
0.0 0
0.1 0
0.2 1
0.5 1
0.6 0
1.0 0
)

This should be easy to implement, and should cover the simpler cases.

[steamer_ctn]

Laci1959 said:

1682613188[/url]' post='296440']
It was like this in the MSTS days, and it even worked. It was called AuxiliaryLeakRate. It probably fell victim to the "Let's see what MSTS does and do the opposite" principle, like so much else.
I would like them to consider keeping the name of the token. They would save me a lot of work.

The MSTS values often had some "interesting" values which may not have worked well. Hence by renaming the parameter it provides a level of certainty that any values have been reviewed by users wishing to use the feature. If the MSTS parameter was used and there were any issues with legacy files it would require the user to change multiple files. Hence this renaming approach was taken to reduce potential legacy issues.

Air Leakage of the Brake system caters for the following possible features:

I) Leakage impact on the brake controller - for some brake systems putting the controller into the Lap position could result in the brakes being applied as air leaked from the system. The current parameter in the ENG section caters for this feature, and provides a consistent leakage amounts.

II) Leakage implemented in the WAG file - as suggested this might provide variations in the BP pressure to add some interest in the operation of the brakes. It might also allow some further challenges when driving and shunting a train due to a wagon with excess leakage causing brake problems. The typical solution was to cut the car out at a siding. Within most railway companies, It was also necessary for the driver to undertake brake tests after shunting activities.

There is a risk that the WAG values might be set incorrectly by different modellers, and when a variety of cars are put into a consist, especially on a long train, this might result in higher then realistic leakage values. In this case the brakes will apply over time.

Not all users want this level of realism or to spend time debugging trains that the brakes keep applying on. So if this feature is implemented some thought is required to ensure that it caters for all users (ie, those that like realism, and those that just want to see the train move).

At the very least I would suggest that it is linked to the "Simple Physics" switch in the Options Menu.