Table des matières → Objets → Horaires

• Index | Destinations | Actions | Position et Horaires | Réseau test des horaires

Tout est une question de Planning et de Timing

Conçu par Rob et construit par Mark, ce plan de réseau apparemment simpliste contient plus d'un surprenant problème de complexité qui ne peuvent être résolu que par l'utilisation des horaires. Cet exemple est l'évolution des tous premiers essais de Mark avec son "Dueling Dampfloks" (du temps des messages dans le groupe Yahoo Rocrail).

dueling.xml

Chaque bloc est réglé avec le même temps d'attente de 1 minute.

Au départ il y avait sept routes qui définissaient les connections possibles entre les différents blocs. Voici la liste:

• r1 (A2-B)
• r2 (A2-C)
• r3 (B-A1)
• r4 (C-A1)
• r5 (A1-A2)
• r6 (D-A1)
• r7 (E-A1)

A noter que toutes ces routes sont configurées dans le sens des aiguilles d'une montre en partant du coin supérieur droit avec le bloc A2 ("à 1 heure"). Il en résultera que le sens général du réseau se fait dans le sens des aiguilles d'une montre et que cela signifiera que le mouvement "en avant à partir de chaque bloc vers un autre se fait dans le sens des aiguilles d'une montre". Par exemple, "en avant" de C doit être A1, et "en arrière" de C doit être A2.

Chaque route peut être empruntée dans les deux directions, ainsi que tous les embranchements qui ont été définis pour chaque sens. Par exemple, pour la route r4 (C-A1) l'aiguillage t1 est positionné sur droit.

Cependant, durant les tests, il est devenu évident que toutes les locos utilisées auraient à un moment donné à faire face à ce sens unique de roulement sur le réseau. Ceci signifie qu'une loco roulant à contre-sens des aiguilles d'une montre serait placé face à un mauvais chemin. Pour cette raison, trois routes ont été ajoutées pour permettre aux locos de faire face au sens de aiguilles d'une montre tout autour du réseau:

• C-A2
• A2-A1
• A1-C

Ces routes ont été configurées dans le sens inverse des aiguilles d'une montre en utilisant "De-A" avec un sens de roulement "en avant". C'est ce qui permet à une loco de rouler à contre-sens en faisant face au "mauvais" sens du réseau.

Il y a un seul groupe de blocs défini A1-A2, qui est marqué comme une Section critique. Cela signifie que si une loco réserve un des blocs du groupe, l'autre est automatiquement réservé.

Le but principal est de permettre aux trains de partager le réseau selon leurs différents parcours en même temps. Par exemple, un train de marchandises se déplaçant dans le sens des aiguilles d'une montre, alors qu'un train de voyageurs se déplace en sens inverse des aiguilles d'une montre…….to finish….. sharing the A1-A2 line in the north. Or a branch mining train that takes coal from the siding D to the town at B, and then goes back to D for more coal. Schedules will allow the operator to define the different paths trains must take, without having to worry about two trains blocking each other. Rocrail should handle all the little details of making sure one train can get past the other and both trains follow their respective paths.

Using just basic blocks and routes two locs can be made to randomly move "around each other" on the layout, but not move around with any real purpose. For this reason, Schedules are used to define a "list of blocks" to be followed, and to allow more meaningful, enjoyable operations. Rocrail then uses the Routes to determine how to get from each block in the list to the next block.

When 2 locs both want to move into each others block, they will "deadlock" and not be able to move. In the simplest case, a 2 block layout A-B contains a loc in A that wants to move to B, and a loc in B that wants to move to A. Neither can move until the other loc gets out of its block, which the other loc cannot do until the first loc moves out of its block.

Rocrail must be able to resolve these conflicts, or fail with a message that says "This deadlock cannot be resolved." Note that you must design your layout to avoid deadlocks where possible, and make sure there is a solution available. Rocrail cannot make the "A-B" example above work, there is no solution. However, with a properly planned layout, Rocrail should be able to control all movements, halting one train temporarily while another one proceeds, and then moving the first train once the way is clear.

Critical Sections are groups of blocks that can only have one locomotive in them at a time. If a loc reserves one of the blocks in the critical section, all the other blocks are reserved for that loc at the same time. The top side of the Schedules Test Case layout is divided into two blocks to test this principle. A1 and A2 are linked so that if one loc reserves either block, it reserves both.

Work started on Schedule testing back in late spring of 2007, but with the onset of Summer, testing stopped for a while. It was renewed in the fall of 2007, with good results.

The first case was to test a single loc running a basic schedule, then test two locs running two schedules at the same time. For this reason, the first two schedules used were:

• C-A1-A2-C (clockwise, repeating)
• B-A2-A1-B (counter-clockwise, repeating)

Note that these schedules were made to repeat by setting the Schedules drop-down in the Action tab to the same schedule. For example, schedule C-A1-A2-C had Actions > Schedules set to C-A1-A2-C.

Initially, a single loc running either of these schedules worked perfectly. However, running two locs at the same time would always deadlock in the A1-A2 part of the layout. This was fixed as of svn 1931. After the fix, one loc would run the first schedule while the other waits, then the second loc would run its schedule while the first waited.

Also, the locs used for initial testing were electric locomotives, so even though they were moving correctly it was not obvious that they were moving backwards when running counter-clockwise

The next set of schedules tested Rocrail's ability to handle changing directions and non-circular schedules.

