#openttdcoop wiki - User contributions [en]

User:X-BT/Edge detectors

2009-07-17T14:57:00Z

X-BT: Changed text to match new image

== Introduction ==

Edge detectors are circuits that output a pulse when the input changes state. In TTD that is a pulse for each transition from red to green or from green to red. This type of circuit is commonly used in train counters. A signal connected to a block on the line will be red while a train is passing, and green otherwise. The counting circuit usually requires a short green pulse to advance one step. This is solved by using some sort of edge detector, that outputs a pulse for every rising or every falling edge. I have experimented with a couple of different designs for edge detectors. Those I present here are both simple, compact and reliable (no chance of jamming). Other designs I have looked into include the use of a NOT-gate to control a pulse generating train. The design used in PSG 149 is of this kind (not my work). Also a single train NOT-gate (which occationally jams) can be modified to an edge detector that also jams sometimes and therefore misses some of the edges.

== Basic idea ==

The basic idea was to modify a two train NOT-gate to make an edge detector with only two trains running in a signle loop. This two train NOT-gate works by letting the trains run around the circle while the input is green. The output is then connected as an AND (same principle as prios) between two the blocks. The blocks will never be green at the same time unless both trains are waiting for the input to turn green. We need the output to be red when both trains are running and when both trains are waiting, and green for a short time either when they start or when they stop. This will result in a red to green or a green to red detector as described above.

== How I implemented them? ==

Both my designs uses an AND of three blocks in the loop. This means that the output only turns green when all three blocks are green. The idea behind the green to red detector is to let the output turn green for a short time when the first train has stopped. To achieve this I input the the block behind the waiting point to the AND gate. The block on the opposite side of the loop is large enough to fit a train and is not connected to the AND. Also the block just before the waiting signal can not be connected to the AND, as this would mean that output could only be red when the first train had stopped. So the block that the second train waits in must also be connected to the AND gate. With these requirements stated, it was only a matter of tuning the signal placement before it worked correctly.

The red to green is quite opposite. The block where the first train is waiting is connected to the AND gate, but not the block where the second train is waiting. The idea is to generate a short green pulse when the first train have left its waiting block. This means that the block that this train is entering must not be connected to the AND gate, and it must be large enough to fit the train. To stop the second train from reaching the block connected to the AND gate at the instant the first train has left, I added a pre sign to delay it. When the second train is in the block behind the waiting signal the first train will be in a block covered by the AND gate.

== Examples ==
The red to green detector to the west is a copy of my first working edge detector. The middle one is a more compact version. The green to red detector is also a redesign of a less compact version. The compact designs have been tested both with maglev Lev4 'Chimaera' and with these monorail trains. The less compact editions was made with 'AsiaStar' (Electric). I do not guarantee that they will work with other trains or other config, but you should be able to get them working by tweaking the signal placement and loop length.

[[Image:X-BT_Edge_detectors.png]]

File:X-BT Edge detectors.png

2009-07-17T14:53:46Z

X-BT: uploaded a new version of "File:X-BT Edge detectors.png": Changed to monorail for readability.

A couple of edge detectors connected to a busy line.

File:X-BT Counter cascade.png

2009-07-17T14:51:43Z

X-BT: uploaded a new version of "File:X-BT Counter cascade.png": Missing combo signal (thanks Fuco), changed to monorail for readability

Cascade of counters, without using extra edge detectors.

User:X-BT

2009-07-16T14:49:57Z

X-BT:

'''Born:''' 1986

'''Location:''' Svelvik, Norway

'''Occupation:''' Master student, cybernetics (until spring 2010)

'''Started playing TTD:''' TTO about 1995 some time, played my first game until money overflow some time in 2050+?...

'''First PSG:''' 149, I finally found someone who likes to play TTD

'''Prefers:''' Terrain frendly solutions, experiments, complex designs

'''Dislikes:''' Trains crashing, local authorities, road vehicle deadlocks

