Only required items on belts

Don't know how to use a machine? Looking for efficient setups? Stuck in a mission?
Post Reply
r3make
Burner Inserter
Burner Inserter
Posts: 6
Joined: Sat Mar 26, 2016 9:21 am
Contact:

Only required items on belts

Post by r3make »

Hi,
i really like factory designs using a single belt for multiple types of items. Yet, all designs i have seen put more items on a belt than necessary, which requires manual fine tuning to avoid one type of item blocking the belt.
Ideally, i would like to have exactly as many items on a belt as are required. This would also allow belts to not be cyclic.

I'm not sure yet, if that is possible to achieve with the features the game provides right now. However, i would like to share my ideas on the topic and would like to hear your oppinion and ideas on how to proceed.

My design assumes that there are smart chests per item type, producer, and consumer. I will refer to a chest providing items as source, and a chest used as immediate input to an assembling machine as sink. Each sink has a buffer of say 10 items. Sources and sinks are connected via belts and the belts should never contain more items than are missing in the sink to fill up the buffer.
Image
Now, each time some item is taken from a sink chest we will decrement some counter. If this counter is negative, then items from the source are taken and placed on the belt. Each time an item is taken from a source, the same counter is incremented. This ensures that there are never items on the belt that are not required at some sink.
The problem is that in the current state of the game an inserter will not output a signal that we can use to know that something was taken or put into a chest.

We can approximate this missing feature via the following circuit (also implemented in the factory prototype shown in the image above):
Image
In this schematic view of the circuit, i visualized combinators via circles. Inputs are always on the left and outputs on the right. The empty circle represents a combinator that simply outputs its input. They are used to delay a signal such that in the next combinator we can catch differences of the chest's storage count. The last combinator (A+B) represents the counter. If the counter's value is negative, a smart inserter is activated that takes items from the source chest.

This circuit works in theory, but has one practical problem. If an item is put into a source chest and another item is taken from the chest at the same time we will not observe a difference and therefore not update the counter. Nevertheless, an item was placed on the belt.
I have not yet figured out how to avoid these cases, but thought about using a clock. On a high clock value inserters putting items to a chest are activated, on a low clock value inserters taking items are activated. I guess this should avoid that items are taken and put to a chest at the same time. Unfortunately, this increases the complexity of the factory design a lot.

Glad to hear your oppinion, ideas, and feedback.

r3make
Burner Inserter
Burner Inserter
Posts: 6
Joined: Sat Mar 26, 2016 9:21 am
Contact:

Re: Only required items on belts

Post by r3make »

Ok, i tried the clock idea: it works, but you have to activate all inserters at the same time.
Video of the prototype in action

DevilXD
Fast Inserter
Fast Inserter
Posts: 213
Joined: Tue Aug 12, 2014 10:47 am
Contact:

Re: Only required items on belts

Post by DevilXD »

This system seemed awesome, until I saw how many combinators you had for just two assembling machines...

I found this on reddit, seems to work similar and simpler: https://www.reddit.com/r/factorio/comme ... 2_example/

Good work though =)

XKnight
Filter Inserter
Filter Inserter
Posts: 329
Joined: Thu May 28, 2015 10:40 pm
Contact:

Re: Only required items on belts

Post by XKnight »

I want to notice several things:
- The main disadvantage I see right now is an incredible big space overheads (although it can be avoided)
- You won't be able to avoid cyclic belt, because in some situations your smart inserters will be incapable to get all items from belt, especially if they are going closely
- To prevent belt jamming you will need some smart controller over this system, otherwise the entire belt will be completely filled with low-tier materials (ores, plates, etc) and nothing will be taken or placed on the belt
- This system requires bigger time to produce first required item, because main cycle is much bigger than direct item flow
- Additional problems will appear when you build second belt loop (to increase throughput)

and advantages:
- Flexibility. Incredible flexibility. You will be able to completely change your output production ratio in a several minutes.
- It is robot-free. Some people (so am I) might say that "use robots to create everything you need" sounds like cheating.
- It is fun. And this is the most important.

Also, I want to say that you idea is not new, but your post inspired me to think in this direction.
Last edited by XKnight on Mon Mar 28, 2016 9:36 pm, edited 2 times in total.

r3make
Burner Inserter
Burner Inserter
Posts: 6
Joined: Sat Mar 26, 2016 9:21 am
Contact:

Re: Only required items on belts

Post by r3make »

