Rail3D*


 
System.ArgumentOutOfRangeException: Length cannot be less than zero. Parameter name: length at System.String.Substring(Int32 startIndex, Int32 length) at R3DWeb.sParseContent(String sPageID, String sText) at cms.Page_Load(Object sender, EventArgs e)

Using Timetables With Diagrams


« | [[wiki/Main/Tutorials]] | »


In the previous part of this tutorial ([[wiki/Tutorials/MoreComplicatedTimetables]]), we saw how to coordinate timetables for multiple routes, and tried one way of dealing with services that only operate for part of the day.

If you compare our setup with a real railway, one obvious thing that is missing is a depot of some kind. Our trains spend the night in station platforms or reversing sidings, whereas in real life they would be sent off to a place where they could be serviced and made ready for the next day. In this tutorial, we’ll be looking at how to set up a simple depot, and how to program trains to go in and out of service at the right times, using the Rail3D Diagram feature.

1 Building a depot

It turns out that there’s a convenient piece of land for building our depot adjacent to the main line between India House and St Juliet stations.

At the moment, we only need five trains to operate a full timetable, but we may well expand our services in future, so we should leave ourselves plenty of space. To start with, I’ve built a depot with six storage roads, long enough for eight cars (two four-car sets) each, as well as two reception roads. Trains to the depot leave the main line at India House (there’s a flat junction for the moment, but space for a flyover if we need it later) and run via a short branch to one of the reception roads, then via the headshunt to a storage siding.

At India House, I’ve added a second Up platform and a crossover, so that trains between Limathorpe and the Depot can reverse in the centre road and don’t have to go to Alfaton and back. The second platform will also reduce the risk of holding up inbound route L trains when other trains are leaving the Depot.

To keep things straightforward, I’ve given each storage track its own “address” — trains on route D1 go to track 1, route D2 to track 2, etc. This makes it a bit easier to arrange times of entering and leaving service. Each track has a stop at the end of it labelled “Depot”, which can be used as a timing point.

2 Diagramming trains

2.1 The objective

What we want to do is send trains to the depot when they get to the end of their timetable for the day.

To get a quick overview of the timetables we have at the moment, we can use the Export Timetable command to dump all the layout’s timetables to a text file. The result looks like this:

###################################

L
Alfaton [06~23]:05 [06~23]:25 [06~23]:45 00:05 
Limathorpe [06~23]:11 [06~23]:31 [06~23]:51 00:11


###################################

H
Alfaton [06~23]:00 [06~23]:20 [06~23]:40 00:00 
Hauttel [06~23]:02 [06~23]:22 [06~23]:42 00:02

###################################


E
Alfaton [06~10]:10 [06~09]:30 [06~09]:50 [16~19]:10 [16~19]:30 [15~18]:50
Echo Reverse [06~09]:19 [06~09]:39 [05~09]:59 [16~19]:19 [16~18]:39 [15~18]:59

###################################

Complications

There are a number of things to be careful of with diagrams, which can give unexpected results if you’re not aware of them.

  • the diagram applies to the leading vehicle, rather than the train, unless it is a multiple-unit set defined in a single model file — for trains made up of separate models, if the train reverses direction, a different diagram is operating
  • the diagram is checked whenever the train arrives at a stop or reverse that applies to the current route
  • the train steps through the sequence one line at a time, so if one change is missed somehow, you will never get back into sequence
  • a timed change will only be applied if the value of the current sim time is greater than the time in the list. Thus a change set for 23:55 won’t apply if the train reaches a stop just after midnight (00:01 < 23:55)

Simplifications

Since things get messy if we have timings just after midnight. To avoid that extra complication, we’ll assume for the moment that our trains are at risk of turning into pumpkins, and get them all back into the depot by midnight.

To avoid having to diagram both ends of each train separately, we will arrange that all diagrammed changes take place when trains are travelling in the Up direction. The depot is already set up with this in mind: we just have to arrange that all trains will enter and leave service at Alfaton. To simplify things a bit further, I put in a stop labelled BookingOn on the depot exit track. This will force the diagrams to update before the trains decide which way to go at India House.

A possible strategy

Route L: One train enters service at Alfaton at 06:05, the other at 06:25. We want the last trips from Limathorpe to be the 23:11 and 23:31, arriving at Alfaton at 23:23 and 23:43. Assuming the trains stick to the timetable, the train that formed the 06:05 from Alfaton will form the 23:23 arrival (it takes 40 minutes for a round trip, so the cycle repeats every two hours).

Route H: One train enters service at Alfaton at 06:00, the other at 06:20. The last trips from Hauttel depart at 23:02 and 23:22, arriving 23:18 and 23:38. Assuming the trains stick to the timetable, the 06:00 from Alfaton will form the 23:18 arrival.

Route E: One train enters service at Alfaton at 06:10. The last trip from Echo Reverse arrives at Alfaton at 19:28.

Empty stock movements from the Depot to Alfaton take about 6 minutes. Because we will really mess things up if a train is late entering service, it’s probably wise to add an extra five minutes to this, and have trains leave the depot 11 minutes before they are due to enter service.

This gives us the following:

Train Route Leave depot Entry point Time Exit point Time
1 H 05:49 Alfaton 06:00 Alfaton 23:18
2 L 05:54 Alfaton 06:05 Alfaton 23:23
3 E 05:59 Alfaton 06:10 Alfaton 19:28
4 H 06:09 Alfaton 06:20 Alfaton 23:38
5 L 06:14 Alfaton 06:25 Alfaton 23:43

