ItemDelivery – RequesterBase [update 2022-08-08 v12]

Originally shared on the public FactorioPrints / Factorio School archive (factorioprints.com · factorio.school). Authorship preserved from the public catalog.

Description

A system to deliver items by train from a central base to outposts.

see also: ItemDelivery - TestSetup

see also: ItemDelivery - Requester Module "BotLossPrevention"explanation is below.

expressions like "blockR1" are references to the picture and the explanation where you can find a block R1 in the RequesterBase.

a changelog is at the end of the documentation.

tl;dr:
vanilla, no mods needed
for double-headed 2-4-2 trains (single-headed-trains are untested but should be possible)
compatible to LHD & RHD (left hand drive & right hand drive)
intended for lategame basebuilding (like a bootstrap for a bigger base or an outpost)
use a constant combinator for up to 5 sequential requests (more variants possible, easily extendible, details below)
all RequesterBases have the same name (multiple stations are possible, see blockR3 to set station ID and prevent request collisions)
requires green cables along train-network (red cables are optional for this system)
connect green cables via big power poles to train-network

overall features:
system delivers exact quantities of requested items
while loading the full stack-inserter bonus is utilized
no filters in cargo wagons are nessesary (-> easy train setup)
multiple different steps can be configured (i.e. “first the roboports & powerpoles, secondly the chests, then the inserters, at last the rest”)
delivery must be completely removed from passive-provider-chests, before next step is requested
trash is loaded from outposts (i.e. wood & stone) after unloading the delivery
train returns home after delivery
simple train-activity status (see below)
different pulse-based systems are possible as a index (signal-z) is used
system is "immune" to signals without or wrong z-index (permanent signals are problematic)

quick-setup:
build ProviderBase in logistic range of your ME (“make everything”)
- connect green cable from big power pole to train wire network
place and configure train
- set train configuration (see below),
- send train to ProviderBase (to connect it to the station)
build RequesterBase
- connect green cable from the big power pole
set 5 item-requests (requests may be small but NOT empty; see operation variants below)
enable constant combinator in blockR1 (see picture)
watch automation / wait for delivery

additional setup-notes
if using multiple requester stations set different IDs for each one
- increment each ID by at least 10, better 20
- IDs also act as a priority, lower IDs will send their request earlier
- note: sending a request will supress all other requester stations until the first request is fulfilled (blue lamp is turned on in R10)
the train will not unload until you have at least one logistic bot in requester-network
- simply deliver 4 or more logi-bots in your first request.
- if there are no logi-bots present, the long hand inserter will take one from the second wagon directly into the roboport.
- the long hand inserter is only active if there are zero logi-bots
requests can only be made if the passive providers are empty
- this prevents a clogged unload-chests and therefore incomplete deliveries
- the buffer chests act as a limited buffer in case you delivered to much or to send out the request before everything is used up
when the train returns to the provider station it is completely unloaded into active providers
- only after unloading the blue light is turned off to signal readiness for the next request

limitations:
Requests can only be made at RequesterBase – multiple pre-programmed steps are possible
Requests / steps without items are not processed. They just open the station for a delivery that was meant for another station. Avoid this!
Maximum of 40 different stacks (40 unique item-names)
Maximum of 160 stacks (i.e “1600 beacons”)
Conclusion: don’t fill all stacks/wagons when requesting items with small stacksize.
requests with more than 8 unique items cannot be buffered completely
- they must be used up completely at the requester before the next step can be requested
if requests are larger than the train capacity the delivery can be triggered manually (in the train-menu: send to requester station)
- left items are cleaned from provider and unloaded when train returns
collisions of signal-pulses are not handled
- i.e. if multiple signals are sent during the same tick, or if a permanent signal is on the train-network
- non-item-signals (like signal-red) cannot be loaded on a train and therefore block the departure
- signals used in the request pulses are filterd out before determining the load

train configuration:
sender-station: circuit signal G > 0 AND 5 seconds of inactivity (set conditions in this order!)
requester-station: 5 seconds of inactivity

