[Weter]

Hello.
Doing test rides with diesel-electric locomotives, have spotted: max speed parameter is likely ignored.
Speed continues to grow exponentially towards 200km/h and maybe higher.
I won't say here about friction and aerodynamic resistance to keep the thread "clear", but electric motors have strictly defined speed, where self-induced counter current in coils becomes equal to current, supplied to motor at given voltage, so further rotation speed's growth is impossible, and excess speed growth on downhill will encounter dynamic brake-like counteraction. Currently, I can't see that.

[Aldarion]

Well. If this is adressed, we may see in the future something I'd love to have: field reduction (otherwise knows has shunting)

[Weter]

Yes, this is wide-spread walk around way to allow shifting of saturation speed higher, by increasing possible current in given voltage, though not economic at all.

[joe_star]

Hmm, it's worked in the past I am sure. Electrics (and diesels) should unload or have their force drop steeply once the max velocity is reached.

[Weter]

Indeed.
That worked earlier.

[joe_star]

Aldarion, on 30 March 2024 - 01:30 AM, said:

Well. If this is adressed, we may see in the future something I'd love to have: field reduction (otherwise knows has shunting)

Even the simple behavior of unloading the tractive effort at "MaxVelocity" is now ignored. This is definitely a bug and I confirmed it affects Diesels as well

E.g.

Type ( Diesel )
	MaxPower ( 2300kw )
	comment( est estimated by comparision with dash9 )
	MaxForce ( 298kN )	
	MaxContinuousForce ( 240kN )
	MaxVelocity ( 75mph )
	MaxCurrent ( 1800A ) 
	WheelRadius ( 20in )

However loco accelerates to 300kmh+ in recent builds

https://i.ibb.co/BCwXLyP/Open-Rails-2024-04-02-12-49-34.png

In older builds the power & force would unload once MaxVelocity is achieved

https://i.ibb.co/KKFkJz1/Open-Rails-2024-04-02-12-46-49.png

On a positive note, all my old MSTS diesel & electric locomotives are now High Speed Rail capable :)

[joe_star]

Weter, on 29 March 2024 - 09:57 PM, said:

Hello.
Doing test rides with diesel-electric locomotives, have spotted: max speed parameter is likely ignored.
Speed continues to grow exponentially towards 200km/h and maybe higher.
I won't say here about friction and aerodynamic resistance to keep the thread "clear", but electric motors have strictly defined speed, where self-induced counter current in coils becomes equal to current, supplied to motor at given voltage, so further rotation speed's growth is impossible, and excess speed growth on downhill will encounter dynamic brake-like counteraction. Currently, I can't see that.

Hello

I looked into the diesel code and found that this is indeed the case that MaxVelocity is no longer being considered for "unloading"

A new parameter was introduced at some point called ORTSUnloadingSpeed.

ORTSUnloadingSpeed ==> is the locomotive speed when the generator reaches its maximum voltage, and due to the speed of the train, the engine starts to ‘unload’. Typically beyond this speed, power output of the locomotive will decrease.

This is implemented such that power declines linearly from the unloading speed to 0 at 2 times the unloading speed.

I made a small change to my own branch to reintroduce unloading based on the MaxVelocity parameter, as I dont intend to update all 250 of my diesel locomotives. Add this just below the existing unloading code

                    else if (UnloadingSpeedMpS == 0 && AbsTractionSpeedMpS > 0.8f * MaxSpeedMpS && !WheelSlip) // If no unloading speed in ENG file then unload power between 80% to 120% of MaxVelocity
                    {
                        float unloadingspeeddecay = 1.0f - ((2.5f * AbsTractionSpeedMpS / MaxSpeedMpS) - 2.0f);
                        unloadingspeeddecay = MathHelper.Clamp(unloadingspeeddecay, 0.0f, 1.0f);  // Clamp decay within bounds                        
                        maxPowerW *= unloadingspeeddecay;
                    }

[Weter]

Hello.
Thanks for an interesting update!

Quote

as I dont intend to update all 250 of my diesel locomotives

Otherwise, ORTSUnloadingSpeed at about half of MaxVelocity should be added into each of */eng-files?

[joe_star]

Hello

