Tommy
Well-known member
A while back, in the DF Succession fort thread, I mentioned an automated minecart system and promised to post a save when I finished it. I never "finished" that one, as soon as I got it working some problems became apparent.
The system was based on two "nodes" connected by some double track with floodgate/raisingbridge catchments at each end. Each node contained 4 stops, all individually gated, which operated in "pairs" - one stop at each end. A minecart slowly ran around a long track, and once each lap it triggered some catchments in a "control loop" consisting of 4 sections. In each section, a pressure plate would reset the previous lines cart latch and set it's own cart latch, and the cart latches were connected to the stop gates, etc. In effect, one "turn" consisted of four clock cycles, and each route had one opportunity per turn. For instance, when a cart was loaded it would be pushed up to a roller which was in front of a gate. When it's turn came, the stop's gates would open and the cart would be allowed to enter the node, where it would end entering the catchment at it's end of the doubletrack. Next cycle, the catchment completes and the cart makes the trip down the double track. On the third cycle, the cart exits the double track and enters the desired stop. If it's a roll-through dump stop the cart continues to the catchment, and on the third cycle re-enters the doubletrack going home. On the fourth cycle, it returns to it's originating stop.
The problems with that system are plentiful. First - it's slow. The clock has to be slow enough to allow the slowest cart to complete the slowest segment of it's journey - even if no carts are actually running. Carts will spend a lot of time waiting - more time waiting than moving in most cases!
Second, it doesn't scale well. Four routes isn't enough. We could add a pair of catchments to the middle of the double track and put 6 stops on each node, and we can "stack" separate track systems (even run them from the same "controller", but this all takes a lot of space. Space where you'd rather have workshops and stockpiles, etc.
Big, Slow, and Stupid just wasn't going to cut it. I needed something a bit more "on demand".
I started a "research fort", no invasions, added some ores, etc, and spent four game-years creating a fort that could support my research, then archived the save so I'd be able to try different versions of controllers.
The first effort had some small success. I built a clock, using two of my "standard" catchments. They are built R,G,R,B,b where R are rollers, G is a floodgate and B and b are a bridge that raises to the capital B. Both gate and bridge are connected to the same control, so only one will be open at a time. Pressure plates between the catchments provided the clock signals. These controlled the catchments, and also were connected to alternate doors in a "control loop". This allowed the control cart to move forward one "program step" at a time. On the first step, the cart crosses a pressure plate that sends the "increment" signal. Later, after the incrementation is completed, it checks the route to see if it needs service. If so, the clock is interrupted and the route travels. Otherwise, or when the route is complete, the clock continues, the counter gets incremented, etc.
There are four "bit togglers". These were built like the clock, two catchments in a loop. One pressure plate would set the bit's cart latch (in the "bit register" - the other would reset it AND send the increment signal to the next higher bit.
This is where latency made it clear that I couldn't continue to ignore it. Here is what happens when the increment signal is sent to the zero-bit toggle. A. The signal is sent. B. 100 gs (game steps) later the floodgate opens, admitting the cart into the catchment. C. a bit over 100 gs after that, the floodgate opens and the cart is released to cross the "bit set" plate. That's over 200 gs just to set one bit! Now let's see what happens on the next increment: A. Signal sent to zero bit toggle. B. a bit over 200 gs later the cart resets the zero bit to false and sends the increment signal to the next bit. C. A bit over 200 gs later the second bit is set.
It will take over 800 gs to increment all four bits - and there is no easy way to tell how many bits will need to flip. This design takes about 1000 gs to check each route!
So I took a good hard look at latency - and where it comes from. I had been using the floodgate/bridge combination because it was easy. Switches and plates send two signals, a "set" and a "un-set". Floodgates open on the "set" signal and bridges raise on the "set" signal. However, both have 100 gs of latency. They respond 100 gs AFTER getting the signal. Switches have no latency, neither do gears or doors. Plates send the set signal right away, but don't send the unset signal until 100 gs after the plate is released. Gears are a bit different - they toggle on either the set or unset signal, so they can be "preset" to be "normally engaged" or "normally disengaged".
The easy solution was to move the bit toggle's plates inside the catchments - which cut the increment latency in half. But that's still over 400 gs.
The next design was better. The roller in front of the bridge was connected to a "normally off" gear. When the signal is sent, the engages immediately, sending the cart across the still open bridge and the plate, and is stopped on a roller (constant power) by a floodgate, which opens 100 gs after the inc signal and then is stopped by the now raised bridge. By the time the bridge drops, the rollers aren't getting power anymore, so the cart waits for the next inc signal.
So, now the bit are being set with very low latency - less than 10 gs for the cart to reach the set/unsetplates. All four bits increment in under 40 gs! However, there is still 200 gs before the toggle can be toggled again, so I'm at around 220 gs per route check. That's 3520 gs to check all 16 routes - and a dwarf can walk (unencumbered) about 350 tiles in that amount of time. Still not fast enough.
The next toggler catchment design was R, D, P, R, G, with all rollers powered constantly. The signal comes in and controls only the doors. The door opens, the cart moves across the set/unset plate, then stops at the floodgate - which was driven by the set/unset plate (not the inc signal). In this design, it's important that the signal cart doesn't stay on the inc signal plate very long - it must be less than the time it takes for the toggler cart to reach the set/unset plate. However, it can be toggled every 120 gs or so.
To get the narrow "pulse width" required for the toggler catchments, the signal cart needs to be travelling pretty fast - and I need two signals per route check (one to increment the counter, the other to query the line). It takes a very large loop to get that 120 gs cycle with two alternating signals at 60 gs intervals, so I made a small, low speed loop with 6 plates which drove 60 doors in a "rotary catchment" on the control loop. It worked, and I had a route selector that could check a route every 120 gs.
Now a new problem bit me in the behind. When a device responds to a signal sent by a switch or plate, there is a moment of lag. It's quite noticable on an older system like mine. This design had a signal being sent every 20 gs (for the rotary catchment) and generated between 11 and 20 signals per route! On my computer, that dropped my frame rate down to 2fps.
So, while the system functioned, it was still rather slow (over 1500 gs to check the routes) and created tons of lag - even when no routes were running.
I decided that the 4 bit controller wasn't going to work, and redesigned from scratch. I don't want to give any spoilers on how it works, but the prototype I built (complete with tracks and routes to control) handles four routes, and checks them all in 36 gs without any signal being sent at all. More, the design will scale well, up to over 30 routes i believe, with less than 10 gs per route added. I saw no detectable lag during idle.
The binary counter was smaller and used less parts, so I'll probably use that as a subcontroller for the ammo distribution route (since it only needs to increment once per trip, to ensure even distribution, lag shouldn't be a big problem)
Every component of the system has been tested, including the routing and track switching. Some routes will be "adjustable" and can select from several dumping stops (set with switches).
I have started a new embark, a 3 x 5 with a stream and a volcano at opposite ends of the site. Invasions are on, no cheats, etc. I am using the "Masterwork" mod, including DF Hack (the mechanism browser is a must-have for a project of this complexity) . I'll probably use steam engines to power some of it, but the transport system can be built with just "vanilla" components. It will be a while before I get the system built, and will post a save (and probably an "owner's manual") when I'm ready.
Meanwhile, I'll post from the expedition leader's diary so you can follow the progress.
The system was based on two "nodes" connected by some double track with floodgate/raisingbridge catchments at each end. Each node contained 4 stops, all individually gated, which operated in "pairs" - one stop at each end. A minecart slowly ran around a long track, and once each lap it triggered some catchments in a "control loop" consisting of 4 sections. In each section, a pressure plate would reset the previous lines cart latch and set it's own cart latch, and the cart latches were connected to the stop gates, etc. In effect, one "turn" consisted of four clock cycles, and each route had one opportunity per turn. For instance, when a cart was loaded it would be pushed up to a roller which was in front of a gate. When it's turn came, the stop's gates would open and the cart would be allowed to enter the node, where it would end entering the catchment at it's end of the doubletrack. Next cycle, the catchment completes and the cart makes the trip down the double track. On the third cycle, the cart exits the double track and enters the desired stop. If it's a roll-through dump stop the cart continues to the catchment, and on the third cycle re-enters the doubletrack going home. On the fourth cycle, it returns to it's originating stop.
The problems with that system are plentiful. First - it's slow. The clock has to be slow enough to allow the slowest cart to complete the slowest segment of it's journey - even if no carts are actually running. Carts will spend a lot of time waiting - more time waiting than moving in most cases!
Second, it doesn't scale well. Four routes isn't enough. We could add a pair of catchments to the middle of the double track and put 6 stops on each node, and we can "stack" separate track systems (even run them from the same "controller", but this all takes a lot of space. Space where you'd rather have workshops and stockpiles, etc.
Big, Slow, and Stupid just wasn't going to cut it. I needed something a bit more "on demand".
I started a "research fort", no invasions, added some ores, etc, and spent four game-years creating a fort that could support my research, then archived the save so I'd be able to try different versions of controllers.
The first effort had some small success. I built a clock, using two of my "standard" catchments. They are built R,G,R,B,b where R are rollers, G is a floodgate and B and b are a bridge that raises to the capital B. Both gate and bridge are connected to the same control, so only one will be open at a time. Pressure plates between the catchments provided the clock signals. These controlled the catchments, and also were connected to alternate doors in a "control loop". This allowed the control cart to move forward one "program step" at a time. On the first step, the cart crosses a pressure plate that sends the "increment" signal. Later, after the incrementation is completed, it checks the route to see if it needs service. If so, the clock is interrupted and the route travels. Otherwise, or when the route is complete, the clock continues, the counter gets incremented, etc.
There are four "bit togglers". These were built like the clock, two catchments in a loop. One pressure plate would set the bit's cart latch (in the "bit register" - the other would reset it AND send the increment signal to the next higher bit.
This is where latency made it clear that I couldn't continue to ignore it. Here is what happens when the increment signal is sent to the zero-bit toggle. A. The signal is sent. B. 100 gs (game steps) later the floodgate opens, admitting the cart into the catchment. C. a bit over 100 gs after that, the floodgate opens and the cart is released to cross the "bit set" plate. That's over 200 gs just to set one bit! Now let's see what happens on the next increment: A. Signal sent to zero bit toggle. B. a bit over 200 gs later the cart resets the zero bit to false and sends the increment signal to the next bit. C. A bit over 200 gs later the second bit is set.
It will take over 800 gs to increment all four bits - and there is no easy way to tell how many bits will need to flip. This design takes about 1000 gs to check each route!
So I took a good hard look at latency - and where it comes from. I had been using the floodgate/bridge combination because it was easy. Switches and plates send two signals, a "set" and a "un-set". Floodgates open on the "set" signal and bridges raise on the "set" signal. However, both have 100 gs of latency. They respond 100 gs AFTER getting the signal. Switches have no latency, neither do gears or doors. Plates send the set signal right away, but don't send the unset signal until 100 gs after the plate is released. Gears are a bit different - they toggle on either the set or unset signal, so they can be "preset" to be "normally engaged" or "normally disengaged".
The easy solution was to move the bit toggle's plates inside the catchments - which cut the increment latency in half. But that's still over 400 gs.
The next design was better. The roller in front of the bridge was connected to a "normally off" gear. When the signal is sent, the engages immediately, sending the cart across the still open bridge and the plate, and is stopped on a roller (constant power) by a floodgate, which opens 100 gs after the inc signal and then is stopped by the now raised bridge. By the time the bridge drops, the rollers aren't getting power anymore, so the cart waits for the next inc signal.
So, now the bit are being set with very low latency - less than 10 gs for the cart to reach the set/unsetplates. All four bits increment in under 40 gs! However, there is still 200 gs before the toggle can be toggled again, so I'm at around 220 gs per route check. That's 3520 gs to check all 16 routes - and a dwarf can walk (unencumbered) about 350 tiles in that amount of time. Still not fast enough.
The next toggler catchment design was R, D, P, R, G, with all rollers powered constantly. The signal comes in and controls only the doors. The door opens, the cart moves across the set/unset plate, then stops at the floodgate - which was driven by the set/unset plate (not the inc signal). In this design, it's important that the signal cart doesn't stay on the inc signal plate very long - it must be less than the time it takes for the toggler cart to reach the set/unset plate. However, it can be toggled every 120 gs or so.
To get the narrow "pulse width" required for the toggler catchments, the signal cart needs to be travelling pretty fast - and I need two signals per route check (one to increment the counter, the other to query the line). It takes a very large loop to get that 120 gs cycle with two alternating signals at 60 gs intervals, so I made a small, low speed loop with 6 plates which drove 60 doors in a "rotary catchment" on the control loop. It worked, and I had a route selector that could check a route every 120 gs.
Now a new problem bit me in the behind. When a device responds to a signal sent by a switch or plate, there is a moment of lag. It's quite noticable on an older system like mine. This design had a signal being sent every 20 gs (for the rotary catchment) and generated between 11 and 20 signals per route! On my computer, that dropped my frame rate down to 2fps.
So, while the system functioned, it was still rather slow (over 1500 gs to check the routes) and created tons of lag - even when no routes were running.
I decided that the 4 bit controller wasn't going to work, and redesigned from scratch. I don't want to give any spoilers on how it works, but the prototype I built (complete with tracks and routes to control) handles four routes, and checks them all in 36 gs without any signal being sent at all. More, the design will scale well, up to over 30 routes i believe, with less than 10 gs per route added. I saw no detectable lag during idle.
The binary counter was smaller and used less parts, so I'll probably use that as a subcontroller for the ammo distribution route (since it only needs to increment once per trip, to ensure even distribution, lag shouldn't be a big problem)
Every component of the system has been tested, including the routing and track switching. Some routes will be "adjustable" and can select from several dumping stops (set with switches).
I have started a new embark, a 3 x 5 with a stream and a volcano at opposite ends of the site. Invasions are on, no cheats, etc. I am using the "Masterwork" mod, including DF Hack (the mechanism browser is a must-have for a project of this complexity) . I'll probably use steam engines to power some of it, but the transport system can be built with just "vanilla" components. It will be a while before I get the system built, and will post a save (and probably an "owner's manual") when I'm ready.
Meanwhile, I'll post from the expedition leader's diary so you can follow the progress.