operation variants:
deliver 5 batches of items – just set your requests in blockR2 from right to left and then enable the combinator in blockR1
deliver less than 5 batches of items – set your requests in blockR2
- remove the constant combinators you don’t need
- leave the left combinantor; match the left decider combinator (and lamp) to your number of steps
- the left combinator sends out -1 signal-w and -753 signal-z to negate the enable combinator in R1
deliver more than 5 batches of items – extend blockR2
- increment the comparator to signal-S in the same way as the other decider combinators,
- set the number of steps / request-batches in the lowest combinator of blockR7
- the last step should always send -1 signal-w and -753 signal-z to negate the enable combinator in R1
deliver repeatedly different batches – set the number of steps decreased by 1 in the lowest combinator of blockR7
- since there is no "last step" no combinator is needed to cancel the enable combinator in R1
- depending on what you deliver the repetition may stop if the last request cannot be unloaded
Note: the lamps use the same number as the respective decider combinator of the same column in blockR2
Note: counting of steps starts at 0 – so the comparison “smaller than” (blockR7) will lead to the specified results

train activity status: (of RequesterBase)
one red light – train is inactive, ready to receive request (default status)
red light & blue light – train is active somewhere else
yellow light & blue light – a request by this station has been sent and is loaded onto the train
yellow, blue & green light – the train (with the delivery) is on its way to this station

Detailed block-description of RequesterBase: Picture

(ProviderBase below)

On-Off-Switch.

Is off when blueprint is built. Switch on when you are ready to request.
Only switch on when you have successfully connected the station to your track-network.
Connect via green cable to big electric poles.

Request-stack:

each column ends with a constant combinator that contains the items to request.
Max. 160 stacks
Max. 40 unique stacks
Combinators are permanently “on”.
Each column is requested separately from right to left.
Steps are checked via signal-S. Counting starts at 0.
Expand the blockR by incrementing signal-S in lamps and decider-combinators. Also increase lowest combinator in blockR7.
To disable the station after the last step, make the last combinator send signal-W=-1 and signal-Z=-753. This effectively disables the timer (blockR3).
Do not litter your request with virtual signals. The signal-4 and signal-2 that can be seen in the example have the value 0. Requests for virtual signals cannot be loaded to the train and will prevent departure of the train from the delivery-station.

Delay-Timer:

if conditions 2, 3 and 4 (from blockR4) are met (signal-W=3) the timer starts to count in ticks.
If the timer has run down signal-W=3 is piped through.
The delay also acts a Station ID. Duplicate values for the timer could result in conflicting requests if you are using multiple requester-stations. Do not use duplicate IDs.
IDs / the delay should be incremented in multiples of 10.
Use the constant combinator to set the value.

Check if all request-conditions are met:

each true condition sends a W=1.

All passive provider chests are empty
Train is ready / blue light is off
Train-station is currently closed / yellow light is off
Station is enabled (see blockR1).

If W=4 all signals are piped through. Also see blockR2.

remove internal signals:

before sending the current request-step to the main-network the internal signal signal-W and signal-S are removed.
The system index signal-Z=753 is kept.

load-unload-controller:

counts content of incoming train
Unloading-inserters are active when train is present and train has cargo.
Unloading-inserters decrease initial cargo-count and are disabled when initial cargo-count reaches zero.
Loading-inserters are disabled until train is present and initial cargo-count reaches zero.
The constant combinator in the lower right is “off”. Turn it on and off again to reset the steps of the request stack (also see blockR2 and blockR7).

step-counter:

each time a train enters the station the step-counter in incremented by 1.
The lowest decider combinator holds the reset-condition for the step-counter.
If you want to request in ever-repeating cycles, then set the lowest decider combinator to “signal-S [smaller than] 5” (value in blueprint is 6).
Remember: counting starts at 0.
Remember: items are only requested when passive provider-chests are empty.
Note: empty steps do not request an empty train and lead to an “unclean state” of the station, because the timer in blockR3 keeps running.

detect present train

After 350 ticks after the train entered the station the signal-R will be sent to blockR9. This will reset the signal-L in the memory-cell and disable the train stop.

enable and disable train stop:

when a request is sent, it will be accommodated by the signal-Z=753
If signal-Z is detected signal-L will be saved in a SR-latch.
As long as signal-L equals 1 the yellow lamp will light up (also see blockR2).
If the yellow lamp is on, the train stop is enabled.
If signal-Z is detected and signal-blue is smaller than 1 the signal is sent to the delivery-station.

network interface and status-counter:

Upper left arithmetic combinator is the connection to the public network.
Other combinators count how often the signal-Z=753 is sent and will therefore show the readiness of the train.
Requests will only be sent if the blue light is off (signal-blue=0).

Detailed block-description of ProviderBase: Picture

Input-Filter:

blocks everything without correct signal-Z-index (=753)
subtracts signal-U which is sent, when the train leaves the ProviderBase (activates green light in RequesterBase)
subtracts signal-V which is sent, when the train signals completion of return & unload

