[pschlik]

Erick mentioned problems with wheel slip and excessive wheel speed in the 2021 wish list thread. As I had also experienced this problem and considered the effect very unrealistic, I was motivated to investigate further and compile a reasonable bug report.

First, the problem: When weel slip occurs (and with no AntiSlip or ORTSWheelSlipCausesThrottleDown parameters active), the speed of the locomotive's wheels increases a lot. Using a TrainSimulations GP38-2 with the speedometer tweaked to show speeds up to 10,000 mph, we can see that wheel slip results in incredibly excessive speeds at the wheels. I hope we can all agree this should be completely impossible. (Note that this test was performed with 100% adhesion factor correction, and the train brakes applied to prevent the thing rolling away on me.)
https://i.imgur.com/03EHN8Q.png

Oddly enough, I find it impossible to get a speed in excess of 2237 mph. However, this is exactly 3600 kph, or 1000 m/s, which is too convenient of a number to be anything other than a hardcoded limit. (And as Erick mentioned, this is roughly Mach 3.)

For reference, the TrainSimulations physics means this GP38-2 will normally stop putting out power completely at 190 mph. When it wheel slips, I would expect the speed of the wheels to never exceed 190 mph as without traction at 190 mph, the wheels shouldn't be able to slip up faster than that.
https://i.imgur.com/ExvWA6o.png

Obviously, the sim isn't always preventing tractive effort above 190 mph, otherwise, wheels wouldn't slip up to Mach 3. For some reason, the GP38-2 is not allowed to produce any traction above 190 mph when driving normally but is allowed to produce traction above this speed when slipping. This definitely doesn't make sense, and as the HUD shows, results in quite an impressive horsepower output for a locomotive that should only be capable of 1,700 horsepower at rail.
https://i.imgur.com/Cne9XJq.png

And here's what I think is the explanation: It would seem that whatever bit of code that decides how much traction a locomotive can produce is mistakenly using the "true" speed (radar speed/speed the HUD displays/whatever you want to call it) of the locomotive as the input to the tractive force curves when it should be using the wheel speed as the input. This can be verified by looking at the axle drive force, which will display the expected force output not for 2237 mph, but for 0 mph (or however fast the train is moving.)
https://i.imgur.com/JNyxnyN.png


This is a fairly simple mistake, likely just use of the wrong "speed" variable, and is an understandable assumption to make as the true speed and wheel speed are usually equal or close to equal. However, by definition, this assumption is wrong during wheel slip and produces inaccurate results during wheel slip (hence, this bug exists).


And the solution: To resolve this, the code should be changed to check tractive force curves against the current speed the wheels are rotating at, rather than the speed of the locomotive itself. This will improve the accuracy of the simulation, as in real life the tractive output of a locomotive is limited by the back EMF of the motors, which depends on the speed the motors are rotating at, and not the speed at which the locomotive is itself moving.

Hopefully, this change could make wheel slip more manageable and less physics-defying. Though I still agree that a larger rework of diesel electrics is required to even have a chance of realistic wheel slip simulation, this right here is a good place to start.


By the way, this is NOT a problem on the stable 1.3.1 version of Open Rails! Wheel slip is actually much easier to manage in the stable version as tractive effort depends on the speed of the wheels (just as it should), so something was changed in unstable releases since then that has broken physics. I would go searching for the exact version where this was introduced but I suspect someone else knows more than I do about where to look for changes that may have introduced this bug.
https://i.imgur.com/iLRS3fs.png
https://i.imgur.com/tVs4qp7.png

[Jean-Paul]

Hi,
I think I'm not alone to have noticed serious inconsistencies since stable 1.3.1. !
Wheelslip seems random : with almost same axle weight, and same tractive effort, differences between axle drive force and axle out force may vary from 2.5 % up to 8 %....
You can also read my post on bug in follow-up of tractive effort curves with testing version 1.3.1.296 (and certainly older ones)
Cheers,
Jean-Paul

[pschlik]

Jean-Paul, on 20 February 2021 - 03:17 PM, said:

