[edwardk]

Is advanced adhesion still a work in progress. I sometimes switch back and forth between simple and advanced adhesion, but this is the first time I tried using it in snow and on a 1.3% grade. I get the wheel slip message and I lose all traction. All drive axles spin like crazy. Sanding does not help at all. I tried using the ORTSDriveWheelWeight() parameter, but no change.

Edit: I am using diesel locomotives.


Edward K.

[engmod]

It does not do what I expect either, especially with AC units.

[ATW]

Try converting the drive wheel weight into LBS. If you need more details I will be glad to help when I get home.

[copperpen]

For steam and early diesel/electric locomotives I have no problems with advanced adhesion in snow. Just reduce the load or add a locomotive to the consist.

[edwardk]

Yes, converting the initial value for ORTSDriveWheelWeight() to lbs did the trick. Keep in mind that the default is flawed because if you do not use ORTSDriveWheelWeight() and advanced adhesion is selected, the default is to use the Mass value directly and this is when I first experienced the issue. The initial metric ton value must be converted to lbs so this is an actual bug. Based on my notes, to convert metric ton to lbs, metric ton is multiplied by 2205 or 2204.6(176.9t*2205 = lbs).

Edit: I meant to multiply, not divide.

Peter, if you read this, this is a bug.

Edward K.

[edwardk]

ORTSDriveWheelWeight is processed as kilograms, but it appears that Mass needs to be converted to lbs first, then to kilograms.

Edward K.

[steamer_ctn]

edwardk, on 26 October 2016 - 01:26 PM, said:

Peter, if you read this, this is a bug.

I am sorry, but I don't quite understand the bug.

As suggested the OR code reads the value ORTSDriveWheelWeight() from the ENG file as a Mass quantity. The STFReader reads the value and then converts the value entered into kg to be used internally within OR.

The STFReader will accept any of the following units of measure (UoM): kg, lb, t (tonne), tons (uk) or tons (us). If no UoM are included in the parameter, then the STFReader assumes that the value is already in kg, and uses the figure directly as entered.

The UoM must be specified for correct conversion by OR, eg ORTSDriveWheelWeight( 104.0t-uk ).

What was the original ORTSDriveWheelWeight() statement in your ENG file?

[edwardk]

steamer_ctn, on 26 October 2016 - 08:55 PM, said:

I am sorry, but I don't quite understand the bug.

As suggested the OR code reads the value ORTSDriveWheelWeight() from the ENG file as a Mass quantity. The STFReader reads the value and then converts the value entered into kg to be used internally within OR.

The STFReader will accept any of the following units of measure (UoM): kg, lb, t (tonne), tons (uk) or tons (us). If no UoM are included in the parameter, then the STFReader assumes that the value is already in kg, and uses the figure directly as entered.

The UoM must be specified for correct conversion by OR, eg ORTSDriveWheelWeight( 104.0t-uk ).

What was the original ORTSDriveWheelWeight() statement in your ENG file?

Peter,

When I experienced the above issue, I was not using ORTSDriveWheelWeight()(at first). This means the initial metric ton value in Mass() value was used. I was experiencing spinning axles on a 1.3% grade using the initial Mass() value or in this case MassKG in the code. It was not until I converted the metric ton value to lbs and used it in ORTSDriveWheelWeight(), I was able to stop the severe wheelslip issue. I actually noticed this on another locomotive I was testing for someone here and advanced adhesion was selected with no snow.

Edit: It was one of the previous posts that mentioned to try converting the metric ton value to lbs.

[steamer_ctn]

edwardk, on 27 October 2016 - 01:10 PM, said:

This means the initial metric ton value in Mass() value was used.

Does this mean that the Mass() statement in the ENG file was not reading the correct locomotive weight?

What was the Mass() statement in the ENG file?

[ATW]

I myself never saw any big difference with using the tons or mass an used LBS instead an saw big differences an slippage reduced making AC motors come to life as well as DC motors along with my custom Tractive Effort curves.

Using:
Antislip (1) & ORTSWheelSlipCausesThrottleDown together I also see modern computerized slippage control systems a help to reduce severe slipping to a lower throttle setting.

[edwardk]

steamer_ctn, on 27 October 2016 - 03:25 PM, said:

