Factorio Forums

Posted: **Sun Nov 13, 2016 1:03 am**

So I've started some research into working with belts in my circuit creations.

Along the way I noticed that the output of a belt in "Read contents" and "Hold" mode is not what I expected. I was hoping that on a full belt the value read would be constant, it is not.

I made a little demo video:
https://youtu.be/oaK14hhPco8

Basically, the combined output of 9 belt tiles gives a more stable output. When completely full the output is a constant 64 value signal. Which then can be used to trigger other things (more posts coming soon).

Posted: **Sun Nov 13, 2016 2:07 am**

Contraption #1: Rail Signal Like behavior for belts.

My first step into making a circuit controlled belt system.

The conveyor belt system in Factorio is hard to beat in it's efficiency at controlling supply VS demand. Belts are basically a circuit network of their own. Not only they move items forward but they also "transmit" information backwards about what's happening down the line.

The one thing is that item types need to be kept separate. Mixed belts quickly become unmanageable. So I kept thinking that there most be a better way.

I took some inspiration from the train system. Imagine a long segment of material on a belt as a train on a railway. Would be awesome to implement a Rail Signal like contraption which could keep different material segments from "crashing" into each other.

It turns out it's completely possible to implement with the circuit system

:
https://youtu.be/uPNlVszLqHw

This is great for various reasons:

Keep materials separate on same belt line
The gap between material packets can be used as trigger for the circuit system to do something
Looks cool

This is the basis for more complex contraptions involving belts. Contraptions which can now work with material packets, instead of working with individual items, opens a whole new set of possibilities.

Posted: **Sun Nov 13, 2016 2:28 am**

memory cells are also good for keeping track/controlling what and how much of something is on a belt.

Posted: **Sun Nov 13, 2016 2:40 am**

impetus maximus wrote:memory cells are also good for keeping track/controlling what and how much of something is on a belt.

Yeah that's another option.

I wanted a combinator free solution. Otherwise each segment of 10~11 tile belt would need a set of combinators. My solution only requires some green wire.

The other issue is that combinators require power. So a power blackout would be a disaster with a factory full of circuit controlled belts. Belts require no power (event circuit controlled ones).

Posted: **Sun Nov 13, 2016 2:45 am**

the memory cell keeps count from the inserters.

Posted: **Sun Nov 13, 2016 3:17 am**

impetus maximus wrote:the memory cell keeps count from the inserters.

A solution based on counts of items on belts is not what I'm looking for here.

That's a "whole belt" kinda solution. I'm looking for finer grained control of what actually happens on the belt. Like for example:

Contraption #3: 4-to-1 Belt Multiplexer
https://youtu.be/nuUUmRCJcZY

Now this is the kind of thing I'm aiming for. Still needs some optimization (it's too big). But it works quite well. The materials are always kept in separate packets. If the line is stopped at the end the entire contraption halts, and when line starts moving it gracefully resumes work.

Posted: **Sun Nov 13, 2016 9:32 am**

Looking forward to see what's coming next.

BTW: this is why 9 belt tiles always gives a cosistent (integer) number — every straight belt have 32 slots per lane for items and every items take exactly 9 slots, so the full lane of the belt segment holds 3.555... items. But cicrcuit network can operate with integers only so it flickers between 3 and 4 (or 6 and 8 for two lanes). Taking data from 9 belt segments eliminates this problem because it will always give an integer as output = no flickering.

Posted: **Sun Nov 13, 2016 10:16 am**

Multiplexer is nice and so far have trouble replicating it (logic selecting one belt from two). Can you post some infor on how to set combinators?

Also multiplexer is useless without demultiplexer. But using splitter I don't know how are you going to do it. Splitter from 2 to 1 lane has not used lane filled with items so no items are lost in splitter. But that can't be done with splitter from 1 to 2 lanes because both outputs are used and everytime some item type would come through some items will be send to wrong belt and stuck in splitter entity. Unleas you use some incredible logic that merges remaining items stuck in splitter back into the one packet.

Posted: **Mon Nov 14, 2016 2:41 am**

Improved multiplexer design:
https://youtu.be/bvWIbD--KnU

Much more compact now.