Wheelslip seems random : with almost same axle weight, and same tractive effort, differences between axle drive force and axle out force may vary from 2.5 % up to 8 %....

Funny you mention that, I also noticed the same oddities between axle drive force and axle out force, and I believe there are some serious faults in the force simulation. I am writing up another post about that issue right now and should have it posted in a few hours.

[scottb613]

Hi Folks,

Hah - you should see the wheel slip on a steam locomotive where it's really noticeable. Have a Trello card in on that one myself...

Regards,
Scott

[pschlik]

scottb613, on 20 February 2021 - 05:01 PM, said:

Hah - you should see the wheel slip on a steam locomotive where it's really noticeable. Have a Trello card in on that one myself...

The effect is definitely more spectacular on the steamers, but the steam locomotives don't generate quite as much easy to dig into data. It's a bit easier to prove my point numerically with the diesel locomotives, and we all know how it's all about the numbers.

[steamer_ctn]

Before making any changes I want to ensure that I have a good understanding of how things are supposed to work.

Firstly I believe that we are talking two different scenarios, ie:

i) Normal Operation - no wheel slip
ii) Wheel Slip

Secondly, as I understand it, OR uses the Advanced Adhesion (Wheel Axle) model to represent the impact of the forces on the locomotive wheels due to wheel slip, etc. In real life the diesel engine, generators, etc would be providing the input force into this model, and so this force would be related to the output of these components, not the wheel or train speed.

In OR the Axle input force is provided by the tractive force curves, which in reality is not 100% correct as these curves are supposed to represent the actual force between the rail and the wheel. The OR Axle model in most instances reduces the input force as the wheel speed changes (allowing correction for minor wheel slip), hence we will never achieve the "stated" rail force specified in the tractive curve. Provided we keep the errors a low as possible, this is probably not a big issue.

In some situations the wheel speed and the "real" train speed are the same, so the reduction in force to the rail is minimal. However in some instances the difference in speed between the wheel speed and the real speed can be larger. I have made the wheel speed visible in the HuD to allow some visibility of it. The video posted by hroc shows some instances where there is a difference between the two speeds.


Normal Operation - So initially looking at scenario i), where there is no or "minimal" wheel slip (which is normal) , the input force should be calculated from the TE curve using the the real train speed. If the wheel speed is used in this instance then the input force will initially be corrected for any minor wheel slip, and then this force will be further corrected within the Axle model. V1.3.1 was doing this double correction in the normal operating condition.

Wheel Slip - So if we start by considering an early generation DC diesel locomotive without any slip control fitted, what happens when wheel slip occurs?

Initially the friction between the wheel and the rail will dramatically decrease and effectively the wheel will have "no load" to balance the driving force on it. If wheel-slip occurs on a Series-wound DC drive, there is the tendency for the traction motor to speed up and run away, even to the point of mechanical failure if the power is not reduced quickly. The driving force (or input force in our situation) will remain the same until it is changed by some action. In the case of an early diesel, typically the driver would be expected to reduce the throttle position as soon as possible to reduce the force applied to the wheel. So in this instance perhaps the current operation is realistic, perhaps all that is needed is a failure mode to represent the mechanical failure of the motors at excessive speed?

The above scenario may vary where the traction motor is an AC. So depending upon the transmission type, ie DC, AC, hydraulic, etc, there may potentially be different responses, eg from full motor runaway (excessive speed on the wheel), to a more controlled scenario perhaps with an AC motor (due to back EMF?).

So if the wheel speed is used in the slip scenario, it will be adjusting the input force down (as you suggest), and therefore what reduction mechanism are we modelling in OR by doing this? Are all different locomotive traction types catered for with this type of approach? What about Electric Locomotives? What about hydraulic Locomotives?

If a full throttle reduction is applied by the driver once wheel slip occurs, does this not make controlling wheel slip manageable (before the wheel has a chance to speed up) and realistic? Do any of the current anti slip controls in OR manage wheel slip (and hence the input force) in an effective manner?
If we are able to implement only one traction type at the moment, then which one do we select?