Request memory-cell:

saves incoming request for later comparison
memory is wiped, when signal-black=1 (signal-black comes from blockP7)

requester & separator:

requests and separates exact amounts
separate copy of the partitial request is saved in a additional memory-cell. this copy sets the request of the requester-chest
the lower vertical inserter subtracts grabbed content from memory-cell (it grabs the full stack-size)
if subtraction in memory-cell results in a negative value, the negative value is multiplied with -1 (to make it positive) and outputted as signal-I'. this signal-I' is used to set the stack-override-value in the upper vertical inserter, which removes items from the cycle into an active provider chest.
note: it is necessary to limit the steel-chest to 1 stack, if something backs up, calculations will still make correct values of signal-I'.
the remaining items are grabbed by the horizontal inserter and are moved to the train.
the next downward-facing inserter counts all items it grabbed, to disable the unloaders (i.e. blockP9)
memory-cells ware wiped when signal-black is sent

wagon separator:

divides initial request by four and distributes to instances of P3.
initial request is divided by two, integer division excess (modulo) is added to one set of results
then both ammounts are divided by two again, modulo is added again to one set of results
blockP4' to blockP4''', make those calculations
several arithmetic combinators calculate "+0" to maintain tick-synchronicity

train-load-counter:

reads train and compares current load with request
signal-L is only sent when memory-cells are empty to prevent instant departure (before a new request is recieved)
current load is multiplied by -1, signals are piped through if signal-L=0
filters out the train-ID (signal-T)

go-pulse-generator:

if request minus train-content = 0 then signal-o
signals of negative train-content and request-memory-cell are combined in a decider combinator output signal-G=1
signal-G=1 is made to a pulse and sent to the train (which is the first wait-condition)

several readychecks:

fulfillment of each of those questions increases signal-R by 1

is the signal-L=0? (has the signal-black been sent to wipe the memory-cells from the previous request)
is the train present? (read train-ID as signal-T; is signal-T greater than 1)
is the train-content=0? (trash unload complete; read train without signal-T)

signal-R=3 is required to send the pulse witz signal-V to the RequesterBase (turns off blue light, resets ID-counter)

the track-signal-interface: detects the leaving and incoming train.

rail-signals send custom signals (open interface to inspect)
a leaving train pulses signal-white with signal-Z=753 (second signal for the RequesterBase to switch on green light)
a leaving train also sends signal-black into the ProviderBase to wipe the memory-cells
chain-signals could have been used since .16

trash unloaders: pairs of stack-inserters unload into active providers (for every wagon).

are only active if memory-cells are empty (memory-cells are cleared when train leaves, before next request is received)

Low-level-debugging:
since the update 2018-10-12 all ID- / Delay-counter and requester stations are reset, when the train completely unloads in the provider station
- so to reset a faulty state, simply return the train to the provider station
- if the train is inside the provider station, manually drive it out of the provider station and drive it back in.
In all other error-cases it should be sufficient to turn on the "step-reset"-combinator (r7) for a short time. turn it off afterwards.

** changelog: **
2018-08-07 (v02):
added some wires to reset whole station from "step-reset"-combinator in r7
2018-09-13 (v08):
ProviderBase: now all wagons are loaded simultaneously.
ProviderBase: cleaned up wiring
more resilient status: when the train returns to the providerbase all requesters are reset
2018-10-12 (v09):
updated and clarified documentation
returning and completely unloading the train in the provider station will send a special signal to:
1. close all requester stations (yellow light off).
2. reset the blue status in all requester stations.
3. reset all request timers simultaneously (request timer = ID).
old versions of providers & requesters should be updated, as they do not process the new reset-signal.
- updates can be "printed over" and do not require complete reassembly of the requester station
- updates only require one additional arithmetic- and decider-combinator per requester
2019-01-26 (v10):
doubled loading speed of ProviderBase
- Requesters are compatible. No update needed.
added possibility to add specialized modues to a certain RequesterBase
- emergency buildBot requester (see here)
- buildup blocker for higher IDs (see here)
2020-09-15 (v11):
cleaned up wires
added request fulfillment indicator to ProviderBase
2022-08-18 (v12)
resilience: if a second request is received before the current request is delivered, a global reset signal is sent te reinitialize all timers.
- steps in Requesters are not changed and will be sent again.
- The reset signal unloads the current train
- Old Requesters are compatible (up to v09).
added short explanation in Blueprint