Sensors and blocks

Content → Automatic Mode

• Sensors and blocks

Sensors are a core component of every computer controlled model railway. By the sensors the positions of the trains on the layout are announced to the software. Sensors can either provide an impulse (e.g., switch rails, Reed contacts, hall sensors) or a permanent signal (e.g., contact rails, other occupancy detectors like current detectors etc.). An overview of the hardware and an introduction to the use of sensors is provided on the page Sensors.

In Rocrail sensors are defined as objects. The page Objects: Sensors and its sub pages inform about the setup of sensors.

> Note: To the avoidance of misunderstandings it should be noted that with the word "Sensor" physical (real, hardware-) sensors, as well as the corresponding software objects and events are called.

Rocrail needs two sensor events for every block which define when a train is entering the block and when it has (almost)¹⁾ reached the end of the block. These sensors are called as enter and in. When required additional sensors like pre2in, shortin etc. can be added.

The definition of the sensors occurs in the route properties of a block and depends on from which block the train comes. For all possible routes sensors have to be defined. Hence, before the definition of sensors in the block properties all routes must have been set up before.

All event types may provide extra bi-directional (ident) information.

Timer controlled events has Limited support; Long timers can severely disturb automatic control if overlapping subsequent events.
Using timed events are discouraged!
No forum support for event timers longer than 100ms.

As explained below in more detail the following general order of events takes place: enter→ (shortin) → (pre2in) → in. Events in brackets are optional.

For the opposite direction of the traffic the allocation is to be repeated from opposite view. Typically a sensor triggers different events depending on the direction of the traffic.

For a correct functioning of the automatic mode at least the events enter and in have to be triggered in each block.

Note: Rev. 14.971+ automatically generates a missed In event with the Enter event in the To block.

In the following the different sensors are looked closer at. Besides, it is assumed that a train must stop in the respective block, e.g. because the waiting settings of the block are set accordingly, or because the following block is occupied. To the meaning of V_min and V_mid see Locomotives: Interface

• Since introduction of the Block Braking Timer (BBT) the two sensors setup with enter and in is the recommended standard. With BBT more than these two sensors are only needed if multiple stopping points are desired in the block. For the breaking behaviour of BBT see description there. The following statements refer to driving without BBT.

Tip: Whether or not using BBT can be defined for each block individually. This decision has not to be made for the whole layout.

• With two sensors - enter and in - the train drives with V_mid⁴⁾ from enter on and decelerates to a halt at in. If the combination of brake behaviour and V_mid is set equally for all locomotives (either all locomotives at the same speed with V_mid and the same brake behaviour or V_mid differently, however, with the quicker locomotives also set to a more sharp braking), a stopping accuracy in the range of a few centimetres is achieved easily.

• With three sensors, enter, pre2in and in, the train decelerates to V_mid⁵⁾ at enter and to V_min at pre2in.
  If one sets V_min quite low (practical value: 10 kph), then the brake setting of the locomotive does have a limited influence only. All locomotives will stop quickly after arriving at in. This leads to the very exact stopping point. The divergence lies within clearly less than 1 cm!.
  In addition, the pre2in can be in a way abused to allow shorter trains an earlier stopping point: To achieve this the respective locomotives are set to "stop at pre2in" in the locomotives properties. Now for these locomotives the pre2in has the function of the in-sensor. Accordingly these locomotives decelerate to V_mid⁶⁾ at enter and stop at pre2in.

• Another combination of three sensors would be enter, shortin and in. This combination is similar to enter and in and, in addition, locomotives with the setting "use shortin event" use shortin as in-sensor. Other locomotives ignore shortin and use in.

• Finally, four sensors can also be combined: enter, shortin, pre2in and in. Then with this variation it is possible to

1. run long trains as far as in (with V_mid and V_min as described above)
2. stop short trains already at shortin (e.g., in front of the station building)
3. use pre2in for trains that would stop to early with shortin and to late with in

• If only one physical sensor is used - e.g., for cost reasons, or to hold the wiring expenditure low - this sensor is defined as enter2in. The physical sensor generates the enter-event and starts a timer which generates the in-event after its expiration. The train decelerates to V_mid⁷⁾ at enter and if the timer is elapsed (in-event) it decelerates to a halt.
  The timer (event timer) is found in the Routes Dialogue of the block properties and is valid for all routes of the block equally. Moreover, the timer can be set individually for each locomotive in the Locomotive Details.
  For standard section blocks with low demands for a precisely reproduceable stopping point this is one very well applicable configuration. Even a stopping exactness of few centimetres can be achieved by fine adjusting of the locomotive decoders, in particular the deceleration time (CV4). However, it must be made sure that the train comes to a halt position within the block borders. If a more exact stopping point is desired, however, an own sensor for the in-event should be used.