If you know the rated rpm of your locomotive traction motor, then the wheel speed at this rpm would be the unloading speed.

For a guesstimate, I think 60-70% of MaxVelocity would work such that the locomotive can still achieve the maximum velocity.

[pschlik]

I recommend being careful with the ORTSUnloadingSpeed and not using it randomly, it is not a suitable simulation of a locomotive overspeed sensor. It should specifically be used only when you know the locomotive in question hits a voltage limit at speed, which would show up on tractive effort curves as a deviation below the constant horsepower curve at high speed. This will not be true for all locomotives, some generators are beefy enough or engines weak enough that they won't reach maximum voltage even when the locomotive is at max speed. For example, I know for sure that the GP40-2 reaches maximum voltage at 60 mph, but the SD40-2 won't be at max voltage even at 65 mph because real data indicates as such.

I also disagree with the implementation of ORTSUnloadingSpeed, as a linear decrease in power output toward 0 is not what happens in real life. When considering series wound motors given a constant voltage (in this case, the max generator voltage) the power output has a sort of exponential decay as speed increases, never actually reaching 0 power output no matter how fast the motor spins. This means a series wound motor will gladly explode itself when given even fairly low voltages under no-load, and is why series wound motors aren't very popular outside industrial applications.

The real solution here is to make custom tractive effort curves that implement whatever high speed behavior you want using real data, rather than approximations bolted on top of MSTS-era physics.

[Weter]

Hmm...
I understand Your words, Phillip, in such way, that the phenomenon, we see, isn't an ORTS bug at all, but an expected result of tractive force curves lack in *.eng-files, right?
Then, let's think about possible addition of some check (in analogy with missing steam parameters case), when ORTS runactivity would read obsolete max velocity parameter and apply some default speed limitation (logging this action for user to be aware)...
There are friction and aerodynamic (latter grows in quadratic progression with speed) resistance, which never allow locomotive with "saturated-state" electric transmission to reach 300km/h

[joe_star]

pschlik, on 10 April 2024 - 12:21 PM, said:

I recommend being careful with the ORTSUnloadingSpeed and not using it randomly, it is not a suitable simulation of a locomotive overspeed sensor. It should specifically be used only when you know the locomotive in question hits a voltage limit at speed, which would show up on tractive effort curves as a deviation below the constant horsepower curve at high speed. This will not be true for all locomotives, some generators are beefy enough or engines weak enough that they won't reach maximum voltage even when the locomotive is at max speed. For example, I know for sure that the GP40-2 reaches maximum voltage at 60 mph, but the SD40-2 won't be at max voltage even at 65 mph because real data indicates as such.

I also disagree with the implementation of ORTSUnloadingSpeed, as a linear decrease in power output toward 0 is not what happens in real life. When considering series wound motors given a constant voltage (in this case, the max generator voltage) the power output has a sort of exponential decay as speed increases, never actually reaching 0 power output no matter how fast the motor spins. This means a series wound motor will gladly explode itself when given even fairly low voltages under no-load, and is why series wound motors aren't very popular outside industrial applications.

The real solution here is to make custom tractive effort curves that implement whatever high speed behavior you want using real data, rather than approximations bolted on top of MSTS-era physics.

Correct. The decay is exponential. The critical speed or unloading speed can usually be found in locomotive tractive effort charts

https://i.ibb.co/HxdYnVp/978-1-4419-0851-3-20-Part-Fig13-800-HTML.png

I suggested using 60-70% as above as this allows MSTS defined locomotives to achieve what their "MaxVelocity" at which point the power balances out with friction forces, within the current implementation (which I also agree is inadequate)

In the current OR implementation, MSTS defined locomotives are essentially unlimited in their speed capabilities especially when running single or with a light load, because no reference to limiting the power output at MaxVelocity is defined anymore. Ideally we should still have an absolute check on MaxVelocity that cuts the power output (representative of some form of speed control)

Quote

The real solution here is to make custom tractive effort curves that implement whatever high speed behavior you want using real data, rather than approximations bolted on top of MSTS-era physics.

That's a solution that abandons MSTS compatibility though, and impacts a huge collection of MSTS locomotives (the Indian railways content I use is pretty much entirely defined with only MSTS parameters)