[YoRyan]

Hi all,

I am in contact with Jason Dilworth of TrainSimulations. We would like to collaborate on a more realistic blended braking model for North American passenger locomotives, like the EMD F40PH and GE P40/P42. To make this happen, we would need to implement some additional .eng properties for the blended dynamic braking system.

But first, we had a question about a potential bug in the current implementation. When operating a locomotive with blended brakes in Open Rails, why is that after you return the train brake handle to "release" that the dynamic brakes remain stuck in "setup" mode for upwards of a minute? You can experience this behavior with the Kuju HHP-8. Load it up with a train of passenger cars and apply, then release the train brake. You will not be able to advance the throttle with the "D" key because the simulator complains about the dynamic brakes being in setup mode. But interestingly enough, you can bypass this restriction using the mouse.

Was this intentional, or is this a bug? It seems to me (and Mr. Dilworth) that the dynamic brakes should release as soon as the train brake handle is released.

[darwins]

Could I suggest that you take as a starting point the work that has already been done for OR - not the MSTS / Kuju default locomotive.

There are several posts on the forums here about dynamic braking - some of them suggest improvements that need to be made. Others give instructions on how to put dynamic braking into an OR eng file. Following the instructions given in one of those posts you can make an OR loco where the blended dynamic braking releases at the same time as the train air brakes or EP brakes. I have attached an eng file that I made by following the instructions given. You may wish to look at that - or better still get in touch with the person who posted the instructions.
There are two things that I would very much like to see achieved with blended dynamic braking: ( 1 ) Have a blended brake controller setting that allows dynamic brake only without any air brake usage - see this post.
( 2 ) Have a blended dynamic brake that works on a locomotive pulling a vacuum braked train. I have some eng files for dual braked locos - the blended dynamic brakes work perfectly in the eng file that uses BrakesTrainBrakeType( "Air_twin_pipe" ) but they do not work at all in the eng file that uses BrakesTrainBrakeType( "Vacuum_single_pipe" ). At the present time OR requires that when the loco has BrakesTrainBrakeType( "Vacuum_single_pipe" ) then it must also have BrakesEngineBrakeType( "Vacuum_single_pipe" ). On the real locos with blended brakes the loco brakes are in fact straight air brakes - regardless of using vacuum brakes or air brakes for the train. It may be that if it becomes possible to specify air brakes for the loco when it has vacuum brakes for the train, that the problem of blending the dynamic brakes might be solved.

Attached File(s)

•  87001.eng (42.6K)
  Number of downloads: 365

[YoRyan]

I bring up the HHP-8 because most everybody should have it, and I don't believe this "stuck in setup" behavior is present in MSTS. Therefore, it seems to me to be a bug.

It would be most helpful if you could explain which property makes the "blended dynamic braking [release] at the same time as the train air brakes or EP brakes." Scanning through your .eng file, I could only find the following properties related to dynamic and/or blended braking:

    BrakesEngineControllers( "Independent, Train, Blended" )
        DynamicBrakesMaximumForce( 120kN )
        DynamicBrakesCutInSpeed( 25 )
        DynamicBrakesMaxAirBrakePressure ( 72.5 )
        DynamicBrakesDelayTimeBeforeEngaging ( 1 )
        DynamicBrakesNumberOfControllerNotches( 0 )
        DynamicBrakeHasAutoBailOff( 1 )
        ORTSDynamicBrakeBlendingForceMatch ( 1 )

[darwins]

I am sorry that I can't explain. Dynamic braking and blended braking is very much an area in which I am still learning. All I know is that I copied the advice given in this thread and it seems to work very well.

[farrmp]

I'm no expert on Dynamic Braking--but I seem to recall that a Several Second Delay was implemented to simulate the Set-Up time of mechanical relays.

[pschlik]

So, I've also had a "few" problems with blended braking in physics I've worked on. Some core assumptions MSTS/OpenRails make about dynamic braking and blended braking makes driving with blended brakes more painful than it should be, and also not very realistic.

The first problem is that OR handles mechanical interlocking of the throttle and dynamic brake horribly:

• You can move the throttle handle while the dynamic brake handle is in setup, only locking the throttle when the setup is complete. Even in setup, the throttle handle should be locked out.
• The dynamic brake gets locked in the setup position until setup is complete. It should be possible to move the dynamic brake handle anywhere during the setup time, even including turning the dynamic brakes off before setup has completed.
• The throttle handle gets locked during blended braking. Blended braking shouldn't activate any interlockings, it should be possible to move the throttle freely during blended braking.

