Logistics Cache

[zebediah49]

I have previously suggested a logistics chest that sits between red and blue: it would try to fill its inventory from red and purple chests, but would be willing to give it up if a blue chest asked. This could be used to cache resources near request locations, improving response times (the robot initially responding to the request would quickly get it from the nearby cache, triggering a request for the long trip to refill cache). It's unnecessary for normal transport use, but would be very handy for burst demands such as construction and players.

So, I emulated one.

Workspace 1_057.png (147.99 KiB) Viewed 1303 times

Program your item request in the combinator on the right; the system will attempt to keep at least half that much in stock. The only real flaw is that two of these contraptions will potentially pull from each other, if they are closer to each other than to the primary source of items.

Blueprint String

H4sIAAAAAAAA/71WYW+bMBD9KxUfJ9gwXdpVlSfld1QTcvElnGZsZpuoEeK/z4a2QBIIiZTmCwn2nd+9984Xru6Eypi4S2kN0qJFMLSuJSuABkyjzQuwmEWZ
Kl5RMqt0EJbKuH1K0vqNRkm4pxH5vmpCjhqy9v3PMFPSaiXSV8jZDpWmdZ8rdYu8TeBO2qA2NjW4lUzQ2u5Ld+wOta2YCMIORbcYAcvyoAkN+PBFEWu3XZWg
WQsq+BaEqrJldclxTeNLkV1dDu5LQII/tNbAHUktX/sUuS8YdVah9T+SJhwskdjl2GoAOYq4H0e4PS9Bcir1Q+M/4bsiBXCsigiEQ6SdLKUScCAI8YIkfcgC
EeNPDW+nmws2lknrAX6NKI8zrI4EIycVIuMtQ02fRppwyJCDnmSXzLD7HnsltUzubY5yO6Q3dl+LkmmPgwa/L6J33SYq9w5OJW260apIUbpoumHCwELe76eb
YbXU9QfkD+le4OfkK/2cDO3843Z2frrAzgO6hNqiacnKwdhIw7/KPeHUNR6f4usjcaE4pGqT9sWSZbjJoeY9NocDRAfs+EKKr3DbuE1/jS9icnA2y/5GKA3o
YzZId34/0R5mmPm00SUuWk/3LPVLk6z39WpgPM2ZG4YemyvUUKsr+Fxvl9pNPstSuR5HLH1AnG21+Nzs36BwHPv/FWNq0ELxwQtqJaNSMAstM5XvrDgOUXJ4
a3WdDu2moZLe5F3tJ1IkS/tsdX40HA3vZbbyriZzPXYDJ13Ro7P3R8mMwR1EpVY7P7mOK0wu8VkTYtbumpF38gZrFrnjXAHNwCDPGmyl5V36DJL/B+yrxpYb
CwAA

Theory of Operation

The fundamental problem here is that to request from the network, you need a blue chest, and to provide to the network you need a red/yellow chest. The blue chest will immediately pull from the red/yellow though. This is worked around by using an intermediate chest, and a mode-based system. In "refill" mode, it will necessarily drain the red chest into the blue, so we want to minimize this process. Numbered from the left --

• Constant combinator specifies the requested list of items.
• Combinator 4: Input is the list; divide that list by two to get the minimum threshold. This is an arbitrary choice, but I wanted to minimize refill rate.
• Combinator 2: Input is the sum of items in-inserter, steel chest, and provider chest; multiplies by -1. This effects subtraction when the output is added later.
• Combinator 3: Input is combinator4+combinator2 == (request/2 - current). If anything is greater than 0, we're low and need to restock. Output 'A=1' to signal this.
• Combinator 1: Input is the request_amount+combinator4 + combinator3. This is equal to (request - current), as well as 'A' to check mode. We multiply everything by 'A', to act as a switch. In other words, when 'A' is 1, we request the items we're missing.
• The bottom inserter is set to enabled when A==0.

The result is that there is no request unless something is below half-full, in which A is set to 1. This disables refilling of the red chest; items will be transferred from both the red chest and the rest of the network, into the blue chest. Once the request has been responded to (total items has increased over the 1/2 mark), the 'A' signal goes off, the request turns off, and the inserter moves the items down into the provider chest. Note that the request technically stops as soon as more items arrive, but the travel time means that if you have enough bots, the whole request will be en-route when the request goes away, and will still get delivered.