DevilXD wrote:This system seemed awesome, until I saw how many combinators you had for just two assembling machines...
I agree, it is far from being of practical use in larger factories without spending hours of wiring things. Actually, it is not as bad as it seems, because the combinators you see are required per item type, not per assembling machine. All sources and sinks for a single item type can share the same combinators (i do it already in the video for metal plates). What is much more complex is getting the wires right: my current approach uses 3 data buses. One for sources, one for sinks, and one to output commands for the inserters. Having a third color of wires would help a lot here ;-)


I have seen the design you link to before. I think it is a clever set up that is more easily achieved, yet it puts lots of items on the belt that are not used in the near future. It also seems to be balanced very clever, such that no single item type blocks the whole belt. Neverthless, i guess this will become very hard to balance if you would include metal and copper plates on the main belt.

I chose to put this discussion in the help forum and not the 'showcase', because i see my current approach not as a solution nor a practical design. It was more about sharing an idea and potentially getting hints in how this could be done better, and more practical.

r3make
Burner Inserter
Burner Inserter
Posts: 6
Joined: Sat Mar 26, 2016 9:21 am
Contact:

Re: Only required items on belts

Post by r3make »

XKnight wrote: - You won't be able to avoid cyclic belt, because in some situations you smart inserters will be incapable to get all items from belt, especially if they are going closely
That's true if ressources are placed onto the belt faster than they can be taken. In the video showing my prototype the inserters placing items on the belt are as fast as the inserters taking from it. This effectively avoids the problem, but results in a very low throughput.
XKnight wrote: - To prevent belt jamming you will need some smart controller over this system, otherwise the entire belt will be completely filled with low-tier materials (ores, plates, etc) and nothing will be taken or placed on the belt
Well, you are describing my goal exactly: do not place unnecessary items on the belt. The proposed circuit is that "smart controller" that avoids putting any item on the belt that will not be taken immediately.

XKnight
Filter Inserter
Filter Inserter
Posts: 329
Joined: Thu May 28, 2015 10:40 pm
Contact:

Re: Only required items on belts

Post by XKnight »

r3make wrote:
XKnight wrote: - You won't be able to avoid cyclic belt, because in some situations you smart inserters will be incapable to get all items from belt, especially if they are going closely
That's true if ressources are placed onto the belt faster than they can be taken. In the video showing my prototype the inserters placing items on the belt are as fast as the inserters taking from it. This effectively avoids the problem, but results in a very low throughput.
XKnight wrote: - To prevent belt jamming you will need some smart controller over this system, otherwise the entire belt will be completely filled with low-tier materials (ores, plates, etc) and nothing will be taken or placed on the belt
Well, you are describing my goal exactly: do not place unnecessary items on the belt. The proposed circuit is that "smart controller" that avoids putting any item on the belt that will not be taken immediately.
So, will you continue working on non-closed loop? Because it is clear for me, that this approach has the lowest throughput you can imagine, and it requires to have the same amount of smart inserters in every source and sink (per item type).

r3make
Burner Inserter
Burner Inserter
Posts: 6
Joined: Sat Mar 26, 2016 9:21 am
Contact:

Re: Only required items on belts

Post by r3make »

Yes.

Throughput in the current design is limited by two things:
1) More ressources are taken from the belt than are put on it.
2) Assembly machines run out of items, because it takes too much time for an item to be moved from a source to a sink.


I think 1) can be solved by having as many inserters putting items to a belt as are taking from it (assuming each inserter is moving 1 item at a time, which is not true if stacking is researched). The circuit should be the same, no matter how many source chests and sink chests there are, hence it is possible to scale this arbitrarily. Unfortunately, this will require quite a lot of space as all items have to be routed through smart chests.

2) is solved easily: just increase the number of items buffered in the chest before an assembly machine. As soon as the first item is taken from the chest, some inserter at a source will place the missing item on the belt. Same process continous for the second item, etc. If the buffer is large enough such that the first item will arrive at the sink before the buffer is empty, it is guaranteed that the assembly machine always has enough items to continue working (assuming the source can always provide enough items).


In practice, an inserter moving stacks of items can produce problems for 1): assume one inserter takes 3 items at once from a sink chest and puts it into an assembly machine. If now three inserters at sources place the missing items at the same time on the belt, the items may be too close to each other to be picked up at the sink, at which only a single smart inserter is operating. I'm not yet sure, how and if this can be avoided. Falling back to a looping belt solves this issue, but will increase problem 2) as items will travel longer.

XKnight
Filter Inserter
Filter Inserter
Posts: 329
Joined: Thu May 28, 2015 10:40 pm
Contact:

Re: Only required items on belts

Post by XKnight »

Perhaps I missed something...

Lets take a look on some virtual factory:
You have 1 producer (metal plates; 1 inserter) and 2 consumers (gears and regular magazine; 1 inserter each), also five minutes before you survived an extremely huge biters wave. At this moment of time you need to quickly recover you magazines, you even can sacrifice your gears because factory defense is more important.