[pschlik]

I think there's some confusion here about the core physics governing wheeled vehicles...Firstly, no, the current behavior is not correct for any type of transmission. 1.3.1 has the correct behavior. The wheel speed should be used as the reference value for the "input" force (before wheel-to-rail losses), instead of the train speed.

In all transmissions, a big concern is providing relatively constant power to the wheels at a wide range of speeds, everyone has some intuitive understanding of this. But note that a transmission can only manage how power is applied to the wheels and that the "wide range of speeds" is technically a "wide range of wheel speeds". The transmission has no correlation or connection to what happens at the rail, that's for other systems to figure out, and we aren't talking about those. The speed of the wheels, and consequently the speed of whatever is directly geared to the wheels, is what governs the force that can be put into the transmission; NOT the speed of the vehicle relative to the ground. To maintain constant power going into the wheels, as the speed of the wheels increases, the torque/force going into the wheels must naturally decrease. If the torque doesn't decrease, then the power would have to increase, so (putting aside things with very strange relationships between torque and speed), this means the force going into the wheels will generally decrease as the wheels spin faster. This doesn't necessarily mean the power output to the ground is remaining constant, nor that the wheel speed has any correlation to the ground speed. But the transmission does not care about what the ground is doing, all that matters to it are what the wheels are doing.

The problem in Open Rails is that there is all sorts of confusion between where to use what's coming in to the wheels (from the engine) versus using what's going out of the wheels (to the rails), generally leading to overuse of quantities relating to what happens at the rails when the focus should be on the wheels. While I can understand Open Rails attempt to use the train speed as the governing factor for force and power, it so clearly leads to nonsense results that do not portray reality in the slightest. That's what I've been trying to demonstrate this whole time.

I feel that it is necessary to point out again how this level of physics has produces unreasonable results even in the in-game debug displays.
Note that the power going into the axles is a massive 363,830 horsepower because there is a massive amount of force going into the axles and the axles are going very very fast. Yes, the train is completely stopped and the power at the rail is zero, but the speed of the train and the power at rail is not the only thing that matters!
https://i.imgur.com/MTPZoIk.png

Yet, despite the massive power input into the wheels, if we then look at the locomotive information debug, the engine claims it is completely unloaded because the power at rail is used to determine the engine load. It should be obvious that this is incorrect, the load on the engine is determined by the amount of engine power going out of the engine, which is approximately the power going IN to the wheels, not what comes OUT. The engine doesn't care what happens at the rail because the engine is not directly connected to the rails!
https://i.imgur.com/9h6lkbY.png

This actually violates the law of conversation of energy. While 1619 horsepower is coming out of the engine, somehow 363,830 horsepower is entering the wheels! Where is all this extra power coming from? It's easy to claim that these results are reasonable if the power going into the wheels is ignored, but I sure hope nobody thinks it's reasonable that 1619 traction horsepower is leading to over 200 times as much axle power!


I do hope this is enough to prove my point. I would rather not have such physics-defying behavior in this simulator.

[steamer_ctn]

pschlik, on 26 February 2021 - 11:58 AM, said:

The problem in Open Rails is that there is all sorts of confusion between where to use what's coming in to the wheels (from the engine) versus using what's going out of the wheels (to the rails)

I agree, and therefore I believe that it is important to review and confirm what is happening within OR, including v1.3.1.

pschlik, on 26 February 2021 - 11:58 AM, said:

This actually violates the law of conversation of energy.

I agree that the conservation of energy principle should apply, and the input power to axle model should remain constant until the throttle position is changed.

As you suggest the speed and force values will change, but they should still combine to give the "expected" constant power value as an input.

I want some time to reflect on what is currently happening, and what should be happening a bit more, so I may not respond for a couple of days.

[steamer_ctn]

I have done some quick research using a couple of sources to try and confirm my thinking - source1 and source2.

So based upon the these documents, my perception for a real world situation is still:

