[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.

[pschlik]

Oh this was never about slip control, it's basic laws of physics that as a motors RPM (not the speed of the vehicle the motor is attached to) increases, the torque/force decreases.
The wheel speed is the best source of data we have in Open Rails to estimate the motor RPM and model this relationship in an approximate way. Ground speed on the other hand is a terrible estimate of motor RPM.

https://fletchermoorland.com/cms/wp-content/uploads/2017/01/series-motor.png

Torque vs speed for some small series wound motor at a constant voltage. These specific stats are not applicable for any train, but as the radians per second (ie: shaft speed/wheel speed) of the motor increases, the torque decreases. Nothing here has anything to do with the ground speed.
https://www.researchgate.net/profile/Bjorn_Kvaale/publication/318209764/figure/fig5/AS:540704724221954@1505925460511/This-figure-shows-the-torque-vs-speed-characteristics-of-a-typical-ideal-3-phase-AC.png

Similarly, AC motors also have a force curve that depends on the RPM speed of the motor, not the ground speed of the vehicle the motor is driving.

I am using the real world as a reference point here, it's just that 1.3.1 coincidentally happened to do a better job at modeling this, and I felt it easier and more effective to say "but 1.3.1 did it correctly" rather than trying to go on a wild goose chase for data on locomotive motors that does not exist.
Just for reference, if 1.3.1 had been using ground speed I would still be complaining trying to get the wheel speed to be used instead, but I might have started complaining years ago. I just wouldn't be comparing anything to 1.3.1 in that hypothetical situation.

[superheatedsteam]

 pschlik, on 03 March 2021 - 10:05 PM, said:

rather than trying to go on a wild goose chase for data on locomotive motors that does not exist.

It does exist, I've seen some of it. Each year, railroad operators and manufacturers around the world spend millions of dollars on research and development to obtain this data in order to improve efficiencies and reliability. I have found numerous published papers or abstracts relating to railroad engineering that make my head swim with the maths involved.

In addition to the above, modern locomotives have computer systems that log many of the parameters of the locomotive and train systems for performance and train handling analysis.

As you appear to have an understanding of the laws of physics, I would respectively suggest that if you are not a programmer and unable or unwilling to read and learn the source code, that you pseudo code a wheel/rail interface model and submit it to peer review by the community. If a consensus on the submission or improvements is reached, this can be presented to the development team who can look at adding it to the simulation code when they have time.

Ask not what can the Open Rails programmers do for us, but what can we do for the Open Rails programmers.