search

k4kfh / ZephyrCab

Drive a model train with prototypical controls, realistic behavior, and simulated physics; uses JMRI's WebSockets interface for layout connection
http://k4kfh.github.io/ZephyrCab
GNU Affero General Public License v3.0
10 stars 4 forks source link

No defined limit to speed #2

Closed k4kfh closed 8 years ago

k4kfh commented 8 years ago

A locomotive cannot keep accelerating forever regardless of how much power it has. The traction motors will only spin so fast with a certain voltage, so at some point there is a defined limit to speed. For an EMD F7 I believe this to be around 60mph in notch 8, so I can assume that it is linear (meaning 7.5mph per notch). This is simple in logical principle, but will require careful implementation for efficient operation in software. In the UDT project, constraint() was used, but JavaScript doesn't natively have that, so a solution will need to be cobbled together.

k4kfh commented 8 years ago

The primary problem with this arises in implementation. Adding a constraint to the final speed would skew the number if and only if there was an outside force (namely grade) "helping" motive force out. Downhill is the only instance I can think of in which the motors would rightfully spin faster than they can turn themselves. This seems like a small issue, however a runaway train due to improper braking is an important part of the simulation and I think it needs to be addressed.

k4kfh commented 8 years ago

I believe the best way to handle this is to create a system to set tractive effort to zero (quietly, without notifying the user) once the speed passes the limit. One of two things would consistently happen:

Not going downhill:

  1. Train accelerates to top speed
  2. Train exceeds top speed ever so slightly
  3. Locomotive's tractive effort drops to zero
  4. Train decelerates
  5. Repeat.

Going downhill:

  1. Train accelerates to top speed
  2. Train exceeds top speed
  3. Locomotive's TE drops to zero
  4. Force of the downhill grade continues acceleration, slower due to the lack of locomotive tractive effort to help out

This seems the best, most realistic way to handle the issue. It also solves the problem of differing max speeds in an MU consist. If one locomotive has a higher max speed than another, the inferior locomotive simply becomes useless above its maximum speed.