Elvas Tower: Start Friction Value - Elvas Tower

Jump to content

Page 1 of 1
  • You cannot start a new topic
  • You cannot reply to this topic

Start Friction Value Rate Topic: -----

#1 User is offline   MatarazzoT 

  • Apprentice
  • Group: Status: Switchman
  • Posts: 10
  • Joined: 20-February 20
  • Gender:Male
  • Location:Rio de Janeiro, Brazil.
  • Simulator:Openrails
  • Country:

Posted 28 April 2020 - 07:25 AM

Hello,

I' ve already downloaded Community VS2019 and Master Branch of Openrails, but i can't find the command line where i can change the starting resistance friction on Locomotives/Wagons. Anyone familiar with the code willing to help out?

The values are incorrect just for starting resistance as far as i'm concerned, Low/Roller/Friction starting coefficient needed to be adjusted.

Davis A (Value in lbf or N when train reaches 5mph) Works fine
Davis B (Value in lbf/mph or N/m/s Roller coefficient) Works fine. (xx lbf (Low needs more research)) ((16~18lbf (20lbf AAR) Roller)) (29lbf Friction)
Davis C (I didn't tested yet)





#2 User is offline   MatarazzoT 

  • Apprentice
  • Group: Status: Switchman
  • Posts: 10
  • Joined: 20-February 20
  • Gender:Male
  • Location:Rio de Janeiro, Brazil.
  • Simulator:Openrails
  • Country:

Posted 29 April 2020 - 09:01 AM

View PostNickonWheels, on 28 April 2020 - 11:13 PM, said:

Hi

Indeed starting friction is clearly one of the most annoying things in ORTS. When using Davis friction there are only these three lines plus three options for bearing type. ORTS determines starting friction based upon bearing type and vehicle weight though it is not just a multiplying number but exponential. I know this is far from agreeable (and there is also the rigid 5 mph merge speed), the only really useful way is of course inserting those numbers like starting resistance as a numerical value. In this regard ORTS friction settings look like unfinished work.

I even tried and finished a code addition to solve this problem (read this) but those in charge of ORTS don´t bother with it because reasons I can´t get behind of. Quite sadly such improvements are unwanted but seemingly we can agree on the starting friction is horrible with the current model.


Hello Nick!

I appreciate your reply, and yes, it is wrong/annoying for sure, i'll take a look on your code, test and get you some feedback, thanks for sharing! We run some heavy trains here in Brazil and i get the feedback from the Engineers relating the same thing about the resistance. The train we start here with N2/N3, we can't move with roller bearings. We use pads near the suspension and Swing Motion Bogies, those parameters need to be set to, as reduce drastically the resistance at start, as in curves and movement.

We can define some commands to be implemented if staff permits, I'm open to discuss, I'll elaborate a bit of them and post here, as i've 0 experience in VS2019 code.

Cheers,
Thiago.



#3 User is offline   wacampbell 

  • Member since Nov. 2003
  • Group: Fan: Traction Nuts
  • Posts: 2,345
  • Joined: 22-November 03
  • Gender:Male
  • Location:British Columbia, Canada
  • Country:

Posted 29 April 2020 - 09:16 AM

On north american trains ( and others I am sure ), coupler slack is the key factor on starting trains. Static friction of the wheel bearing is negligible since only one car starts rolling at a time. There's no point in fine tuning starting resistance until coupler slack effects are in place.

#4 User is offline   cjakeman 

  • Vice President
  • PipPipPipPipPipPipPipPip
  • Group: ET Admin
  • Posts: 2,866
  • Joined: 03-May 11
  • Gender:Male
  • Location:Peterborough, UK
  • Simulator:Open Rails
  • Country:

Posted 29 April 2020 - 10:30 AM

View Postwacampbell, on 29 April 2020 - 09:16 AM, said:

On north american trains ( and others I am sure ), coupler slack is the key factor on starting trains. Static friction of the wheel bearing is negligible since only one car starts rolling at a time. There's no point in fine tuning starting resistance until coupler slack effects are in place.

Agreed.

Fortunately, Steamer_ctn is working on this precise issue.

#5 User is offline   MatarazzoT 

  • Apprentice
  • Group: Status: Switchman
  • Posts: 10
  • Joined: 20-February 20
  • Gender:Male
  • Location:Rio de Janeiro, Brazil.
  • Simulator:Openrails
  • Country:

Posted 29 April 2020 - 03:20 PM

View Postwacampbell, on 29 April 2020 - 09:16 AM, said:

On north american trains ( and others I am sure ), coupler slack is the key factor on starting trains. Static friction of the wheel bearing is negligible since only one car starts rolling at a time. There's no point in fine tuning starting resistance until coupler slack effects are in place.


Most of them yes, but here for example we got twin wagons connected by a rigid connection, x68 150t Railcars, making x136 150t iron ore cars loaded 20400 metric tons with 2 engines, sometimes 1 engine working, it makes difference. But this is a Heavy Haul operation, just one of them, coupler sure is a big factor too, but resistance on railcars are more than that.

Cheers,
Thiago

#6 User is offline   steamer_ctn 

  • Open Rails Developer
  • Group: Status: Elite Member
  • Posts: 1,888
  • Joined: 24-June 11
  • Gender:Male
  • Country:

Posted 29 April 2020 - 09:13 PM

View PostMatarazzoT, on 29 April 2020 - 03:20 PM, said:

Most of them yes, but here for example we got twin wagons connected by a rigid connection, x68 150t Railcars, making x136 150t iron ore cars loaded 20400 metric tons with 2 engines, sometimes 1 engine working, it makes difference. But this is a Heavy Haul operation, just one of them, coupler sure is a big factor too, but resistance on railcars are more than that.

Given the fact that the rigid connection is between each pair of twin cars, one could assume that some coupler slack is still present between each pair of cars, and hence advantage can be taken of it in starting the train.

Starting resistance is not a well documented area of railway operation, and hence putting huge amount of effort into trying to find, or make up some values for it seems like a lot of effort, potentially without a great deal of return.

So in order to determine whether it is worth the time and effort to make adjustments, etc, a test scenario should be designed using real world data and see whether OR performs the same as the real world situation. If it doesn't, then this will support the case for changes to OR to be considered.

I will be able to take some of these test results into the work that I am doing on Advanced couplers.

Page 1 of 1
  • You cannot start a new topic
  • You cannot reply to this topic

1 User(s) are reading this topic
0 members, 1 guests, 0 anonymous users