i) That when slip occurs, the input force to the traction motor should, without any external influence (such as a slip control system or the driver reducing the throttle setting), remain the same as the pre-slip value.

ii) The wheel speed, if left unchecked will increase to significant values. In the case of some DC motors it will cause the motor to fail, throw electrical coils out of the ammature, etc. So without further research, I don't know what value this speed is typically. Similarly for AC motors there maybe a limiting wheel speed, but again I am not sure what this might be at this stage.

As discussed, OR uses an axle module to "manage and simulate axle forces considering adhesion problems" (from OR developer notes). From the developer notes, this model seems to support three different scenarios as follows:
i) No Drive
ii) Traction motor connected through gearbox to axle
iii) Simple force driven axle

Currently only iii) above is used by OR, so it appears that the original developer had not completed their development work for this module. In addition it appears that it was going to have the ability to take into account some different electric motor attributes.

There appears to be no provision for any speed limitation in the model, eg for the speed failure points of DC or AC motors, etc. Hence wheel speed will keep increasing while ever there is sufficient input force to drive it up. In a real world situation, either the driver or the slip control system would reduce the throttle setting as soon as slip started happening (thus reducing input force), so in theory large speeds would not normally be reached. As the model does not have any speed limitation provision, it appears that the developer elected to added a "pseudo" slip control feature external to the axle model, which reduces the input force as the wheel speed increases.

Hence this means in its current form it is only modelling locomotives, with a basic slip control system. Wheel slip can still occur in this model, whereas with more modern locomotives a more advanced system might reduce the throttle setting to ensure that wheel slip does not occur. Early model DC locomotives would need some code changes to model them as no slip DC locomotives cannot be modeled currently.

As in real life, I would expect a driver in OR to manage wheel slip by reducing the throttle in order to bring wheel slip under control as soon as they start to experience wheel slip. Alternatively a more sophisticated slip control system would need to be incorporated into the locomotive control.

Given the fact that I currently don't have any more time to spend on the necessary research and thinking required to make large code changes in this area, and also given the fact that users are used to OR operating in this fashion currently, I have reinstated the "pseudo" slip control system for the axle model when slip occurs, until functionality can be added to make it possible for the user to select between, no slip, basic slip, and fully automated slip control.

The changes have been uploaded to the latest unstable version. To help users (and myself) to understand more about what is happening in the Axle model, I have also added a couple of extra values to the HuD. The first is the "equivalent" input power in the Force In line. The second two are the "axle speed" and following this value the "slip speed".

Also whilst running a few tests I found some unusual happenings in v1.3.1 when using dynamic braking and wheel slip with flipped locomotives. These haven't been investigated further.

[pschlik]

Thought about this some more, and I believe boiling down this issue to a bunch of individually manageable changes can provide an approachable way to improve this part of physics so it hasn't regressed from 1.3.1 and is easier to understand for future reference.

First, create some distinction between the axle input power (axle drive force & wheel speed) and the axle output power (motive force & train speed).
-It's clear that right now, there's not enough attention paid to the difference between what goes into the axle and what comes out; including the distinction in code is a step toward understanding the distinction

To fix the main "bug" reported here, change the physics to target a constant axle input power, instead of whatever it does now.
-Basically, change calculations for axle drive force to use wheel speed instead of train speed; that'll create the intended behavior and preserve the laws of physics

For added clarity, set engine load to be based on the axle input power, rather than the motive power.
-Don't think this would change physics at all, but this is a more realistic way to calculate load, and it may be relevant for the future

Additionally, LOAD_METER instruments inside cab views should also use the axle drive force, rather than the motive force, to calculate the displayed value
-A minor change, yes, but a further part of correctly representing the difference between what goes in and out of the axles; load meters can only measure what is going in

While we are at it, also tweak motive force calculations to not subtract the locomotive air brake force, as that causes a problem as I elaborated on here
-This is a somewhat different issue that appears to be an entirely different mistake but is still affecting the same part of the physics system
-By the way, it's fine to leave the calculations of wheel slip, wheel slip losses, and inertial losses unchanged, only brake "losses" are an issue