• Another possibility to use only one physical sensor is the enter2route-sensor⁸⁾. Nevertheless, this sensor is a special case which should be used for street vehicles in a car system only. A description of how the enter2route-sensor is set up can be found on the page of the Dinamo Car System.

• In blocks equipped with two sensors (enter and in) the pre2in event can be simulated using enter2pre instead of enter. The physical sensor generates the enter-event and starts a timer which generates the pre2in-event after its expiration. The train decelerates to V_mid⁹⁾ at enter and if the timer is elapsed (pre2in-event) it decelerates to V_min.
  The timer (event timer) is found in the Routes Dialogue of the block properties and is valid for all routes of the block equally. Moreover, the timer can be set individually for each locomotive in the Locomotive Details.

Note:
Since the event timers do not only affect enter2in and enter2pre but also in attention should be paid to the following:
If an enter2pre event is defined and this is, e. g., assigned to timer 1 the in event has to be assigned to the other timer (e. g. timer 2, usually with a short or no delay at all) to assure the in event is not delayed by the same time

• Similar to enter2pre the shortin event can also be simulated using enter2shortin if no physical sensor is available for shortin.

Whether occupancy sensors which can supervise a whole rail segment, or impulse sensors which deliver only one short impulse while crossing are to be used, depends on the respective intended purpose, the rail system and the costs: The occupied-sensor according to its function is only useful if designed as an occupancy sensor, however, an exit-sensor can be an impulse sensor without any difficulties. Recommendable for the dual rail DC-System, e.g., could be the following combination: An occupancy sensor to generate the enter-event, for all other events (shortin, pre2in, in) the cheaper impulse sensors will fulfil the requirements.

The following table summarises the speeds as a function of the sensor events. Subsequently the velocity sequence in an example of one block with three sensors is shown graphically.

Note: According BlockDialog Details, Speed other speed indications may be configured.

Rocrail does not send every speed step to the decoder and therefore the decoder has to be programmed to get a smooth acceleration and deceleration.

Since the implementation of the Block Brake Timer (BBT) for blocks with only 2 sensors (enter and in without pre2in), finely adjusted Braking and Acceleration processes will be achieved.
With the BBT an existing pre2in sensor is ignored. Its possible further use as shortin sensor is not affected.

Is in a block only one sensor realisable (e.g. the whole block is only one block occupancy section) nevertheless is it possible to get a satisfied stopping inside the block. Then the sensor should be configured as enter2in event and the in event will be generated from an event timer.
The CV configured brake delays or speedlines of all locos, that pass through the block, should not be too different. Otherwise is it possible, a loco achieved too early the Vmin speed and stops too far from the end of the block. For every train, that pass through the block, is neccessary that it is complete inside the block, if the timer controlled in event occurs.
* Caution: Heed warnings on timed events in the Event Table

In Rocrail sensor events are configured in the block route properties. For this purpose in the following order

1. blocks are created (7.1)
2. sensors are set up (7.2)
3. routes are generated (7.3) and
4. sensor events are configured (7.3.2).

In brackets are the relevant sections of the step-by-step tutorial given. In addition, the pages on sensors, routes and blocks should be regarded.

Using the same sensor in different blocks, for the same or different events, is strictly forbidden. This applies to all above mentioned events without exception. It is thus, as an example, not possible to use one enter sensor for two or more blocks.

• With the Block routes option Ignore events if not reserved a sensor can be used for multiple blocks if on Event trigger only one block is in the reserved state. (Yellow or blue.).

• Another not so easy option is to use actions and scripts: With the help of "virtual sensors" can be one physical enter sensor (e.g. in front of track harps in shadow stations) be used for several subsequent blocks. This will be realized with Actions (Demo 2) or Scripte (both in german), which are triggered by this one physical sensor and then turn on virtual Enter sensors (which assigned to the subsequent blocks).

If using specific routes for sensor events different sensors can be used to generate the same event (enter in the example) in the same block.

This is not an example for shared sensors; see above chapter!

Example Plan

The screenshot shows a small layout, it contains two routes from the main line block on the left to the main line block on the right, one route passes block local_1 and the other route passes block local_2. The two routes, although coming from the same start block, have different sensor entries for the enter event but use the same in sensor of main right.