Does this mean that the Mass() statement in the ENG file was not reading the correct locomotive weight?

What was the Mass() statement in the ENG file?

In the ES44DC, the Mass is 186.8t. Can your advanced adhesion process use metric ton? All I know is that I converted the metric ton to lbs before using it in ORTSDriveWheelWeight(411894). What you see is the initial metric ton value converted to lbs. Once read in, its converted to kilograms.

Edward K.

[steamer_ctn]

edwardk, on 27 October 2016 - 05:22 PM, said:

Can your advanced adhesion process use metric ton?

It will use any valid mass units (internally within OR it will use kg).

edwardk, on 27 October 2016 - 05:22 PM, said:

In the ES44DC, the Mass is 186.8t.

Because the units "t" is included in the parameter, the 186tonnes will be converted to kg for OR use.

edwardk, on 27 October 2016 - 05:22 PM, said:

All I know is that I converted the metric ton to lbs before using it in ORTSDriveWheelWeight(411894). What you see is the initial metric ton value converted to lbs. Once read in, its converted to kilograms.

As there is no UoM indicated in this parameter, it will be read in directly as kg (assuming that this is the way that the parameter statement appears in the ENG file). Thus if this value is the locomotive weight in pounds, then the weight has effectively been increased by 2.2 times to 411894 kg. Naturally doubling the adhesive weight of the locomotive will significantly improve the slip capability of the locomotive (but may impact the realism).

The parameter needs the units to be specified, ie ORTSDriveWheelWeight(411894.0lb)

[edwardk]

ORTSDriveWheelWeight(411894.0lb)? What I initially used here is almost correct then? What about the extreme wheel slipping when on a 1.3%+ grade when this parameter is not used? The initial Mass() is used. I realize there is wheel slippage, but what I experienced would not be considered normal. Is it possible the adhesion value you are using is too low? I believe you using 0.4f for snow. 0.8f is being used for simple adhesion.

If you have one of SLI's Scenic Sub routes, try running it in the middle. At this moment, I am unable to come with an area for you to test.

Edward K.

[copperpen]

This is what the au_ctn test route is for. It gives a common ground that everyone can use to test and verify results. It can be found at Peter's site, coalstonewcastle. Just click the link in his post and search for the route.

[steamer_ctn]

edwardk, on 28 October 2016 - 02:55 AM, said:

ORTSDriveWheelWeight(411894.0lb)? What I initially used here is almost correct then?

If the ORTSDriveWheelWeight is missing from the ENG file then the full weight of the locomotive will be used as the adhesive weight. In some instances, say for locomotives with non-driven wheels, the adhesive weight will actually be less then the full weight of the locomotive. Thus it will provide a "best case" slip performance.

edwardk, on 28 October 2016 - 02:55 AM, said:

What about the extreme wheel slipping when on a 1.3%+ grade when this parameter is not used? The initial Mass() is used. I realize there is wheel slippage, but what I experienced would not be considered normal. Is it possible the adhesion value you are using is too low? I believe you using 0.4f for snow. 0.8f is being used for simple adhesion.

What is normal?

The only information provided so far is a grade and the fact that it is a diesel locomotive hauling the load (ES44DC).

What is the load that is being hauled? Often the load needed to be derated for train operation in ice and snow conditions. What is the expected load that the ES44DC can haul up a 1.3% grade? Is this for dry or icy conditions? Has this information come from a working timetable or railway operational manual?

edwardk, on 28 October 2016 - 02:55 AM, said:

If you have one of SLI's Scenic Sub routes, try running it in the middle. At this moment, I am unable to come with an area for you to test.

As suggested by Copperpen I prefer to utilise the test route on the Coals to Newcastle site as this has a number of consistent gradients of sufficient length to give a good indication of the performance. It is also freely available for all users, and this thus eliminates any issues with users obtaining a copy, which can be an issue if the stock and route is payware, or difficult to obtain.

My other preference is to ensure that all the rolling stock has been "optimised" for operation in OR to ensure consistent performance. I have used this approach for testing some of the recent changes that I did to the adhesion model. See this page for info demonstrating this approach, and the "standard" model that I used. I have set the rolling stock up to provide a consistent performance in OR.

If you wish to explore this further, please set up a test scenario that we can all use to confirm the agreed expected performance.