I'll basically copy&paste what I've written in the
Assembling machines and signals Thread (since I don't know if everyone interested in the topic looks over there):
[...]
- Items that cannot be used for the current recipe are moved to an internal residual item buffer
- Output (Filter) Inserters can take items from that residual items buffer
- Input Inserters can only input resource items from the current recipe.
I think we can all agree that this is what it might work like.
But if you always have to wait for residual items to be completely removed before you can start crafting the new recipe one is actually delaying things artificially and increasing the overhead, decreasing overall crafting throughput considerably if you always have to wait for the slow inserters to output everything.
I mean as I see it... the Assembler could already start working on the new recipe after moving the unusable items to the residual item output buffer and once the actually required resources are inside the assembler. The residual items can still be removed from the buffer in the background at the same time.
So I thought about how it could work similar to how CPU pipelining works, just with a 3-stage assembly pipeline instead or so:
- Pipeline.png (8.01 KiB) Viewed 4479 times
In each step the Assembler would do following:
- Recipe Resource Fetch: Look at current Recipe signal and allow input inserters to prefetch necessary resource items (if they are not already inside the buffer)
- Recipe Crafting Execute: Start Crafting the recipe once all required resources are inside
- Items & Residuals Output: Output finished items. Output mismatching residuals if new recipe signal mismatches old recipe. (Basically your Write Back for those who are into CPUs)
The output can be handled by 2 different inserters... one that handles the output of finished items and one that handles the output of residual items.
This way one can make it so that there is always a limited "internal cache" for resource items... and as long as one is switching between the same 2-3 simple recipes or something there would never be residual items to be removed because they fit into the cache. But if you switch between more complex recipes or a lot of simple recipes then the cache will overflow and the oldest (least used) resources will be moved to the residual item output for pickup. And the assembler will only stall if you don't remove the residuals fast enough filling up the residual item output.
That would increase the overall throughput for simple recipes because the penalty of switching the recipe is largely mitigated.
I came up with that because with all the suggestions of "taking out residuals" almost nobody ever thought about how inefficient the throughput gets if the assembler always stalls waiting for removal of items. It becomes way too ugly that the machine spends more time waiting for item removal/insertion than it actually does pure crafting... It becomes so inefficient that it is not worth going for in comparison to dedicating machines to specific recipes.
So my above suggestion of pipelining the input/crafting/output is might actually be necessary to increase the efficiency of the entire "Set recipes"/"Smart Assembly" concept.
I continued to made a rough mockup of how I think that it might actually "work" with being able to switch the recipe at any given point without any performance loss within a certain "window":
- Assembler Flow.png (17.87 KiB) Viewed 4479 times
Basically this is how it would work:
- So basically you set the recipe by signal, which then tells which items are "allowed" to be input into the internal Resource Cache.
- Once all required resource items are inside the Resource cache the recipe starts crafting.
- Finished items are moved to the Finished Item Output buffer. An Inserter can pick the stuff up from here.
- If Recipe Switch happens then the requirements of the new recipe are compared with what is already inside the cache.
- If it turns out that the resources for the new recipe don't fully fit into the cache (= "Cache Overflow", since there may still be other mismatching items) then it proceeds to dump one mismatching resource item after another to the residual Item Output buffer until there is enough space. It could begin by dumping the "oldest" resource that hasn't been used recently to the youngest.
- From the Residual Output buffer the inserters can grab the items that aren't needed anymore.
So basically the assembler could go on with crafting the new recipe (given that the resource items are already in place in the cache) without waiting for the residual items to be removed first. It would only start dumping residuals if there's not enough space in the cache, so it will not happen with every resource item on every recipe switch (except if all 6 resource items of the new and old recipe mismatch). The only time when the assembler would stall is either one of the following three cases:
- Output buffer for finished items is full.
- Cache is empty because you didn't deliver enough resources to the assembler.
- Output buffer for residuals is full while a recipe switch requires dumping additional residuals since the Resource Cache is also full.
There would still be a circuit signal necessary to tell the output inserters that there are resdiuals or finished items for pickup. Don't know if a single signal outputting either the finished items or the residual items would be sufficient, but at least one is absolutely necessary to tell the residuals from the finished items apart. Maybe both could be provided: Finished Items would have a positive circuit signal, Residual items have a negative signal. Then you could use "Each > 0" for finished items and "Each < 0" for residual items... that way one would be able to even have several finished items for output (important for mods maybe).
The amount of Cache/Buffer Slots is up for debate of course, but I'd say the 6 slot variant is a solid foundation to work with.
So how I see it, it would be possible to store the resources for up to 6 "single-resource" recipes in the cache and switch between those 6 recipes before it would become necessary to dump something into the residual item output buffer. That in turn increases the uptime of the assembler significantly. Maybe a stall doesn't even happen at all because you get a lot of time to remove the residuals.
That in turn makes it possible to use it even with belts that may have huge delays in item delivery/export, though maybe still not as effective as bots would be of course.
.