2.2 Implementing this in Rail3D

To do this, we can use the Diagram function (see [[wiki/Reference/EditDiagram]]) to step each train through a series of different route names during the course of the day.

Preparations

The route Dn (i.e D1, D2, etc.) is used to direct the train as empty stock to its assigned depot track, and hold it there until morning. These routes thus have timetables with only one departure time each.

###################################

D1
Depot 05:49

###################################

D2
Depot 05:54

###################################

D3
Depot 05:59

###################################

D4
Depot 06:09

###################################

D5
Depot 06:14

###################################

We can edit the timetable dump file we created to include these, then import it back into Rail3D (Import Timetable).

nb: be careful to keep the same format (number of “#” characters and empty lines) as in the exported dump file, otherwise Rail3D won’t recognise all your timetables!

Setting up the diagrams

We need to select each train in turn, and enter the sequence of routes it has to follow during the day using the Edit Diagram command. Make sure the train is travelling in the Up direction (towards Alfaton), otherwise you will perhaps find yourself editing the diagram for the wrong end. It’s a good idea to pause the simulation to avoid the danger that the train reverses while you’re working on the diagram.

For each train, we want a sequence something like this:

  • Stabled in depot as route Dn (D1, D2, etc.) until scheduled departure time
  • Empty stock to the terminus where it enters service
  • Reverse and change route to service route; run as this route to the end of the day
  • On completing last journey, change route to Dn and return to depot

We’ll use route name A for the empty stock working from the depot to Alfaton. The route change to A is set for the “Booking on” point where trains leave the depot. The route change to the depot route is set a couple of minutes before the scheduled arrival at Alfaton — otherwise, there is the risk that the change doesn’t happen if the train arrives a minute early.

So, putting this into the form of a Rail3D diagram, i.e. a list of or events, we get something like this:

Train 1
BookingOn  A
Alfaton H
23:16  D1
Train 2
BookingOn  A
Alfaton L
23:21  D2
Train 3
BookingOn  A
Alfaton E
19:26  D3
Train 4
BookingOn  A
Alfaton H
23:36  D4
Train 5
BookingOn  A
Alfaton L
23:41  D5

When you have entered the diagram, don’t close the dialogue immediately, but click a few times on the Next button to cycle through the changes until the next change that is due to happen is shown correctly. If you forget to do this, the diagram will not be saved, and the train will be out of sync, and you will get odd results.


The next change is to route A at Location BookingOn

2.3 Testing

Testing gets a bit tedious. You can run the simulation at 5x speed, and you can change the time using the Set Time command, but you have to be careful about changing the time when a train is waiting for a scheduled departure (if the train is due to depart at 10:20 and you set the clock to 12:20, the train will wait for the next time 10:20 comes around, unless you start it manually with the “Green flag” button.

With a bit of trial and error, you should be able to get the layout into a state where all the trains put themselves neatly to bed at the end of the timetable.

3 A different approach

As you’ll have seen, diagrams are not for the faint-hearted. They can add an important extra touch of realism to operations, but to be effective and reliable, they have to be used as part of a carefully planned working timetable. If you are more of a “throw a few trains on the layout and see what happens” sort of modeller, you’re unlikely to get much benefit from diagrams.

One way that diagrams can be used very effectively is if you are following a real, prototypical working timetable. In this case, rather than using generic route names and a timetable of the sort we’ve been using here, with multiple departures from each timing point, you’ll probably use the train’s reporting number (headcode) as the route name, and have a separate timetable for each headcode.

If you did this on our layout, it might look a bit like this:

Train no. - 2H00 2E00 2H02 2E02 2H04 2E04
Alfaton d - 06:00 06:10 06:20 06:30 06:40 06:50
Echo Road - 06:08 06:18 06:28 06:38 06:48 06:58
Hauttel a - 06:16 - 06:36 - 06:56 -
Train no. 2E01 2H01 2E03 2H03 2E05 2H05 2E07
Hauttel d - 06:22 - 06:42 - 07:02 -
Echo Road 06:20 06:30 06:40 06:50 07:00 07:10 07:20
Alfaton a 06:28 06:38 06:48 06:58 07:08 07:18 07:28

(etc., for the rest of the day…)

The timetables would look like this:

###################################

2H00
Alfaton 06:00 
Echo Road 06:08

###################################

2H01
Hauttel 06:22 
Echo Road 06:30

###################################
2H02
Alfaton 06:20 
Echo Road 06:28

###################################

2H03
Hauttel 06:42 
Echo Road 06:50

###################################

…and so on for the rest of the day

The unit that forms the 2H00 working would have a diagram that looked something like this, if 5H00 is an empty stock working:

BookingOn  5H00
Alfaton    2H00
Hauttel    2H01
Alfaton    2H04
Hauttel    2H05
Alfaton    2H08

…and so on for the rest of the day

This is much more flexible, and more like the way real railways work but, as you can see, it involves a lot more “paperwork” than the approach we’ve been using. You wouldn’t be likely to go to all that trouble for a simple layout like this one where everything just repeats, but for a more complicated set-up it could be very useful.

4 Download

You can find the completed layout for this part of the tutorial at: http://www.markhodson.nl/rail3d/2kdlayouts/ops_layout_04.trp


« | [[wiki/Main/Tutorials]] | »


import