Wiki source code of Hardware abstraction
Last modified by stu115775 on 2025/01/30 12:17
Show last authors
| author | version | line-number | content |
|---|---|---|---|
| 1 | The Hardwarecontrol should give an abstraction for controlling the Hardware which also makes sure some of the base rules apply. | ||
| 2 | |||
| 3 | === Features === | ||
| 4 | |||
| 5 | * train tracking | ||
| 6 | * block locking/crash avoidance | ||
| 7 | * speed control: driveing and parking in a segment | ||
| 8 | * same speed policy (same speed on all tracks beneath a train) | ||
| 9 | * automatic signal management | ||
| 10 | * automatic point branching | ||
| 11 | |||
| 12 | === Interacting parts === | ||
| 13 | |||
| 14 | The railway is split up into the following smaller interacting parts: | ||
| 15 | |||
| 16 | (% class="wrapped relative-table" style="width: 99.9305%;" %) | ||
| 17 | |=((( | ||
| 18 | Segment/Station | ||
| 19 | )))|((( | ||
| 20 | 1 Track, 2 Contacts, 1 Signal | ||
| 21 | ))) | ||
| 22 | |=((( | ||
| 23 | Segment_bid/Station_bid (bi-directional) | ||
| 24 | )))|((( | ||
| 25 | 1 Track, 2 Contacts, 2 Signals | ||
| 26 | ))) | ||
| 27 | |=((( | ||
| 28 | Track | ||
| 29 | )))|((( | ||
| 30 | 1 Track | ||
| 31 | ))) | ||
| 32 | |=((( | ||
| 33 | Track_bid | ||
| 34 | )))|((( | ||
| 35 | 1 Track | ||
| 36 | ))) | ||
| 37 | |=(% colspan="1" %)(% colspan="1" %) | ||
| 38 | ((( | ||
| 39 | Point_in | ||
| 40 | )))|(% colspan="1" %)(% colspan="1" %) | ||
| 41 | ((( | ||
| 42 | 1 Point with 2 incoming and 1 outgoing tracks | ||
| 43 | ))) | ||
| 44 | |=(% colspan="1" %)(% colspan="1" %) | ||
| 45 | ((( | ||
| 46 | Point_out | ||
| 47 | )))|(% colspan="1" %)(% colspan="1" %) | ||
| 48 | ((( | ||
| 49 | 1 Point with 1 incoming and 2 outgoing tracks | ||
| 50 | ))) | ||
| 51 | |=(% colspan="1" %)(% colspan="1" %) | ||
| 52 | ((( | ||
| 53 | Point_bid | ||
| 54 | )))|(% colspan="1" %)(% colspan="1" %) | ||
| 55 | ((( | ||
| 56 | 1 Point, 2 to 1 bi-directional point | ||
| 57 | ))) | ||
| 58 | |=(% colspan="1" %)(% colspan="1" %) | ||
| 59 | ((( | ||
| 60 | Cross_in | ||
| 61 | )))|(% colspan="1" %)(% colspan="1" %) | ||
| 62 | ((( | ||
| 63 | 1 Track, 2 Points, has 2 incoming, 1 outgoing and 1 bi-directional track where incoming trains get on the main track and outgoing come from the side track | ||
| 64 | ))) | ||
| 65 | |=(% colspan="1" %)(% colspan="1" %) | ||
| 66 | ((( | ||
| 67 | Cross_out | ||
| 68 | )))|(% colspan="1" %)(% colspan="1" %) | ||
| 69 | ((( | ||
| 70 | 1 Track, 2 Points, has 1 incoming, 2 outgoing and 1 bi-directional track where outgoing trains come from the main track and incoming go to the side track | ||
| 71 | ))) | ||
| 72 | |||
| 73 | The differentiation of bi-directional and uni-directional Elements is made to have simpler parts for the unidirectional parts. The "Station" is actually a Segment mostly in a Station and has the property to guarantee a tick boundry between variables in different interfaces, to prevent immediate loops in interface loops. | ||
| 74 | |||
| 75 | With these we can model the railway system by connecting these parts in terms of mapping input and output values according to the connections. To fulfill the tasks/rules every connection (each-direction) has the following variables, where in and out describes if it's an input/output of the previous part in travel direction: | ||
| 76 | |||
| 77 | (% class="wrapped" %) | ||
| 78 | |=(% colspan="1" %)(% colspan="1" %) | ||
| 79 | ((( | ||
| 80 | input | ||
| 81 | )))|=(% colspan="1" %)(% colspan="1" %) | ||
| 82 | ((( | ||
| 83 | bool | ||
| 84 | )))|=(% colspan="1" %)(% colspan="1" %) | ||
| 85 | ((( | ||
| 86 | incoming_blocked | ||
| 87 | )))|(% colspan="1" %)(% colspan="1" %) | ||
| 88 | ((( | ||
| 89 | (bidirectional only) if true: there should not be any lock requests to prevent a Deadlock by two trains comeing infront of each other | ||
| 90 | ))) | ||
| 91 | |=(% colspan="1" %)(% colspan="1" %) | ||
| 92 | ((( | ||
| 93 | input | ||
| 94 | )))|=(% colspan="1" %)(% colspan="1" %) | ||
| 95 | ((( | ||
| 96 | bool | ||
| 97 | )))|=(% colspan="1" %)(% colspan="1" %) | ||
| 98 | ((( | ||
| 99 | lock_request_pending | ||
| 100 | )))|(% colspan="1" %)(% colspan="1" %) | ||
| 101 | ((( | ||
| 102 | (bidirectional only) if true: there is a lockrequest waiting to get a lock | ||
| 103 | ))) | ||
| 104 | |=(% colspan="1" %)(% colspan="1" %) | ||
| 105 | ((( | ||
| 106 | output | ||
| 107 | )))|=(% colspan="1" %)(% colspan="1" %) | ||
| 108 | ((( | ||
| 109 | bool | ||
| 110 | )))|=(% colspan="1" %)(% colspan="1" %) | ||
| 111 | ((( | ||
| 112 | send_lock_request | ||
| 113 | )))|(% colspan="1" %)(% colspan="1" %) | ||
| 114 | ((( | ||
| 115 | (bidirectional only) if true: the waiting lock request is actually requested. This is used together with the previous ones to allow faster lock assignment, since otherwise a Track_bid would only pass a lockrequest every other tick to have no more than one lock going thru it. | ||
| 116 | ))) | ||
| 117 | |=(% colspan="1" %)(% colspan="1" %) | ||
| 118 | ((( | ||
| 119 | output | ||
| 120 | )))|=(% colspan="1" %)(% colspan="1" %) | ||
| 121 | ((( | ||
| 122 | int | ||
| 123 | )))|=((( | ||
| 124 | requestLockFor | ||
| 125 | )))|((( | ||
| 126 | id of the track to request the lock for | ||
| 127 | |||
| 128 | -1: get any next lock | ||
| 129 | ))) | ||
| 130 | |=(% colspan="1" %)(% colspan="1" %) | ||
| 131 | ((( | ||
| 132 | output | ||
| 133 | )))|=(% colspan="1" %)(% colspan="1" %) | ||
| 134 | ((( | ||
| 135 | int | ||
| 136 | )))|=((( | ||
| 137 | requestLockTrain | ||
| 138 | )))|((( | ||
| 139 | when requestLockFor!=0 the id of the incoming train | ||
| 140 | ))) | ||
| 141 | |=(% colspan="1" %)(% colspan="1" %) | ||
| 142 | ((( | ||
| 143 | input | ||
| 144 | )))|=(% colspan="1" %)(% colspan="1" %) | ||
| 145 | ((( | ||
| 146 | bool | ||
| 147 | )))|=((( | ||
| 148 | Locked | ||
| 149 | )))|((( | ||
| 150 | the next part is locked and expects an incoming train, lock is released when train reaches the next track | ||
| 151 | ))) | ||
| 152 | |=(% colspan="1" %)(% colspan="1" %) | ||
| 153 | ((( | ||
| 154 | input | ||
| 155 | )))|=(% colspan="1" %)(% colspan="1" %) | ||
| 156 | ((( | ||
| 157 | bool | ||
| 158 | )))|=((( | ||
| 159 | Branched | ||
| 160 | )))|((( | ||
| 161 | the connection to the next "part"(save track) is branched (to set the signal) | ||
| 162 | ))) | ||
| 163 | |=(% colspan="1" %)(% colspan="1" %) | ||
| 164 | ((( | ||
| 165 | input | ||
| 166 | )))|=(% colspan="1" %)(% colspan="1" %) | ||
| 167 | ((( | ||
| 168 | bool | ||
| 169 | )))|=((( | ||
| 170 | PullSpeed | ||
| 171 | )))|((( | ||
| 172 | the speed to synchronize to have one speed for all used tracks | ||
| 173 | ))) | ||
| 174 | |||
| 175 | These should be written in order to have a dependency cycle free model and there has to be a part in each cycle that writes each of these independent of the correspoding value in another input interface. |