'''Favourite transportation concept:''' Personal Rapid Transit

== Some of my designs ==
[[User:X-BT/Zipper_merge]]

[[User:X-BT/Edge_detectors]]

[[User:X-BT/Counters]]

[[User:X-BT/7-segment]]

User:X-BT/7-segment

2009-07-16T14:49:06Z

X-BT: New page: I know this is not unique, but I just had to make my own train counter with a 7-segment train-LED-display (also made one with signal display, much easier). I hope this might be of help if ...

I know this is not unique, but I just had to make my own train counter with a 7-segment train-LED-display (also made one with signal display, much easier). I hope this might be of help if you want to make your own.

== The Display ==
The display is made with diagonal tracks to avoid CL issues when train is leaving and entering. It also makes the digit correctly oriented on the monitor. The LEDs are connected from both sides, to control both sides of the two way pre-signals. This means that each LED requires both non-inverted and inverted input, and that trains only move when their status changes.

[[Image:X-BT_7-segment.png]]

== Gate Array ==
To control the display I use an inverted counter and a huge gate array. This gate array makes an OR comparision of selected outputs from the inverted counter. The array supplies both non-inverted and inverted signals for the display, so there are a total of 14 outputs. To the bottom right I put a template for the array with 2x2 outputs and 1 input. It shows how to connect to make that input turn a LED on (north output) or off (south output). Output signed 'on' is non-inverted and 'off' is inverted. The inverted counter has one or none green outputs, so the transition from one state to the next will be through all outputs red, which is just fine. Both screenshots are taken paused, so the output of the gate array is 4.

[[Image:X-BT_7-segment_gate_array.png]]

File:X-BT 7-segment.png

2009-07-16T14:17:56Z

X-BT: 7-segment display with diagonal tracks.

7-segment display with diagonal tracks.

File:X-BT 7-segment gate array.png

2009-07-16T14:16:55Z

X-BT: Complete 7-segment gate array for digits 0-9

Complete 7-segment gate array for digits 0-9

User:X-BT/Counters

2009-07-16T14:02:40Z

X-BT:

This is a collection of some of my additions to the field of counting trains with trains.

== Simplified cascade ==
This is a simple way to cascade more counters to get more digits. It does not require one edge detector for each digit, only for the first. The idea is to let the green pulse from the edge detector get through to the next counter only when a digit is at 9.

[[Image:X-BT_Counter_cascade.png]]

== Inverted counter ==
If you have built a counter with outputs and added NOT gates to all of them, then don't be mad at me for writing this. The following counter design has inverted outputs. The transition from one state to the next is through all red, which makes it suitable for a 7-segment display. The train has a total length of 37. You should probably use multiple engines. Another option is to have 9 small trains, but that requires some more signals.

[[Image:X-BT_Inverted_counter.png]]

User:X-BT

2009-07-16T13:54:50Z

X-BT:

User:X-BT/Counters

2009-07-16T13:53:06Z

X-BT: New page: This is a collection of some of my additions to the field of counting trains with trains. == Simplified cascade == This is a simple way to cascade more counters to get more digits. It do...

This is a collection of some of my additions to the field of counting trains with trains.

== Simplified cascade ==
This is a simple way to cascade more counters to get more digits. It does not require one edge detector for each digit, only for the first. The idea is to let the green pulse from the edge detector get through to the next counter only when a digit is at 9.

[[Image:X-BT_Counter_cascade.png]]

== Inverded counter ==
If you have built a counter with outputs and added NOT gates to all of them, then don't be mad at me for writing this. The following counter design has inverted outputs. The transition from one state to the next is through all red, which makes it suitable for a 7-segment display. The train has a total length of 37. You should probably use multiple engines. Another option is to have 9 small trains, but that requires some more signals.

[[Image:X-BT_Inverted_counter.png]]

File:X-BT Inverted counter.png

2009-07-16T13:52:08Z

X-BT: Counter with inverted outputs.