Individually, each of these changes is deceptively simple...add a variable here, replace a variable there with something else, that kind of thing. I'm sure there would be all sorts of regression testing required, but the point is that the physics are built on reasonable foundations, it's just a few specific calculations and behaviors that have been implemented in unusual ways, leading to infamous problems like wheels going Mach 3 and the ammeter bouncing around. Also, as few of these changes actually affect physics, and many would just be done for clarity and accuracy, it is highly unlikely these changes would ruin any old content. In fact, resolving Mach 3 wheel slip would most likely make old content easier to work with.

And for comparison, version 1.3.1 only obeys the second point. So, it's better than the testing version at obeying the laws of physics, but still somewhat confuses things in these other aspects, which is why we ended up here confused about what physics is and should be doing.

[steamer_ctn]

pschlik, on 28 February 2021 - 09:10 PM, said:

Thought about this some more, and I believe boiling down this issue to a bunch of individually manageable changes

I agree that any changes should ideally focus on small areas at a time.

pschlik, on 28 February 2021 - 09:10 PM, said:

First, create some distinction between the axle input power (axle drive force & wheel speed) and the axle output power (motive force & train speed).
-It's clear that right now, there's not enough attention paid to the difference between what goes into the axle and what comes out; including the distinction in code is a step toward understanding the distinction

I am not 100% sure exactly what you mean by this?

The challenge we have is that OR uses the (motive force & train speed) curve as its principal reference source. Users have been setting up their ENG files based upon this understanding.

The Axle model then uses (motive force & wheel speed) as its input when the wheels are slipping, which then produces typically a (reduced) axle drive force out as the "new" motive force. So the motive force may not match the value that the user thinks that they are configuring.

So with v1.3.1 and to a lesser extent the current unstable version there is a whole mishmash of forces and speeds used to try and build a working real world model.

If you are interested to look at any potential "improvements" that we can make with me, I would be happy to set aside some time. (However as I have some other stuff that I need to get back to, it would need to be as a second priority). This investigation would require some research and testing tasks (in my test environment).

But if we do this I would like to move to email correspondence as we will need to share information, and it is easier to do this via email. If you are interested, contact me via the CTN site to set up the process.

[pschlik]

Sent in my detailed thoughts. I worry that we are forgetting about the users and developers who made content for 1.3.1 and how the more recent changes in physics are causing their content to behave in unintended and unrealistic ways, but that is a concern for future discussion.

[steamer_ctn]

pschlik, on 01 March 2021 - 02:28 PM, said:

Sent in my detailed thoughts.

Thanks for that.

pschlik, on 01 March 2021 - 02:28 PM, said:

I worry that we are forgetting about the users and developers who made content for 1.3.1 and how the more recent changes in physics are causing their content to behave in unintended and unrealistic ways, but that is a concern for future discussion.

That has been an ongoing question ever since the first piece of new functionality was added on "top" of the original MSTS content.

Within reason if the power/force values are correctly set in the ENG files there shouldn't be a great deal of difference in behavior, if any thing there may be some minor improvements in pulling performance pre-slip.

[pschlik]

I replied to your email reply directly, but with the way the system works, I'm not sure if that got to you as it's almost been two days and I've not heard back. For now, the short version of my second mail is that I'm not actually concerned about reverting all the physics to 1.3.1, just the wheel slip behavior from 1.3.1 is what I'd like to see. I know some other changes were made, and those didn't really cause any trouble, feel free to leave the rest of it as is.

Also, I have noticed some changes in behavior in the unstable versions from this week, but the problem does not appear to be fixed, only acting a bit different instead. Wheel slip is less extreme than before, but still too extreme. I'm observing that the axle drive force during wheel slip will jump around rapidly, alternating between using the force produced by the train speed and force produced by wheel speed. I don't really know why this is happening, but I suppose this is progress, in a way? At least sometimes the correct amount of force is applied.