And these three problems are universal, not just issues with passenger locomotives.

Of course, the most useful of these problems to fix would be that OR locks the throttle during blended braking. This shouldn't happen, the engineer should be free to move the throttle handle during blended braking. Setting the throttle above idle should kill the dynamic braking imposed by the braking system until the throttle is returned to idle. This would already solve the problem with the HHP-8...but wait, there's more.


Many blended brake systems will automatically shut off the dynamic brakes below a certain speed. This speed could be customized with a parameter, but 5 MPH is generally a safe bet. The purpose of this is to rewire the locomotive to immediately take power again when the throttle is applied after the stop is completed, even if the train brakes are left applied (of course, even if the dynamic brakes were still on it should be possible to override this, but there would be a slight delay to transition from braking to power, which is best avoided). This specifically avoids the situation OR provides where you get stuck unable to take power until the brakes release all the way...at which point the train may start rolling backward or something.


Then blended braking has yet another trick up its sleeve to prevent the dynamic brakes coming on when the engineer doesn't want them; bail off! Bailing off an automatic brake application will disable dynamic braking during blended braking. This is because the amount of pressure the automatic brake (NOT the locomotive brake though!) is trying to put into the brake cylinders is used to determine the percentage of dynamic braking to use. The "DynamicBrakeHasAutoBailOff" and "ORTSDynamicBlendingForceMatch" parameters both attempt to simulate this behavior, but are inadequate, and OR does not feature the ability to bail off the brakes to disable brake blending.

How it actually works is that an automatic brake application occurs, the automatic brake starts to provide an application to the relay valve. The blended brake system senses this pressure and uses that to set a target dynamic braking position. This seems to vary from locomotive to locomotive, but usually, it's tuned so that a moderate brake pressure corresponds to full dynamic brakes, with any lower brake pressure providing a proportionally lower dynamic brake setting, down to no dynamic brakes at all if the demanded pressure drops below 12-15 psi. This is why doing an actual bail off should kill the dynamic brakes; a bail off drains the brake demand from the automatic brakes, causing the system to set the target dynamic brakes to none. Asking OR to simulate this is basically asking OR to simulate the relay valve, which it should, but is a larger problem than just blended braking.

But we all know that blended braking causes the locomotive brakes to release anyway, but the automatic "bail off" part of brake blending is not actually a bail off at all; the automatic brake application is not canceled, rather the brake cylinders are vented without venting the brake demand from the automatic brake. Locomotives will allow the train brake application to be released and applied from the brake cylinders as appropriate to keep the force roughly constant across the whole operating range of speeds, but OR's idea of a "force match" isn't really right either. IIRC, the way it works in OR is that the locomotive will try to make the dynamic and loco brake combined have the same force as the locomotive brake alone would have. A more realistic way of doing this would be to have brake blending combine the dynamic brakes and loco brakes such that the force is equal to the maximum dynamic brake force (at least, the maximum dynamic brake force achieved by the current dynamic brake target setting), not the maximum friction brake force. In all cases, the locomotive will try to maximize dynamic brakes before using air to save on brake pad wear and tear.


Another key feature of blended braking is that blended braking is managed by each locomotive individually with no communication or connection to other locomotives required. If a freight locomotive is at the front of a train with a passenger locomotive behind it, (assuming the passenger locomotive is operational and has blended brakes cut in), the passenger locomotive will respond to automatic brake applications from the freight locomotive and will apply its dynamic brake as part of brake blending even if the freight locomotive's dynamic brakes are set to off. Conversely, a passenger locomotive in front of a freight locomotive will apply its dynamic brakes when an automatic brake application occurs, but will not sent any command to the freight locomotive to apply its dynamic brakes, it will remain at idle. (However, if the locomotives have brake MU set up, a loco brake bail off in either locomotive would still cancel the blended braking in the passenger locomotive, as bail off is MU'd.)

The dynamic braking caused by blended braking is not sent or received over MU. Meanwhile, in OR, it is sent over MU. You put a freight locomotive in the lead in OR and none of the trailing passenger locomotives will use their blended brakes. You put a passenger locomotive in the lead and suddenly all of the trailing freight locomotives will act like they have blended brakes along with the lead unit, which is frankly dumb.


So the problems with brake blending are extensive and go deep. Overall, the system is unrealistic and much harder to use than it should be (as we can tell, from the HHP-8 situation). I think it reflects some of the larger problems in the simulation of locomotive systems which just make some things far more awkward than they have to be.


Information source: Caltrain MP36PH-3C manual. This thing has blended braking, surprise surprise, and it is explained lots in the manual.

