![]() Typically a sensor triggers different events depending on the direction of the traffic.įor a correct functioning of the automatic mode at least the events enter and in have to be triggered in each block. Events in brackets are optional.įor the opposite direction of the traffic the allocation is to be repeated from opposite view. No forum support for event timers longer than 100ms.Īs explained below in more detail the following general order of events takes place: enter→ (shortin) → (pre2in) → in. ![]() Timer controlled events has Limited support Long timers can severely disturb automatic control if overlapping subsequent events. For blocks with two sensors ( enter and in). The events are generated sequentially pre2in is simulated. For blocks with two physical sensor only.Ī combination of enter and pre2in. The events are generated sequentially shortin is simulated. For blocks with one physical sensor only.Ī combination of enter and shortin. The events are generated sequentially in is simulated. This kind of event is not suited for trains but solely for Car systems.Ī combination of enter and in. It is not connected to a physical sensor, but is generated after an in event from the previous block. The use of this event is discouraged: Use BBT instead. 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. When this happens the train is stopped immediately and put back in manual mode. This event is used for extra safety and detects if a train does not stop with in the distance between in and exit. Use this event type only if the sensor has no further functionality. (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. Some sensor systems provide more information like the address of the passing locomotive. The status will be evaluated if a reserve request is put by a train to make sure the whole block is electrically free. No action is taken as long as it is not unexpected. Hence, before the definition of sensors in the block properties all routes must have been set up before. For all possible routes sensors have to be defined. The definition of the sensors occurs in the route properties of a block and depends on from which block the train comes. When required additional sensors like pre2in, shortin etc. These sensors are called as enter and in. Rocrail needs two sensor events for every block which define when a train is entering the block and when it has (almost) 1) reached the end of the block. > 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. ![]() The page Objects: Sensors and its sub pages inform about the setup of sensors. In Rocrail sensors are defined as objects. An overview of the hardware and an introduction to the use of sensors is provided on the page Sensors. 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.). By the sensors the positions of the trains on the layout are announced to the software. If you're new to it, we recommend you start with their Step-by-Step Tutorial.Īndroid, macOS, and Linux builds are usually different.Sensors are a core component of every computer controlled model railway. Rocrail has so many features one could write a book on it. Rocweb - web client for all (also mobile) devices. ![]()
0 Comments
Leave a Reply. |