Now, the speculation:
If I am reading this correctly, it looks like when the wheel slip % is above 100%, the wheel speed is used, but when below 100%, train speed is used. This is an acceptable solution in theory (though it begs the question why not use wheel speed all the time?), but it appears that something is wrong with the calculation of the wheel slip %, as even when the wheels are spinning 200 mph faster than the train is actually moving, the wheel slip % hovers around 100%, sometimes going above 100% sometimes going a bit below.
Surely if the wheels are 200 mph faster than the train speed, the wheel slip % should be consistently over 100%? I'd expect a wheel slip % of a few hundred, maybe even a few thousand %. Granted, I am not entirely sure what the wheel slip % actually represents, but I am given the impression it is not working as intended.

Heck, sometimes I can get the wheels to be slipping 100s of mph above the train speed, and the game will tell me no slip is occurring! I believe this issue is totally unrelated to the focus of this bug report, but is still a related problem. May be worth investigating.

[steamer_ctn]

pschlik, on 03 March 2021 - 01:35 PM, said:

I replied to your email reply directly, but with the way the system works, I'm not sure if that got to you as it's almost been two days and I've not heard back. For now, the short version of my second mail is that I'm not actually concerned about reverting all the physics to 1.3.1, just the wheel slip behavior from 1.3.1 is what I'd like to see. I know some other changes were made, and those didn't really cause any trouble, feel free to leave the rest of it as is.

As suggested I have other projects that I am working on so I don't always respond to all my emails instantaneously. Also sometimes things need to be thought about and studied before responses are generated.

pschlik, on 03 March 2021 - 01:35 PM, said:

Also, I have noticed some changes in behavior in the unstable versions from this week,

As indicated in this post, I have reluctantly restored the functionality whereby when the wheels start slipping (indicated by the "wheel slip" indicator) the wheel speed is used to calculate tractive effort ( as per v1.3.1). I still don't believe that this is the correct approach at the moment, but it was done as an expediency to accommodate yours and others concerns.

One of my biggest concern is when we reference a particular version of OR (or MSTS for that fact), and make comments like, "it should work just like it did in verXXX". Who knows what errors are hiding in verXXX? Instead I strongly believe that we should be looking at the real world, and using that as our reference point.

pschlik, on 03 March 2021 - 01:35 PM, said:

Heck, sometimes I can get the wheels to be slipping 100s of mph above the train speed, and the game will tell me no slip is occurring! I believe this issue is totally unrelated to the focus of this bug report, but is still a related problem. May be worth investigating.

So this is an instance where using the wheel speed may not be good, and may result in an unnecessary power reduction for the locomotive. This is why it is not always good to use the wheel speed. As to why the axle model is behaving like this I don't have a clue at the moment.

As suggested above I am a strong believer in using real world information for any changes to OR. I also believe that before we model something we need to understand what we are modelling. So I am not interested in doing any further changes unless a fuller understanding of what and why we are trying to develop is created.

For example, when the changes were made to the tractive effort real world test reports were used as the reference material. The test stock for these changes were based upon work and operating procedures from Norfolk Southern(NS). NS seems to go to a lot of trouble to set the performance standards for their diesel locomotives so that they won't normally experience slip events. They also expected drivers to control slip, and not to remain in a slip event for a long period of time. Hence to them slip was a bad thing and to be avoided.

For those interested the stock can be downloaded from here - NS stock . The report referenced in the first paragraph of this stock is a highly recommended read, and provided the outcomes against which the changes and stock were tested against.

Some other documents which might be of interest at a high level.

This document provides the rules for operating and handling the locomotive, and has some references to slip in it.

This document has some references to different slip control systems fitted to particular locomotive types.

As suggested in my earlier posts I don't believe that v1.3.1 is a full slip control system, rather it is only a means to maintaining the operation of the axle model within "stable" bounds, and hence it can't be expected to behave in the same way as modern full slip control systems. Code changes would be required for this to be addressed.

So in short the wheel slip has been returned to v1.3.1 functionality, ie using wheel speed.