Obvious solution is to disable gear production and enable magazine, but if your inserters are managed at the same time from the same wire it becomes impossible to do.

How will you deal with it?

r3make
Burner Inserter
Burner Inserter
Posts: 6
Joined: Sat Mar 26, 2016 9:21 am
Contact:

Re: Only required items on belts

Post by r3make »

You can deactivate inserters as you normally would. So if you want to prioritize magazine production, just deactivate the inserter taking metal plates from the sink chest to fill the assembly machine for gear production.
Unfortunately, this will require a combinator, because that inserter is already activated/deactivated by a clock interval. Hence, the clock has to be combined with the prioritizing signal.

Maybe you have overlooked (because i never talked about it nor included it in my schematic illustration) that inserters filling the sink chest are only taking items from the belt if the chest's content is below the desired buffer size.

I guess i should draw another schematic picture showing the complete setup. Would be nice to have a good circuit drawing tool for factorio ;-)

XKnight
Filter Inserter
Filter Inserter
Posts: 329
Joined: Thu May 28, 2015 10:40 pm
Contact:

Re: Only required items on belts

Post by XKnight »

Recently I was a little bit busy with several crazy ideas, but I promised myself to turn back to this topic...

Main idea remains the same - "only required items on belts", but with several important changes:
- Belt is closed. This is very important, because using closed belt allows to have variable amount of inserters per recipe.
- As small as possible space-overhead. (Someone might say that space is the cheapest resource, but I don't think so).
- Highest flexibility.

The core component of this build is an item counter-requester (1 comb per 2-smart inserterters + 2 comb for counter). It guarantees that specified amount of items will be taken from one belt and placed on the other belt, even if output belt is jammed or input belt is empty; also it allows to get current status (how many items are waiting).
3.png
3.png (164.32 KiB) Viewed 5449 times
At the beginning, I tried to count items that are taken on and off the belt. This approach gives very accurate results, but it requires significantly more smart-inserters so it was thrown away (because almost all recipes consume more items than produce, and they have different type).

Better results were achieved when we count only items that were requested by the belt.
In this approach three unwanted situations may happen:
- Producer: iron plates. Consumers: gears and regular magazines.
Iron plates might be consumed by gear assembler when we've requested a magazine. Solution for this problem is obvious: all assemblers by default should reach upper limit of output items, so they won't accept any other item from the belt.

- Unfortunately, this solution introduces next problem*
1. Gear assembler (0 iron plates and 3 gears inside). Empty belt.
2. One gear was requested from the system and 2 plates were placed on the belt.
3. Gear assembler (0 iron plates and 2 gears inside). 2 iron plates on the belt.
4. Inserter won't put these iron plates into the assembler until output storage reaches lower limit.
As a result these plates will be spinning on the belt for a long time reducing its capacity.
Good news, that this overhead is small and it can be predicted.

- Last but not least problem is a factory management.
Imagine next situation: we have one gear assembler, one magazine assembler and 4 iron plates inserters, also, we've requested 1000 gears from the belt.
After some time, the entire belt will be completely filled with iron plates, because they are consumed with lower speed than produced and there is no space on the belt to put new gear. System is stuck.
Manual solution for this problem is quite simple: do not request more items than system can produce in a given time. Instead of requesting 1000 gears we can request 10 gears 100 times with some delay between these requests. Obviously, this system will not stuck until amount of requested items is lower than belt capacity, also it has the same productivity.
At the same time, ideal solution which can dynamically balance workload for different assemblers is quite complicated task which requires complex combinator system or even CPU.

Experimental factory:
1.png
1.png (932.17 KiB) Viewed 5449 times
The most noticeable difference between this system and passive loop is a lack of smart inserters which takes items from the belt.
In this system only two items can be taken from the belt - red and green science pack.

Here how it looks our order request:
2.png
2.png (36.57 KiB) Viewed 5449 times
This is an unfolded productivity chain for 10 red and 10 green science packs.
Productivity chain
Using this order request we can calculate assembler workload:
Red science pack = 10 * 5 = 50 sec.
Green science pack = 10 * 6 = 60 sec.
[Other assemblers are very fast]
Finally, we have knowledge about this system productivity, and amount of time which is needed to perform our request. So we should send this signal into the network once per 60*60 = 3600 ticks.
Experimental factory is running
Notes:
I am pretty sure that nobody actually transfers copper cables on the belt, but I did it to make sure that this system works.
Also, it is inefficiently to use this system for producing gears, electronic circuits, and several other items with low production time.

Post Reply

Return to “Gameplay Help”