Hello Märklin & Rocrail fans,

I'd like to share with you an example of complex « actions » (sometimes conditional), which are currently driving my railroad crossings.
This article will be posted in 3 parts, due to post restriction size.

PART1

1 Preamble

This note is a complement/deeper example to http://wiki.rocrail.net/...hp?id=level_crossing_en. This link already describes how to setup a railroad crossing using outputs, sensors and actions.

It is recommended, if you are not aware of « actions » and wish to go further, to fully read before the wiki about actions and the examples already provided.

Please note the following : « Try when you design a layout to apply what is already described in the link.  It's the most simple. Unhappily, there are some cases where you can't avoid some complexity, so this example tries to illustrate some ways to manage it (and it is certainly far from perfect !) »

Please also note this topic may be difficult to understand if you don't already have an experience with Rocrail, especially with « blocks », « routes », « outputs » and basic « actions ».

2 Introduction

In my case, I had many constraints (maybe due to lack of design... )

• the sensors weren't put on the tracks in the right place, and dismantling the layout wasn't an option.
  
• the traffic involved by my two railroad crossings is bi-directional
  
• one of the railroad crossing is set between 2 tracks, the second one has only one track
  
• all railroad crossings are complemented by 4 X St Andrew crosses
  
• the already in place sensors were either too close to railroad crossings, or simply missing to provide realistic closure/opening of the barriers

...but with luck

• many automated blocks were already in place and gave satisfactory behavior

So the idea to drive « actions » is to use events related to blocks occupancy, and if not enough, use events related to routes triggering, and sometimes events related to signals. The occurrence of events depends on the « state » of each block and/or route and/or signals involved.
These events are called in the Rocrail documentation « action controls ».

That is what I mean by using complex actions.

Here is an extract of my Rocrail synoptic:


3 Setup
3.1 Hardware used

• 2 sets of railroad crossings (Viessmann 5100)
  
• 2 sets of 4 St Andrew crosses (Viessmann 5835)
  
• 1 K83 (or compatible)
  
• 1 K84 (or compatible)

3.2 Railroad crossing 1 (double track - down-left angle)

• addresses 61 & 62 (one address for each barrier), driven by half a K83. Setup in Rocrail is done by switches (Gate61 & Gate62), with a type of Accessory, and Accessory picture #11 (single barrier)
  
• set of St Andrew crosses, address 137, driven by 1/4 K84. Setup in Rocrail is done by an « Output » object (k137)

3.3 Railroad crossing 2 (single track - middle on the left)

• addresses 63 & 64 (one address for each barrier), driven by the remaining half of the K83. Setup in Rocrail is done by switches (Gate63 & Gate64), with a type of Accessory, and Accessory picture #11 (single barrier)
  
• set of St Andrew crosses, address 138, driven by 1/4 K84. Setup in Rocrail is done by an « Output » object (k138)
  

...A picture of the real life...

bottom of image is Railroad crossing 1, top of image is Railroad crossing 2

4 Traffic
Note: Please look at the green arrows in the synoptic. They describe the traffic direction allowed in each block.

4.1 Traffic involved for Railroad crossing 1 (medium complexity)
Note: Sidings blocks are currently not included in the traffic.

4.1.1 Single direction track

• From BFront1 then BFront2 to BDown1
  
• From BFront1 then BFront2 to BRear1
  
• From BFront1 then BFront2 to BRear2

4.1.2 Bi-directional track

• From BFront3 to BDown1
  
• From BFront3 to BRear1
  
• From BFront3 to BRear2
  
• From BRear1 to BFront3
  
• From BRear2 to BFront3

Note: BFront2 is a short block

4.2 Traffic involved for Railroad crossing 2 (higher complexity...All bi-directional !)
Note: Sidings blocks are currently not included in the traffic.

4.2.1 From left to right

• From BRear1 to BStation2
  
• From BRear1 to BStation3
  