Atria wrote:Multiplexer is nice and so far have trouble replicating it (logic selecting one belt from two). Can you post some infor on how to set combinators?
Sure thing. The idea is to have a memory to remember the last material type that was sent to output and then decide what material to send next.

Settings for all the combiners of the improved design:
http://imgur.com/a/myCBk

Atria wrote:Also multiplexer is useless without demultiplexer. But using splitter I don't know how are you going to do it. Splitter from 2 to 1 lane has not used lane filled with items so no items are lost in splitter. But that can't be done with splitter from 1 to 2 lanes because both outputs are used and everytime some item type would come through some items will be send to wrong belt and stuck in splitter entity. Unleas you use some incredible logic that merges remaining items stuck in splitter back into the one packet.

Yeah, that's a bit of an issue. But I think I have a solution.

Simply hold back the previous packet at the output of the splitter, blocking output from that lane. Manual testing seems to show it works with a single splitter. Two splitters stacked (4-to-1 demux) is a bit of a challenge, not only does the final output splitters need to have their lanes blocked, but also the intermediate splitter as well. It's doable, but making the circuit to control it will be a challenge.

Posted: **Mon Nov 14, 2016 10:52 am**

Thank you very much for combinators setting.

In the end I managed to make the circuit network that worked and it was more compact than your first solution with advantage that it could take any type of item instead of preset ones. I will copy your advanced design and work on making it work with any type of items. I will even try to make circuit for ignoring empty input lanes when selecting which lane to let go into mux next.

Nice thing is that once you set up the packets and let them onto the belt, you don't need to make everywhere those "signals", they will simply keep their distance that was set up by combinatorics that let them into the system. Problem is if belt is not straight and belt sides will not be synchronized when packets will try to exit this system. Another thing I was working on yesterday - recreate synchronized packet after belt was rotated.

Yoyobuae wrote: Simply hold back the previous packet at the output of the splitter, blocking output from that lane. Manual testing seems to show it works with a single splitter. Two splitters stacked (4-to-1 demux) is a bit of a challenge, not only does the final output splitters need to have their lanes blocked, but also the intermediate splitter as well. It's doable, but making the circuit to control it will be a challenge.

But how will you recover lost items in splitters? Splitter output with one blocked exit still sends there some items (2 or 4?). Every belt and splitter set ups that I can think of still will lose some items in splitters. All splitter output need to be on at all times or it will lose items there. Maybe use splitter to separate packet to two belts with only one belt side used and then sideload them onto new belt without other splitters (somehow?).

Good luck, hope you will figure it out.

Posted: **Mon Nov 14, 2016 6:13 pm**

I'm working on something similar. I am using packets of 12 items per lane so the receiving end can use one stack inserter per lane and pick up a full packet in one go.

When you use splitters to split off a packet from the belt again you will need to block the complete belt (both lanes) to get a packet "out". Half of the header of your packet will be stuck on one side of the splitter when splitting out a packet. But when the "splitting off a packet" stops and the main flow continues, you will have these spurious items continue their journey on the main belt. You will also need a footer, or the next packet will lose its head in the splitter.
This means reduced throughput and you have bogus items go around.

To overcome this you need an inserter that clears (pick from) the splitter after using it to split off a packet. So why not use the inserter directly.

Edit: My goal is to build a crossbar switch to replace a bus, just to make something that nobody else did yet

Edit2: So we seem to have found each other.. I lack the multiplexer you lack the demultiplexer. Now we need a bus master and arbiter to assign packet slots ^^

Edit3: Here's an example image how I access the main packet belt. The output portion needs circuit logic it does not work yet. It is meant for replacing a packet on the bus. The two inserters that pick up the packet need to face the belt in the belt-move-direction (they may not sit on the side) or they will miss and not pick up the 2nd item of the packet.

Edit4: The complete system would use buffer chests that are loaded with incoming packets. The buffer chests would have a simple logic to request items from the multiplexer. The multiplexer would then have an arbiter that serves the requests in a prioritized round-robin fashion. Actually the arbiter would assign packet slots on the bus and the multiplexer would fill them as requested.

Posted: **Thu Nov 17, 2016 5:06 am**

Atria wrote:Nice thing is that once you set up the packets and let them onto the belt, you don't need to make everywhere those "signals", they will simply keep their distance that was set up by combinatorics that let them into the system. Problem is if belt is not straight and belt sides will not be synchronized when packets will try to exit this system. Another thing I was working on yesterday - recreate synchronized packet after belt was rotated.