[Csantucci]

Hi Ryan,
it has been implemented that way (that is that dynamic brakes don't release immediately in blended braking) because disc, the code developer thought that it was correct so, that is that dynamic brakes in blended braking release only when the brake pipe returns fully charged. I didn't agree with this at that time, but I couldn't convince the developer (also because I'm not a braking expert), and for that reason I never use blended braking. See here http://www.elvastowe...post__p__196470
I'm happy if you will modify that, because at least in my country the way OR handles it now is not prototypical.

By the way it would also be nice if blending could be a bit parametrized. In my country, when you operate the blended train brake on an electric locomotive, you have a first position where only the dynamic brake is activated. If you move to the subsequent lever positions, also the air pipe begins to discharge. So for minor braking you use only the first position, with the advantage that brake release is immediate, because it is only based on dynamic braking.
See here http://www.elvastowe...post__p__170733

By the way that thread might provide further useful info.

This http://www.elvastowe...es-and-realism/ might also be of interest.

[YoRyan]

Thanks for your insight, pschlik. It's very much appreciated.

pschlik, on 30 October 2020 - 02:38 PM, said:

The first problem is that OR handles mechanical interlocking of the throttle and dynamic brake horribly...

Yes, I agree. All of these points reflect incorrect behavior and deserve fixes.

pschlik, on 30 October 2020 - 02:38 PM, said:

Many blended brake systems will automatically shut off the dynamic brakes below a certain speed. This speed could be customized with a parameter, but 5 MPH is generally a safe bet.

Correct me if I'm wrong, but isn't this handled by the "DynamicBrakesCutInSpeed" property?

pschlik, on 30 October 2020 - 02:38 PM, said:

Then blended braking has yet another trick up its sleeve to prevent the dynamic brakes coming on when the engineer doesn't want them; bail off! Bailing off an automatic brake application will disable dynamic braking during blended braking. This is because the amount of pressure the automatic brake (NOT the locomotive brake though!) is trying to put into the brake cylinders is used to determine the percentage of dynamic braking to use.

Coincidentally, Mr. Dilworth and I have been discussing how to model this exact behavior.

We propose a new boolean property, "OrtsDynamicBlendingUsesEngineBrakePressure", that, if activated, would cause blending to correspond with the locomotive's train brake pressure. Thus, bailing off the locomotive would disengage blended braking.

pschlik, on 30 October 2020 - 02:38 PM, said:

Another key feature of blended braking is that blended braking is managed by each locomotive individually with no communication or connection to other locomotives required.

Oh boy, we got really deep into the MU rabbit hole with the semi-recent new consist format discussion. My position is unchanged: I think it would be a bad idea to simulate such nuances by default. It would frustrate players who inadvertently combine different kinds of incompatible equipment.

Now, make MU compatibility an opt-in difficulty setting, and then we're talking. But then we'd need some way for rolling stock creators to define compatibility with all other pieces of rolling stock, which may or may not involve a new scripting interface. Such a content feature would be very interesting, but would take a lot of thought.

[YoRyan]

Carlo, thanks for the links. I agree with you and pschlik that the lockout behavior is not prototypical and ought to be changed, particularly since it is not present in MSTS. (Not to say that MSTS was the pinnacle of realistic operation, but rather that we need solid justification to break backwards compatibility.)

Csantucci, on 31 October 2020 - 03:20 AM, said:

By the way it would also be nice if blending could be a bit parametrized. In my country, when you operate the blended train brake on an electric locomotive, you have a first position where only the dynamic brake is activated. If you move to the subsequent lever positions, also the air pipe begins to discharge. So for minor braking you use only the first position, with the advantage that brake release is immediate, because it is only based on dynamic braking.

And here in North America, we have the opposite behavior: On the F40PH, the minimum reduction position engages the air brakes exclusively, while subsequent positions engage the dynamics in addition to that.

Considering the wide range of blended braking behaviors, and the frustration that content creators like pschlik have with one-size-fits-all algorithms like "ORTSDynamicBlendingForceMatch", I propose that we introduce a lookup table that maps brake cylinder pressure to dynamic brake application. Content creators would thus have complete control over the blend.

[Csantucci]

Ryan,
I thought more about a mapping from brake controller position to brake cylinder pressure and dynamic brake percent.
If you map brake cylinder pressure to dynamic brake application I don't think it is possible to consider the case of dynamic brake only, because in our case both the case of zero dynamic brake (release position of brake controller) and full dynamic brake(first apply position) correspond to 0 cylinder pressure.