My new high tech Fully Automated Railroad Crossing
821.3 هزار بار بازدید -
4 سال پیش
-
This video shows the main
This video shows the main functionalities of the automated railroad crossing gates on the HaSaKo HO Modelrailroad integrated in the Faller Car System Digital.
The automated RR-crossing gates/barriers and bell sound are a copy of the Netherlands AHOB crossing gates / barriers. The RR-crossing is controlled by both the Train software and the Faller Car System Digital 3.0 software. There are no stop magnets in the road and there are no fixed contacts in or around the track. The command of closing or opening of the gates/barrier is programmed in the Windigipet train software and is integrated in the programmed route options. It uses data from the track occupation messages to define if the train is approaching the RR-crossing and/or has passed. The system works for all 3 tracks and in any direction, as long as still one train is expected on one of the tracks the RR-crossing gates stay closed. The train software gives an output command to a 4-fold DCC decoder with bi-stable relay outputs. One output activates a relay to power the RR-crossing electronic controls and sound system. And another output creates a trigger signal to a Faller Traffic Controller decoder to tell the car system control program the RR-crossing is going to close or open. In the Faller software program the RR-crossing gates/barrier are treated as a virtual traffic light.
The DCC cars are controlled by Faller Car System 3.0 which uses an indoor satellite system to identify the position of each car on the road and gives commands using RF. The position of the gates is known in 3D coordinates by the satellite system. The cars are stopping if they approach the RR-crossing within a certain distance.
The gates/barrier need 6-7 seconds to drop or raise, which needs to be accounted for in both train and car software programs. I programmed a 5 seconds delay for trains leaving the very nearby station to allow the gate to close. Likewise when the gate/barrier gets command to raise (open) the cars are programmed to wait 7 seconds before pulling off. These timings I have defined experimental.
A big risk is cars getting stuck on the RR-crossing itself and then being destroyed by a model train at speed. (yes, the model train wins). I solved this by writing a small program logic in FCS 3.0 that only allows a car to pass the RR-crossing when sufficient space is at other side. Similar to avoid cars hitting a dropping gate/barrier or accidental stop under the gate and block it, I programmed a "non-stop" special zone. When a car is in that zone it will not stop if the RR-gates are going to close, but drive-on. Like in reality. The program also allows multiple cars to queue for a closed gate.
The automated RR-crossing gates/barriers and bell sound are a copy of the Netherlands AHOB crossing gates / barriers. The RR-crossing is controlled by both the Train software and the Faller Car System Digital 3.0 software. There are no stop magnets in the road and there are no fixed contacts in or around the track. The command of closing or opening of the gates/barrier is programmed in the Windigipet train software and is integrated in the programmed route options. It uses data from the track occupation messages to define if the train is approaching the RR-crossing and/or has passed. The system works for all 3 tracks and in any direction, as long as still one train is expected on one of the tracks the RR-crossing gates stay closed. The train software gives an output command to a 4-fold DCC decoder with bi-stable relay outputs. One output activates a relay to power the RR-crossing electronic controls and sound system. And another output creates a trigger signal to a Faller Traffic Controller decoder to tell the car system control program the RR-crossing is going to close or open. In the Faller software program the RR-crossing gates/barrier are treated as a virtual traffic light.
The DCC cars are controlled by Faller Car System 3.0 which uses an indoor satellite system to identify the position of each car on the road and gives commands using RF. The position of the gates is known in 3D coordinates by the satellite system. The cars are stopping if they approach the RR-crossing within a certain distance.
The gates/barrier need 6-7 seconds to drop or raise, which needs to be accounted for in both train and car software programs. I programmed a 5 seconds delay for trains leaving the very nearby station to allow the gate to close. Likewise when the gate/barrier gets command to raise (open) the cars are programmed to wait 7 seconds before pulling off. These timings I have defined experimental.
A big risk is cars getting stuck on the RR-crossing itself and then being destroyed by a model train at speed. (yes, the model train wins). I solved this by writing a small program logic in FCS 3.0 that only allows a car to pass the RR-crossing when sufficient space is at other side. Similar to avoid cars hitting a dropping gate/barrier or accidental stop under the gate and block it, I programmed a "non-stop" special zone. When a car is in that zone it will not stop if the RR-gates are going to close, but drive-on. Like in reality. The program also allows multiple cars to queue for a closed gate.
4 سال پیش
در تاریخ 1399/10/19 منتشر شده
است.
821,304
بـار بازدید شده