Finally got around making a version that allows for turns (video):
https://gfycat.com/RaggedFragrantArrowworm

The little loop besides the belt is where the magic happens. There's a piece of raw wood on the inside of the little loop. Then the belt conditions are set to implement a SR Latch of sorts. It's compact and it doesn't require power. Downside is that the raw wood needs to be placed manually.

That trick is not really necessary, it's just neat that works.

The combinator version would probably work a tad faster (my version takes ~5 cycles to react).

Settings for the belts:
https://imgur.com/a/XmBmN

Blueprint (needs Creative Mod):

Code: Select all

H4sIAAAAAAAA/+VbYW+bMBD9KxWfgxTApI02749ME3LAba0Rg4yTNkL57zMk2XLAtpxLBtb6pU2dXPzu3R13z5AVD3mRsvwhoTWXWmjBK1rXkm059aoty3M/
Z9vSW5RFZRYLSet36q8XB+qHx0VaSK2KPNnwV7YXhaJ1KlS6EzoxK9n5/c9CVTqpxItkOa31oTSW90LpHcu9xfmL2kV/k7P0u9earTSTmi7Nn9uSKaaNbe+L
d2zXJE8by2afX73A+0ZrxTOz53b7h0RkNDw2P4szios139jaCNnY6sAJlg2eYAjPs8g1V41LcAB2ZvfBQsiMv9PgeOO+zQ6uX8UABn8vFa8qXysmq7JQ2t/w
XEMk0ZmXTKjTd1Fiz5HQfHvBlxZlyZVf5kzza4JWBDBEm7WzdS7ZJudJJqrmN9Vqx3+uKc6y5JXJrNmDNpAruH757+mN2yLjNBh24YviXAInkiXabWHPbSH+
84PhM6KrQ+Dpz/aefmZ5ZePqbrSuQLRGa7toDa7dvhq7ovA9Vwf9KuTLH6L2A760jNquK02mL/qRHMECkBqzWuy531hOmpDx94XIurWs8epyOJYHLFTFTqV8
yEaHmF+F8FzUhsP1vBoOruLCww+C7jbC+6ZYPFpc/DXHlreWsxBfzk6OAzGwQhoIR/S87bX+X/u+l5T4inZy3Ic8vxzDQGB/LWt7u+Vdi/L9qB+pHId44teY
hOmgggFrBQu32UcMxeNv9sbKF6xBgxFGeFYep2Xl9hIPgBI80Cc3GH20QzZ/CoMnQKHFlSN2gkGThCBULQiNnSDUJCEA+oQHunKCUZOTAGhgB3T+jHZSNLS4
yPdGq1kyGkJGIwtGe/PfLBkNIaORBaPEDUahMBjihcEWqAOMhhDoymICc4LRCDIaWTCKEkemAwoZjSwY7Y/UcwRqkhKErkULiBJdpgPa0X3x+tTEKYre632F
sHtL1ONJkRG+Ce6rWbMMaag04GtUX3ObI0yLVJ24JKGPkxwgAQ6WBN+do66HiFMRxd78t6LI5qzM2h2Jz78CQVmF4KVON/r7CE5sBD+xuaEeEdjeE3zYujGY
EqhcE7xy7YbsSTr5iZc93dDICJzWCL4TcuPEhcBhjeCHNTfEXdJpNvANvBtHhQRKnjG+qXLjmInA2TvGN/QTn1PfihMOZDG+H3LjQJTAfijG90OouzUmwxnD
fijG90MDt7XMEihsiGJ8Q4S76W06oPiUHLi1aZbIYA8U43uggdvvZgkUNkExvqm93Cb43yqiNsEx8XEG5rGIZqt/fZpgpCckFqJKzDe0CG98WuLU5ZlPpu3b
6t9LW78h5nj1gMYnxfVOyYfkE5fZDxcq5EYWMwAA

Posted: **Fri Nov 18, 2016 7:54 pm**

WIP Furnace contraption:

VIDEO

When input ingredients are picked up from belt there's always a space left, so why not use that space for output?

