Braking - Wheel Skid
#21
Posted 24 April 2016 - 10:47 PM
This first patch implements the variation of brakeshoe friction due to speed (hence the braking force on the wagon will also vary with speed). For some background reading see this page.
As indicated on the diagram on the reference page, a default curve approximating a cast iron brake shoe is used by OR to vary the friction with speed.
It should be noted that the MaxBrakeForce parameter is (and has always been) the actual force applied to the wheel after reduction by the friction coefficient.
The patch supports the following three modes of operation:
i) Advanced Adhesion not selected - brake force operates as per previous OR functionality, i.e. - constant brake force regardless of speed.
ii) Advanced Adhesion selected and legacy WAG files or NO additional user friction data defined in WAG file - OR assumes the users assigned friction coefficient, and reverse engineers the braking force, and then applies the default friction curve as the speed varies.
iii) Advanced Adhesion selected and additional user friction data HAS been defined in WAG file - OR applies the user defined friction/speed curve.
Option iii) is the recommended method of operating, and naturally will require include files, or variations to the WAG file.
To setup the WAG file, the following changes will need to be made:
i) use the new OR parameter ORTSBrakeShoeFriction ( x, y ) to define an appropriate friction/speed curve. This parameter needs to be included in the WAG file near the section defining the brakes. This parameter allows the user to customise to any brake type.
ii) Define the MaxBrakeForce value with a friction value equal to the zero speed value of the above curve.
See the reference page for an example of how the code is configured in the WAG file.
The FORCES INFORMATION HUD has been modified by the addition of two extra columns:
i) Brk. Frict. - column shows the current friction value of the brakeshoe and will vary according to the speed. (Applies to modes ii) and iii) above). In mode i) it will show friction constant at 100%, which indicates that the MaxBrakeForce defined in the WAG file is being used without alteration, ie it is constant regardless of the speed.
ii) Brk. Slide - added in preparation for next phase and will indicate whether the car wheels are sliding under brake application.
It should be noted that the "Adhesion factor correction" slider will vary the brakeshoe coefficient above and below 100% (or unity). It is recommended that this is set @ 100%.
These changes will add an extra challenge to train braking, but provide a more realistic train operation.
For example, in a lot of normal Westinghouse brake systems, a minimum pressure reduction was applied when moving the brake controller to the LAP position. This is catered for with the MSTS parameter, TrainBrakesControllerMinPressureReduction. Typically Westinghouse recommended values of between 7 and 10 psi. This feature does not appear to be implemented in OR. so when applying the brakes initially, especially at speed, it maybe worthwhile to drop the BP pressure by 7 psi straight away. Previously it was not easily possible to follow this approach as too much brake force was applied at speed, which stopped the train too quickly.
#22
Posted 25 April 2016 - 06:11 AM
#23
Posted 25 April 2016 - 07:34 AM
All I can say is very well done.
Thanks
#24
Posted 25 April 2016 - 10:55 AM
#25
Posted 25 April 2016 - 12:08 PM
Any chance of addressing real buff and draft forces? It would add run-in effects with braking (which could cause skidding and possibly jack-knifing and/or string-lining cars). It would also lay the groundwork for a new multi-player feature: different people tying to manage a train w/ helpers.
#26
Posted 25 April 2016 - 03:04 PM
disc, on 25 April 2016 - 06:11 AM, said:
I am not sure what you mean?
The curve shape, and values are shown in the reference diagram referred to in the above post.
disc, on 25 April 2016 - 06:11 AM, said:
I considered this approach, but felt that this would only complicate things from a coding and model development perspective.
The use of the ORTSBrakeShoeFriction ( x, y ) allows model developers the flexibility to customise the brake friction to any brake type.
In regard to developers not having access to friction curves, information is available on the internet, or alternatively I am happy to host some standard curves that could be cut and pasted into relevant WAG or include files, if people have suitable curves to share.
Genma Saotome, on 25 April 2016 - 12:08 PM, said:
This will probably require a lot more research, so I suspect, to quote Star wars, that it is probably in a a galaxy far far away.
#27
Posted 25 April 2016 - 05:18 PM
#28
Posted 27 April 2016 - 04:39 PM
This feature will identify if a wagon wheel is locked, and started to skid. The braking force will drop, and the train will slide for a significant distance. If a skid condition is encountered, then the brakes need to be released until the wheel starts to rotate again.
Diesel and electric locomotives are excluded from this function at the moment as they appear to be covered in the original base advanced adhesion model.
The main parameters that will influence a wagons ability to skid are the following:
- Force applied to the brakeshoe
- brakeshoe friction
- weight of the wagon
- wheel/rail friction
#29
Posted 27 April 2016 - 10:21 PM
#30
Posted 27 April 2016 - 10:32 PM
ATW, on 27 April 2016 - 10:21 PM, said:
I am still try to work out the code for the animation. Hopefully that will be the next component added.
#31
Posted 27 April 2016 - 10:35 PM
#32
Posted 28 April 2016 - 08:17 AM
#33
Posted 28 April 2016 - 10:27 AM
Quote
Quote
This will probably require a lot more research, so I suspect, to quote Star wars, that it is probably in a a galaxy far far away.
My gut tells me it shouldn't be that hard to try out but the implications of having it as a feature are hard to tell.
Basically a solution would involve identifying subsets of a train where each set is composed of those cars that have an adjacent car in a full draft or full buff relationship. "Full" could mean 100% to either end of the draft gear movement... or for practical purposes, maybe a bit less. The sets, having no slack within should move as a solid unit WRT the train. The relationship between sets represent what is called a node. A train going up or down a grade will soon reach a state where it has no nodes (absent helpers) and so is represented by one set. To create a node one has to change the power output so the acceleration (or deceleration) causes as change of state at some coupler pair. The location of a node or nodes will change depending on both train handling, terrain, and the presence or absence of helpers.
As for what the feature might do... seems likely to change train handling behavior on long trains, especially when they start; It could be an enabler for a train surge against the locomotive on a big run-in; Plausibly it should dynamically change the load the locomotive is pulling; A big run-in on some empty cars could cause a jackknife; Last, it doesn't appear to me that the total length of our trains vary as they should and so perhaps this might help address that too.
#34
Posted 28 April 2016 - 12:27 PM
I feel it won't be so hard as the current run out coupler Break code can be used as template but in opposite force triggers being bunched instead of stretched. If bunched break coupler forces can't use a part of the coupler settings "Break( 2nd space value)" there is always those 2 MSTS parameters that can be the trigger limits to code an target.
They come of no known use in ORTS yet but are present in almost every file:
DerailRailForce ( 2.5N/kg*23t )<---Implement to use for how much ton force opposing cars are against where coupling speed limits from derailing may be of no use like MSTS default.wag but by run in mass an speed is against opposing cars bunch forces an limits.
DerailBufferForce ( 900kN )<-------Implement to use for bunched run-in coupler/hose Break push limit disciplines.
#35
Posted 28 April 2016 - 02:42 PM