Counter with inverted outputs.

File:X-BT Counter cascade.png

2009-07-16T13:50:30Z

X-BT: Cascade of counters, without using extra edge detectors.

Cascade of counters, without using extra edge detectors.

User:X-BT

2009-07-16T12:15:52Z

X-BT:

User:X-BT/Edge detectors

2009-07-16T12:12:57Z

X-BT: New page: == Introduction == Edge detectors are circuits that output a pulse when the input changes state. In TTD that is a pulse for each transition from red to green or from green to red. This ty...

== Introduction ==

Edge detectors are circuits that output a pulse when the input changes state. In TTD that is a pulse for each transition from red to green or from green to red. This type of circuit is commonly used in train counters. A signal connected to a block on the line will be red while a train is passing, and green otherwise. The counting circuit usually requires a short green pulse to advance one step. This is solved by using some sort of edge detector, that outputs a pulse for every rising or every falling edge. I have experimented with a couple of different designs for edge detectors. Those I present here are both simple, compact and reliable (no chance of jamming). Other designs I have looked into include the use of a NOT-gate to control a pulse generating train. The design used in PSG 149 is of this kind (not my work). Also a single train NOT-gate (which occationally jams) can be modified to an edge detector that also jams sometimes and therefore misses some of the edges.

== Basic idea ==

The basic idea was to modify a two train NOT-gate to make an edge detector with only two trains running in a signle loop. This two train NOT-gate works by letting the trains run around the circle while the input is green. The output is then connected as an AND (same principle as prios) between two the blocks. The blocks will never be green at the same time unless both trains are waiting for the input to turn green. We need the output to be red when both trains are running and when both trains are waiting, and green for a short time either when they start or when they stop. This will result in a red to green or a green to red detector as described above.

== How I implemented them? ==

Both my designs uses an AND of three blocks in the loop. This means that the output only turns green when all three blocks are green. The idea behind the green to red detector is to let the output turn green for a short time when the first train has stopped. To achieve this I input the the block behind the waiting point to the AND gate. The block on the opposite side of the loop is large enough to fit a train and is not connected to the AND. Also the block just before the waiting signal can not be connected to the AND, as this would mean that output could only be red when the first train had stopped. So the block that the second train waits in must also be connected to the AND gate. With these requirements stated, it was only a matter of tuning the signal placement before it worked correctly.

The red to green is quite opposite. The block where the first train is waiting is connected to the AND gate, but not the block where the second train is waiting. The idea is to generate a short green pulse when the first train have left its waiting block. This means that the block that this train is entering must not be connected to the AND gate, and it must be large enough to fit the train. To stop the second train from reaching the block connected to the AND gate at the instant the first train has left, I added a pre sign to delay it. When the second train is in the block behind the waiting signal the first train will be in a block covered by the AND gate.

== Examples ==
The red to green detector to the west is a copy of my first working edge detector. The middle one is a more compact version. The green to red detector is also a redesign of a less compact version. The compact designs have only been tested with these maglev trains. The less compact editions was made with 'AsiaStar' (Electric). I do not guarantee that they will work with other trains or other config.

[[Image:X-BT_Edge_detectors.png]]

File:X-BT Edge detectors.png

2009-07-16T12:10:43Z

X-BT: A couple of edge detectors connected to a busy line.

A couple of edge detectors connected to a busy line.

User:X-BT

2009-07-15T14:32:52Z

X-BT:

User:X-BT/Zipper merge

2009-07-15T14:29:57Z

X-BT: Description of Zipper merge compressor designed by X-BT

This is an attempt to reduce the gap between trains traveling on a track, also called compressing. It is based on the zipper-principle used when merging two lanes on a densely trafficated road, alternating equally between the lanes. The basic idea of my implementation is to hold back every train for a short while at one of the tracks to make gaps that a train from the other track fits perfectly into. Then every train on the other track is also stopped and released at the right time so that it will merge perfectly into the gaps on the first track. This is done entirely by the use of presignal logics, and it is quite simple to achieve. This construction is often called a compressor.