This contraption is designed so that the space left from removing an item is consumed by the output. This means that the belt goes from full compact ore to full compact plate. Well output is almost fully compact, since the belt is stopped for a fraction of a second there's a little space generated at the output.

Now I just need to figure out how deliver coal thru that same belt.

Posted: **Fri Nov 18, 2016 8:52 pm**

The loop thing you've built is interesting. Unfortunately I'm quite busy building a smart furnace with belts so I don't have time to take a deeper look into your contraptions. I'll do it later when I will need such things.

For now I want to note some things about your shared furnace belt. There are many builds with shared input output belt on the forum so its problems are well known. Your setup works because of inserter stack size 1. As soon as you research stack size bonus it will have compression problems and some furnaces won't be able to output onto the belt anymore. What you need to do for full compression is to insert onto an underground belt entry or exit. Another thing is that with productivity modules you will need more space on the output belt than on the input belt, so the build is not suited for beacons.

Posted: **Fri Nov 18, 2016 10:26 pm**

[quote="hansinator"For now I want to note some things about your shared furnace belt. There are many builds with shared input output belt on the forum so its problems are well known.[/quote]
Really? I tried searching in forums and on Reddit but couldn't find any shared input/output belt setup.

EDIT: Well, I've seen some mixed belt system either with multiple inputs and I think some with input/output on same belt, but they always loop back the output to take care of any remaining input. Then they use circuits to regulate things. My setup doesn't use loops, instead it guarantees the full input is consumed in one pass.

hansinator wrote:Your setup works because of inserter stack size 1. As soon as you research stack size bonus it will have compression problems and some furnaces won't be able to output onto the belt anymore. What you need to do for full compression is to insert onto an underground belt entry or exit.

I see no reason why it wouldn't work with increased stack size bonus. Here's a proof of concept with stack size 2:

VIDEO

It works as long as the 1-to-1 input/output ratio is kept, inserter stack size doesn't change that.

The tricky part will be guaranteeing that the input is always fully consumed. Will probably need to fiddle around with the circuit logic and spacing to get inserter timing just right.

hansinator wrote: Another thing is that with productivity modules you will need more space on the output belt than on the input belt, so the build is not suited for beacons.

Yeah, that's true. It breaks the 1-to-1 input output relation.

I've personally decided that I'm aiming more for elegance and cleverness with these solutions, rather than raw throughput stats.

Posted: **Fri Nov 18, 2016 11:05 pm**

Yoyobuae wrote:
hansinator wrote:For now I want to note some things about your shared furnace belt. There are many builds with shared input output belt on the forum so its problems are well known.
Really? I tried searching in forums and on Reddit but couldn't find any shared input/output belt setup.

A quick search doesn't turn up suitable topics, but trust me, I've seen many examples in different builds in this forum.

Yoyobuae wrote: It works as long as the 1-to-1 input/output ratio is kept, inserter stack size doesn't change that.

As long as they are synchronized, yes. But the inserters will pick from both sides of the belt with a larger stack bonus while always outputting on the same belt tile. On average this shouldn't hurt, but it creates local imbalances between the items that are picked up and laid down on one side of the belt. This leads to de-synchronization in a way that some inserters never get the chance to lay down items. Then usually inserters fail at fully compressing the output belt with higher belt speeds which causes more output inserters to miss a chance to put items on the belt. Maybe I missed a detail in my description. It is a complex failure mechanism.

You will see this problems emerge when you build a larger test setup with stack bonus. Problem intensity increases with higher belt speeds. Though I don't know if your regular belt stopping mitigates these problems, but I suppose not.

Edit:

Yoyobuae wrote:I've personally decided that I'm aiming more for elegance and cleverness with these solutions, rather than raw throughput stats.

I'm aiming for all of it and additionally I want to maximize usage of belts, train stations and furnaces. This means that different resources share the same facilities, i.e. a smart train station and furnace setup. That is also why I am aiming for a packetized main bus: if some of the resources it carries require less than a blue belt of throughput, I can put additional other items on that blue belt. This way I can save on belts, train stations and furnaces which would otherwise sit idle when their output is not required. Some things require complex constructions to get the full throughput, so some of them inevitably become ugly. But in the end it pays off. I also like complex things

Posted: **Fri Nov 18, 2016 11:19 pm**

hansinator wrote:
Yoyobuae wrote: It works as long as the 1-to-1 input/output ratio is kept, inserter stack size doesn't change that.
As long as they are synchronized, yes. But the inserters will pick from both sides of the belt with a larger stack bonus while always outputting on the same belt tile. On average this shouldn't hurt, but it creates local imbalances between the items that are picked up and laid down on one side of the belt. This leads to de-synchronization in a way that some inserters never get the chance to lay down items. Then usually inserters fail at fully compressing the output belt with higher belt speeds which causes more output inserters to miss a chance to put items on the belt. Maybe I missed a detail in my description. It is a complex failure mechanism.

You will see this problems emerge when you build a larger test setup with stack bonus. Problem intensity increases with higher belt speeds. Though I don't know if your regular belt stopping mitigates these problems, but I suppose not.

Hmm, would have to investigate it more closely to be sure.

Probably it has to do with faster belts moving several "slots" per cycle. So the empty slot never lines up with the output inserter.

Posted: **Sat Nov 19, 2016 2:10 am**

Yoyobuae wrote:Hmm, would have to investigate it more closely to be sure.

After closer inspection I believe that output inserters with inserter stack bonus are bugged.

Output inserters randomly take one cycle longer than necessary to drop their payload on belt even when the free space is there. Which could be related.

But the bug really becomes evident with the inserter stack bonus and faster belts. The larger the stack the more the inserter lags behind belt until they simply misplace the item, leaving empty slots in belt (or outright miss a candidate 9 slot space).

I'm guessing the devs were trying to reduce the amount of times the output inserter needs to check for free space on the belt, but that may be interacting badly with inserter stack bonus.

Doesn't happen at all without the stack bonus though. My solution: Don't research stack bonus. The stack bonus for non-stack inserters shouldn't even exist, anyway.

Well, back on topic. Turns out stopping the belt was unnecessary. Just had to tweak the positions of furnaces a bit to handle the new timing and now it works without generating any gap:

VIDEO

Posted: **Mon Nov 21, 2016 4:47 am**

Made "a few" improvements to the Furnace design:
https://youtu.be/hKnnk31yKuw

Now it can supply coal as well as ore. And it can also switch between ore types. Note that I had the steel recipe researched, which made things particularly tricky considering output iron plates are on the same belt as input. But finally manage to get it to work without any deadlocks.

But in the end it's not very practical. Had to use way more combinators. And the input needs to be PERFECT. Even a imperceptible space on input messes up the timing. Had quite some issues trying to make the input switch from copper to coal to iron while maintaining perfect compression.

Posted: **Tue Nov 22, 2016 10:53 pm**

The furnace setup looks very elegant, but why do you rely on coal when electric furnaces are simpler to operate?

If you connect a inserter with a circuit wire to just a pole and nothing else and set it to "read hand contents, hold" and "enable everyhting = 0" it will pick up just one item, circumventing the stack bonus. There's also this solution from DaveMcW viewtopic.php?f=193&t=35380#p219373
The same thread also shows my method of explicitly setting the stack size using a constant combinator.

Factorio Forums

Yoyo's Belt+Circuit contraptions

Yoyo's Belt+Circuit contraptions

Re: Yoyo's Belt+Circuit contraptions

Re: Yoyo's Belt+Circuit contraptions

Re: Yoyo's Belt+Circuit contraptions

Re: Yoyo's Belt+Circuit contraptions

Re: Yoyo's Belt+Circuit contraptions

Re: Yoyo's Belt+Circuit contraptions

Re: Yoyo's Belt+Circuit contraptions

Re: Yoyo's Belt+Circuit contraptions

Re: Yoyo's Belt+Circuit contraptions

Re: Yoyo's Belt+Circuit contraptions

Re: Yoyo's Belt+Circuit contraptions

Re: Yoyo's Belt+Circuit contraptions

Re: Yoyo's Belt+Circuit contraptions

Re: Yoyo's Belt+Circuit contraptions

Re: Yoyo's Belt+Circuit contraptions

Re: Yoyo's Belt+Circuit contraptions

Re: Yoyo's Belt+Circuit contraptions

Re: Yoyo's Belt+Circuit contraptions

Re: Yoyo's Belt+Circuit contraptions