Les capteurs sont une composante essentielle de chaque modèle de chemin de fer commandé par ordinateur. Par les capteurs les positions des trains sur la disposition sont annoncées au logiciel. Les capteurs peuvent soit fournir une impulsion (par exemple, des rails de commutation, des contacts Reed, des capteurs de hall) ou un signal permanent (par exemple, des rails de contact, d'autres détecteurs d'occupation comme des détecteurs de courant, etc.). Une vue d'ensemble du matériel et une introduction à l'utilisation des capteurs est fournie sur la page Capteurs.
Dans Rocrail, les capteurs sont définis comme des objets. La page Objets: Capteurs et ses sous-pages renseignent sur la configuration des capteurs.
Remarque: Pour éviter les malentendus, il convient de noter qu'avec le mot «capteur», des capteurs physiques (matériels, matériels) sont appelés, ainsi que les objets logiciels et les événements correspondants.
Rocrail a besoin de deux événements de capteur pour chaque bloc qui définissent quand un train entre dans le bloc et quand il a (presque)1) atteint la fin du bloc. Ces capteurs sont appelés comme enter et in. Lorsque nécessaire, des capteurs supplémentaires comme pre2in, shortin etc peuvent être ajoutés.
La définition des capteurs se produit dans les propriétés d'itinéraire d'un bloc et dépend du bloc auquel le train vient. Pour toutes les voies possibles, les capteurs doivent être définis. Par conséquent, avant la définition des capteurs dans les propriétés du bloc toutes les routes doivent avoir été mis en place auparavant.
Tous types d'évènement peut fournir une information supplémentaire bidirectionnelle (identité).
|enter||Le train entre dans le bloc. la vitesse est réglé sur V_mid2), dans le cas où aucune destination libre n'est trouvée ou dans le cas où le train devrait attendre.|
|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, 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
|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. Use with care! For short trains and automobiles only.|
|enter2route|| 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 controlled events
Limited support; Long timers can severely disturb automatic control if overlapping subsequent events.
Using timed events is disadvised!
No forum support for event timers longer than 100ms
|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).|
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.
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
Tip: Whether or not using BBT can be defined for each block individually. This decision has not to be made for the whole layout.
|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.|
|See warning in table Sensor Events above.|
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
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.
|enter2route||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_mid8)|
|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 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.
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.
In Rocrail sensor events are configured in the block route properties. For this purpose in the following order
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.
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!
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.