Innovative Model Railroad Control System

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
======Sensors and blocks======
[[:english#automatic mode|{{  :automat.png}}]][[:english|{{  :rocrail-logo-35.png}}]]
[[english|Content]] -> [[english#automatic mode|Automatic Mode]] 
  *  **Sensors and blocks ** 
   

// \\ // \\


===== Overview =====

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|Sensors]]**.

In Rocrail sensors are defined as objects. The page **[[:sensor-en|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)((in breaking distance to the stopping point)) 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 **[[block-routes-en|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. \\

 \\ 

===== Sensor Events =====
All event types may provide extra bi-directional (ident) information.\\

 \\
==== Standard ====

^  **Standard events**  ^^
^ enter | The train enters the block. Velocity is set to **V_mid**((or the velocity specified for **[[:block-details-en#stop|Stop]]**)), in case no free destination is found or in case the train should wait. |
^ in | If the train has to stop the velocity is set to zero. __This event also frees up the previous block locked by this train.__ |
 \\

 \\
==== Additional ====

^  **Additional, optional events**  ^^
^ shortin | In combination with the loco property "Use shortin event" this will be used as **in**. Suitable for short trains which should, e.g., stop in front of a station building. |
^ pre2in | Reduce the train velocity to **V_min** in case no free destination is found or in case the train should wait. \\ In combination with loco property "Stop at pre2in" this will be used as **in**; can be used instead of or in addition to **shortin** |
 \\

 \\
==== Special purposes ====

^  **Events for special purposes**  ^^
^ occupied | No action is taken as long as it is not unexpected. The status will be evaluated if a reserve request is put by a train to make sure the whole block is electrically free. |
^ ident | Some sensor systems provide more information like the address of the passing locomotive. (Lissy, BarJut, RailCom, ...) This information is compared in auto mode to the identity-code set in the Loco properties, in manual mode this identity-code is shown in the block symbol.\\ Use this event type only if the sensor has no further functionality. | \\ 
^ exit | The train exits the block. This event is used for extra safety and detects if a train does not stop with in the distance between **in** and **exit**. When this happens the train is stopped immediately and put back in manual mode. An exception message is generated. To use the **exit** event after the **in** event, the **exit** event must be set to the general route "all enter +/-" because after the **in** event the "from block" is set to the current block.\\ __The use of this event is discouraged: Use BBT instead.__ |
^ free | Free previous block and route before IN. \\ If the [[:block-routes-en#end_pulse_endpulse|End pulse]] option is set the ENTER event must be before the FREE event.  |
^ enter2free | A combination of enter and free. |
^ [[:automobile-blocks-en|enter2route]]((enter2route is obsolete and was replaced by FiFo blocks. Since it will be removed from Rocrail someday, it should not be used anymore.)) | It is not connected to a physical sensor, but is generated after an **in** event from the previous block. \\ This kind of event is not suited for trains but solely for Car systems. |
 \\

 \\
==== Timer ====

^  **Timer controlled events**  ^^
^ enter2in | A combination of **enter** and **in**. The events are generated sequentially; **in** is simulated. For blocks with one physical sensor only. |
^ enter2shortin | A combination of **enter** and **shortin**. The events are generated sequentially; **shortin** is simulated. For blocks with two physical sensor only. |
^ enter2pre | A combination of **enter** and **pre2in**. The events are generated sequentially; **pre2in** is simulated. For blocks with two sensors (**enter** and **in**). |

//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.

==== Application ===

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 **[[:loc-int-en|Locomotives: Interface]]**

=== Two Sensors ===

  * Since introduction of the **[[:loc-bbt-en|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**((or the velocity specified for **[[:block-details-en#stop|Stop]]**)) 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.

=== Three Sensors ===

  * With three sensors, **enter**, **pre2in** and **in**, the train decelerates to **V_mid**((or the velocity specified for **[[:block-details-en#stop|Stop]]**)) 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**((or the velocity specified for **[[:block-details-en#stop|Stop]]**)) 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**.

=== Four Sensors ===

  * Finally, four sensors can also be combined: **enter**, **shortin**, **pre2in** and **in**. Then with this variation it is possible to
  - run long trains as far as **in** (with **V_mid** and **V_min** as described above)
  - stop short trains already at **shortin** (e.g., in front of the station building)
  - use **pre2in** for trains that would stop to early with **shortin** and to late with **in** 

=== One Sensor ===

| Even though using only one sensor per block (**enter2in**) is possible, this alternative should not be taken into account or only be used exceptionally. See the warning in table Sensor Events above. |
 
  * 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**((or the velocity specified for **[[:block-details-en#stop|Stop]]**)) at **enter** and if the timer is elapsed (**in**-event) it decelerates to a halt. \\ The timer (event timer) is found in the **[[:block-routes-en#event_timer|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 **[[:loc-details-en|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((enter2route is obsolete and was replaced by FiFo blocks. Since it will be removed from Rocrail someday, it should not be used anymore.)). 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-en#enter2route|Dinamo Car System]]**.

=== Further timer controlled events ===

| See warning in table Sensor Events above. |

  * 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**((or the velocity specified for **[[:block-details-en#stop|Stop]]**)) at **enter** and if the timer is elapsed (**pre2in**-event) it decelerates to **V_min**. \\ The timer (event timer) is found in the **[[:block-routes-en#event_timer|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 **[[:loc-details-en|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**.

 \\
=== Impulse sensors versus occupancy sensors ===

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. \\ 

 \\ 

==== Velocity Sequence ====

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. \\ 

| **Event** | **Reaction** |
| enter2route((enter2route is obsolete and was replaced by FiFo blocks. Since it will be removed from Rocrail someday, it should not be used anymore.)) | if the actual block is occupied the train will be decelerated to **V_mid** at this point already | 
| enter, enter2in, enter2shortin | if the next block is occupied or the train has to stop in the actual block the velocity is set to **V_mid**((or the velocity specified for **[[:block-details-en#stop|Stop]]**)) |
| pre2in | if the next block is occupied or the train has to stop in the actual block the velocity is set to **V_min** |
| in, shortin | if the next block is occupied or the train has to stop in the actual block the velocity is set to **0** |

>**Note:** According **[[:block-details-en#Speed|BlockDialog Details, Speed]]** other speed indications may be configured.

 \\ 
==== Graphical Representation ====
=== Blocks with 3 sensors ===
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. \\ 
|{{:v-3-sensor-block-en.png}}| \\
 \\
=== Blocks with 2 sensors ===
Since the implementation of the __**[[loc-bbt-en|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. \\
{{:bbt:bbt-graphic.png}}\\
|< >|
^ A | Enter speed. |
^ B | BBT steps; In this example 10. |
^ C | Enter event; First BBT step. |
^ 10 | Last BBT step. |
^ D | In event; Step down to zero speed. |
^ E | Zero speed; Loco is in wait or idle mode. |
 \\ 
=== Blocks with only one sensor ===
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 | Event Table]] ** \\
|{{:v-1-sensor-block-en.png}}|\\

 \\

===== Configuration =====
In Rocrail sensor events are configured in the block route properties. For this purpose in the following order
  - blocks are created (**[[:stepbystep-en#blocks|7.1]]**)
  - sensors are set up (**[[:stepbystep-en#sensors|7.2]]**)
  - routes are generated (**[[:stepbystep-en#routes|7.3]]**) and
  - sensor events are configured (**[[:stepbystep-en#configuring_routes|7.3.2]]**).

In brackets are the relevant sections of the **[[:stepbystep-en|step-by-step tutorial]]** given. In addition, the pages on **[[:sensor-gen-en|sensors]]**, **[[:route-gen-en|routes]]** and **[[:block-routes-en|blocks]]** should be regarded.

 \\
===== Shared sensors =====
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. 
 \\
===No rule without exceptions===
  * With the **Block routes option** __**[[block-routes-en##ignore_events_if_not_reserved|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 [[userpages:micha68:stagingblocks#Demo 2|Actions (Demo 2)]] or [[userpages:micha68:virtualfbscript#Scripte|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).
 \\
===== Different sensors in specific routes to the same block =====
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 ====

{{shared-sensor-plan.xml|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.\\ 

{{shared-sensor-plan.png}} \\ 

 \\
=== Sensor events for route 1: ===

{{route-1-shared-sensor.png}} \\ 

 \\
=== Sensor events for route 2: ===

{{route-2-shared-sensor.png}} \\