• From BRear2 to BStation2
  
• From BRear2 to BStation3

4.2.2 From right to left

• From BStation1 to BDown1
  
• From BStation1 to BRear1
  
• From BStation1 to BRear2
  
• From BStation2 to BDown1
  
• From BStation2 to BRear1
  
• From BStation2 to BRear2

5 Definition of « Actions »
This section describes how to define the « actions ».
























END OF PART1
The second part will follow soon...

Cheers
Fabrice

Edited by user 18 June 2014 17:35:11(UTC)  | Reason: re-uploaded pictures

PART2

6 Action controls which trigger the actions

This section describes how to implement the action controls.
Please note these action controls are NOT defined inside the « actions » sub-menu. They are defined in the source objects (which generate the triggering events) i.e. the blocks, routes and signals.

6.1 Requirements for traffic described in section 4.1.1

• Req 1-1: When a loco leaves BFront1 towards BFront2, Gates 61 & 62 must be closed and StAndrew137 must be active (blinking red lights) (easy )
  
• Req 1-2: When the block BFront2 is freed, Gates 61 & 62 must be opened and StAndrew137 must be inactive (no more blinking red lights) (less easy)

6.2 Implementation
6.2.1 Req 1-1
Action control on block BFront1 :








6.2.2 Req 1-2
Action control on Block BFront2 :










Problem : If blocks BFront1 and BFront2 are both occupied and trains are stopped because of each waiting for a free destination, Req 1-1 implies Gate61 & 62 are closed.
Now, if a train leaves BFront2 and frees that block, Req 1-2 implies Gate61 & 62 are opened ;
BUT if the train in BFront1 has not entered yet BFront2, then the gates won't be closed !
-> some supplementary requirement is needed (see Req 1-3)

6.3 Supplementary requirement

• Req 1-3: When the block BFront2 is entered, Gates 61 & 62 must be closed and StAndrew137 must be active (blinking red lights)

6.4 Implementation of Req 1-3
Action control on Block BFront2 :







Question: « Why not only use Req 1-3 instead of Req 1-1 ? »
Answer: « Because if a train doesn't stop in BFront1, the trigger on "entering" BFront2 is a bit late compared to the time necessary for the loco speed to decrease/time necessary for the barriers to go down. When the loco is starting from BFront1, the delay is more acceptable ».

In summary, the primary event for closing the barriers is « BFront1 occupied » and the secondary/security event is « BFront2 entered ».

6.5 Requirements for traffic described in section 4.1.2

• Req 1-4: When the block BFront3 is entered from right to left, Gates 61 & 62 must be closed and StAndrew137 must be active (blinking red lights) ...easy  !
  
• Req 1-5: When the block BFront3 is freed (from any direction), Gates 61 & 62 must be opened and StAndrew137 must be inactive (no more blinking red lights) ...easy  !

6.6 Implementation of Req 1-4 and 1-5
Action control on Block BFront3 :















6.7 Requirements for traffic described in section 4.1.2 (cont.)

• Req 1-6: The sensor r1-11 is too close to barriers, so the event related to this sensor can't be used when a loco enters the block BFront3 from left to right (less easy ). This requirement can be translated in the following two requirements :
  
  • Req 1-6-1: When the route BRear1->BFront3 is set, Gates 61 & 62 must be closed and StAndrew137 must be active (blinking red lights)
    
  • Req 1-6-2: When the route BRear2->BFront3 is set, Gates 61 & 62 must be closed and StAndrew137 must be active (blinking red lights)

6.8 Implementation of Req 1-6-1 and 1-6-2
Action control on Routes :

6.8.1 Route BRear1->BFront3








6.8.2 Route BRear2->BFront3









This ends the implementation of the Railroad crossing #1 (medium complexity).
END OF PART2

...Part3 is coming...Hold on
Cheers
fabrice

Edited by user 18 June 2014 18:03:04(UTC)  | Reason: re-uploaded pictures