• C-A2-A1-C (clockwise, repeating)
• D-A1-E-A1-D (both directions, repeating)

As of svn 1942, this worked perfectly. When the loc running the second schedule would enter A1, the other loc would halt in A2 and wait until the first loc was back in a siding. Then the waiting loc would continue past A1, and stop in C. The loc in the siding would move back out into A1, and the cycle would repeat.

This is an example of a Yard Switcher working while Main Line trains keep moving through the yard's entrance.

Rocrail could already be used to clean the layout randomly by simply attaching a cleaning car to a loc and starting it under Automatic mode. But because of all the stopping and starting involved, it was not very efficient, the cleaning car should be run at constant speed when possible. This schedule was designed to clean the layout more efficiently:

• C-A1-A2-B-A1-A2-C-A1-D-A1-E-A1-D-A1-A2-C (clockwise, then both directions, repeating)

This was used as of svn 1946 to clean the layout, and also functioned perfectly.

The direction issue and locomotive placement became a problem when we tried to run the Dueling Dampfloks scenario originally envisioned back in the Spring. This quickly pointed out the following important points about Routes, Direction and Locomotive Placing:

1. From To and Both Directions control whether a loc is allowed to move one way only along the route, regardless of facing. For example, if a Route A-B is From To, a loc can only move from A to B.
2. Run Direction controls if Rocrail sends forward commands to the loc when using the route. For example, if a Route A-B has Run Direction set to Reverse, and a loc has Placing set to default, Rocrail will send backwards commands to the decoder when moving the loc from A to B.
3. Placing also controls if Rocrail sends forward commands to the loc to move forwards along the route. For example, if a loc in A on Route A-B with a Run Direction of Forwards has Placing unchecked, Rocrail sends backwards commands to the decoder to make it move to B.
4. Run Direction and Placing are combined when Rocrail determines how to move a loc. For example, if a Route A-B has Run Direction set to Reverse, and a loc has Placing unchecked, Rocrail sends forward commands to the decoder when moving from the loc from A to B.

Once Mark fully understood this, he got Dueling Dampfloks to run very well using these schedules:

• C-A2-A1-C (counter-clockwise, repeating, used by the BR 38)
• B-A1-D-A1-A2-B (both directions, then runs next schedule, used by the BR 74)
• B-A1-E-A1-A2-B (both directions, then runs previous schedule, used by the BR 74)

You can see a short low-resolution video of the Dueling Dampfloks layout in action on You Tube: Dueling Dampfloks Video

Schedules are still evolving in Rocrail, and there are many unused fields in the dialog boxes that illustrate ideas that have not been implemented yet. Some of the ideas that still need to be developed are:

Block Timing This will allow trains to know that they are early, late or on time. Rocrail can then speed up, slow down, or even make a train wait as needed.

Each block already has a time associated with it in a Schedule. If the first block in the schedule is set for 0:00. and the next is set to 1:00, Rocrail should know if the train made it into the block at 0:30 (early), or 1:07 (late) and make a decision based on Time. Rocrail should hold a train in a block if it is early, and perhaps speed the train up if it is late. This is more complex than it seems.

Timetables and Clock Usage This will allow schedules to be repeated only at specific times. Instead of having a schedule run, stop and then just run again, Rocrail should be able to run a schedule at 9:57, then 12:15, then 13:45. This is more complex than it seems, and brings up the idea of "Time" on the layout.

Schedule Groups In the same way that we can link a set of routes into a schedule, we should be able to link a group of schedules into a Run. Note that we need a better word for this concept, but the idea is that the loc first runs the Amsterdam to Paris schedule, then the Paris to Munich schedule, then the Munich to Amsterdam schedule.

Train Priority Fast trains should reserve blocks instead of slow trains where possible. However, a slow train must not be stopped indefinitely because there are too many fast trains using the track it needs. This is very complex, and implies aging, i.e. when a train is only a little bit late, you can stop it, but if it is very late, it must run with higher priority so it will not be "deadlocked" by faster trains that reserve the blocks it needs.

Passing Tracks Situations where a slow train is in front of a fast train should be handled as well, with the slow train "pulling to the side" at the next passing siding and allowing the fast train to get in front. This would mean setting up a single schedule with two or more lists of routes, or allowing you to specify two blocks for a single destination in a schedule. For example consider these two schedules:

• A1-B-A2-A1
• A1-C (wait)-A2-A1

We would always use the first schedule if no other train was on the layout. But if a train with higher priority was following this train, this train would use the second schedule and wait in C while the other train moves ahead of it.

Function Triggering When a loc completes a schedule, a specific function is activated. This might let a loc play a sound when it reaches its destination, or uncouple from its wagons. Using the Yard Schedule mentioned above, this might let one loc run 2 trains, by moving into a siding and coupling automatically, running a train out on the layout, moving back into the same siding, and then uncoupling using a Telex magnet.

This is one of the goals of the original Dueling Dampfloks layout, the idea of a switcher running two sets of wagons from each of the sidings while a main passenger train runs the layout.

This is already implemented, but it should be fully tested.

Output Triggering This will allow other actions to be taken when a schedule is completed, such as turning on or off lights, putting power on the rails in an isolated section, or any other kind of electrical action that can be controlled by an addressable decoder.

The following tables show the details for all the elements in the layout.

Action to submit after reaching the last destination.