[[Image:X-BT_zipper.png]]

In this example I have trains with a considerable difference in acceleration. These may not be mixed before the merger. Also since I am using single headed steam trains, the valuables trains barely manage to reach full speed before the merge point. With this long acceleration stretch I had to add a more complex jam detection system than I have used earlier.

== Construction guide ==
1 ) Start by building two tracks that merge. Decide which track shall generate gaps, and which shall merge into the gaps. The tracks must be long enough for the trains to accelerate to full speed before the merge point.

2 ) Construct the gap generating signal (A). This shuld be a pre-signal followed by an exit-signal at the next tile. The example has a more complex jam preventing feedback, that may be implemented later when everything is tuned. Until then you may have stop the waiting trains to clear jams.

3 ) Construct the two normal signals pointed at by the arrows (C), and the connection between the block before and after these two signals (the one with the middle combo-signal in the example). The distance between signal (A) and the first of these two singals determines the gap size (no signals here, except for the exit-signal). Let this distance be large at first, then tune it later by moving signal A closer. As indicated, signals (C) should have room for one train between them.

4 ) Construct the release signal (B) for the other track. This signal is controlled by the trains at the first track. Under normal operation it turns green when a train is in the block between signals (C). That is also the condition for signal (A) to turn green, so trains start simultaneously at both tracks.

== Tuning ==
Time to let the trains enter the merger and see how it works.

1 ) Move signal (B) so that the trains coming from it gets as close to the trains from (A) as possible. Moving it closer to the merging point reduces the gap. Make sure that they merge without slowdowns. If a jam occur and presists, just stop a train waiting at signal (B) until it clears.

2 ) Move signal (A) to make trains from (A) get as close to trains from (B) as possible. Congratulations, it is now tuned for (almost) minimal gaps.

== Jam detection and clearing ==
The idea is to stop releasing trains when there is a jam at the merge point. It may be enough to stop the trains at (B) from releasing, since trains from (A) have large gaps that should absorb the jam. With the slow acceleration of the steam trains, I found it best to stop both releases until track was cleared. The key point when adding the jam detector is to detect that a train is in a specific place where it should not be when the trains are released. To get it right you have to make it run properly, then take a note of where the trains are when the next couple is released (on singleplayer you can use the pause button). Then you can add feedback from blocks that contains no trains at release time during normal operation. The feedback can be from one or both of the two tracks (I belive it is best to connect from both when stopping both releases). If no such train free blocks exist close to the merging point, move the merging point one or more blocks down the line.

== Notes ==
- The merger must have trains waiting at both incoming lines for optimal operation. If there are too few trains, it might happen that one of them does not come to a complete stop before release, and a jam is most likely to occur.

- For equal acceleration it is possible to place signal (B) perfectly before tuning (can you figure out where it should be relative to signals (C) ?).

- For different acceleration the slowes ones should probably go on (A) since they require longer acceleration stretch.

- Diagonal tracks cause problem for compressed lines. For a single S-bend add extra signals about one TL prior to the bend.

- Gaps may be fine tuned with the use of diagonal tracks. For instance try to change which track goes straight at the merge point.

== Variants ==
In PSG 149 I made a variant where the logics is placed between the two tracks, rather than on the sides. This probably conserves some space in most cases.
It is possible to add a bypass to let the trains at (A) tun contineously when the queue at (B) is empty. (Trains at (B) runs contineously if there are no trains at (A))

File:X-BT zipper.png

2009-07-15T12:56:35Z

X-BT: Zipper merge in action

Zipper merge in action

User:X-BT

2009-07-15T10:06:34Z

X-BT: New page: '''Born:''' 1986 '''Location:''' Svelvik, Norway '''Occupation:''' Master student, cybernetics (until spring 2010) '''Started playing TTD:''' TTO about 1995 some time, played my first g...