0.13 Prioritized Belts with Fallback Compression

This board is to show, discuss and archive useful combinator- and logic-creations.
Smart triggering, counters and sensors, useful circuitry, switching as an art :), computers.
Please provide if possible always a blueprint of your creation.
Post Reply
Tricorius
Filter Inserter
Filter Inserter
Posts: 266
Joined: Fri Jul 01, 2016 9:04 pm
Contact:

0.13 Prioritized Belts with Fallback Compression

Post by Tricorius »

I ran into a bit of a conundrum over the weekend. As my starting area coal and iron deposits were depleting I needed to bring in more resources to my main input lines. I had a larger coal deposit to merge into my fuel line. And I had to run a train in for iron. You can, of course, hook this up with a splitter...but now you're draining your original deposit more slowly. You could disconnect the new belt, but then your original deposit will experience shortages as miners mine-out the ground below them.

(In fact, the reason that I tried this option was due to my coal line to steam power slowly depleting and causing a power shutdown. Yes, it's easy to avoid this, but I was busy putting the hurt on biters.) :D

So:

I crafted a few colored wires and wired up some belt track. :)
PRIORITY_BELT
The upper belt services the small mining deposit (it was much larger, to begin with, of course). The lower belt runs west to an iron ore unloading depot. I didn't want to baby-sit the line, but I wanted that area mined out so I could use the real estate.

The red wire runs from the top belt, to the pole, then to the bottom belt. The top track is set to read the belt contents with the "hold" option (continually scans and broadcasts the contents of the belt to the wire).
TOP_BELT_CONDITION
The lower track is set to read the wire conditions, configured to enable/disable according to how much iron ore is on the broadcasting belt segment. (In this case, we are checking for less than one iron ore on the belt.)
BOTTOM_BELT_CONDITION
This condition now locks the lower belt segment when the upper segment has at least one ore (you can see here the "red" indicator light on the bottom belt segment). The lower belt is stopped, therefor the splitter is feeding solely from the top "priority" belt (in this case it's actually backed up since I spliced the southbound belt above the trash ore box to demo).
DEMO_PRIORITY_MODE
When there is a gap in the ore, it will feed from the lower "fallback" belt (to help maintain belt compression).
DEMO_FALLBACK_MODE
After the top belt is depleted, the condition always triggers (no ore on the upper belt) so you get a constant feed from the backup belt. (At this point, you can of course go send your personal construction bots to gobble up the mine and carry the fancy contraption away.)

This technique works WONDERFULLY for coal belts. Although I set the ore condition up a bit (iron ore < 3) to ensure there was more compression (I didn't care if I mined out the coal deposit as quickly...my priority was keeping power going).


-- Bonus --

I configured an ore trash chest (where you can dump spare ore that always seems to jump into your pockets over time).

The belt segment condition is essentially the same as above. I want to continually read what is traveling through the belt.
ORE_CHEST_BELT_CONDITION
Again, the action is essentially the same, but this time it's tied to a fast inserter.
ORE_CHEST_INSERTER_CONDITION
(This eventually becomes a requestor chest and you can just trash ore and rest assured that it will enter your network. Although this chest is in a poor location as that area of the belt is almost always compressed. You'd ideally want the chest that the tail end of the line so that it has more "on" time.)

-- Future --

There are obviously a lot of improvements that can be done (for instance running this right next to a very simple splitter combiner is *very* basic). It would be better to have a more robust compression configuration, but this was mid-game belt and I wan't really too concerned about it.
Last edited by Tricorius on Tue Jul 12, 2016 7:12 pm, edited 2 times in total.

BlakeMW
Filter Inserter
Filter Inserter
Posts: 950
Joined: Thu Jan 21, 2016 9:29 am
Contact:

Re: Prioritized Belts

Post by BlakeMW »

Clever. The splitter by itself does a pretty good job, but this will result in the nearly-depleted mines being completely depleted in half the time and since it's only one circuit wire (and you can technically omit the splitter and use sideloading) it's stupidly cheap.

Tricorius
Filter Inserter
Filter Inserter
Posts: 266
Joined: Fri Jul 01, 2016 9:04 pm
Contact:

Re: Prioritized Belts

Post by Tricorius »

BlakeMW wrote:Clever. The splitter by itself does a pretty good job, but this will result in the nearly-depleted mines being completely depleted in half the time and since it's only one circuit wire (and you can technically omit the splitter and use sideloading) it's stupidly cheap.
The splitter does do a fine job getting half of the mine onto the main line. That's actually why the splitter is still there (it was there first, before I had the idea for the belt condition, and I chose not to remove it.) As previously mentioned, the part that I *really* like about it is that as the mine depletes, the fallback belt will allow more through, keeping the line mostly compressed while still giving full priority to the mines.

pieppiep
Fast Inserter
Fast Inserter
Posts: 170
Joined: Mon Mar 14, 2016 8:52 am
Contact:

Re: 0.13 Prioritized Belts with Fallback Compression

Post by pieppiep »

What is wrong with this setup?
The items from the left have priority.
Side loading only adds items when the belt is not full.
No circuit needed.
Attachments
side loading.png
side loading.png (272.14 KiB) Viewed 5391 times

BlakeMW
Filter Inserter
Filter Inserter
Posts: 950
Joined: Thu Jan 21, 2016 9:29 am
Contact:

Re: 0.13 Prioritized Belts with Fallback Compression

Post by BlakeMW »

Circuit solutions are very cheap and compact, the cost of a circuit solution can be literally 1 or zero circuit wires (when constructed from blueprinted, the wires are freebies). Granted neither cost nor space are major considerations in Factorio, but there is an intrinsic attractiveness to the most minimalistic solutions.

Tricorius
Filter Inserter
Filter Inserter
Posts: 266
Joined: Fri Jul 01, 2016 9:04 pm
Contact:

Re: 0.13 Prioritized Belts with Fallback Compression

Post by Tricorius »

pieppiep wrote:What is wrong with this setup?
Absolutely nothing. :) But I have a soft spot in my heart for blinking lights.

Seriously, though, I presented this as a simple way to get started with logistics while solving a potential problem. Additionally, this scales a bit easier. You could still have a pretty compact setup when combining in ten mines and prioritizing them. Using pure belts would be more difficult if you want fine-grained control.

Probably not an issue most people will run into. But it's still kinda fun. :)

G-Fiti
Manual Inserter
Manual Inserter
Posts: 4
Joined: Sun Jul 10, 2016 12:29 pm
Contact:

Re: 0.13 Prioritized Belts with Fallback Compression

Post by G-Fiti »

Is it just me or are the images not working?

Tricorius
Filter Inserter
Filter Inserter
Posts: 266
Joined: Fri Jul 01, 2016 9:04 pm
Contact:

Re: 0.13 Prioritized Belts with Fallback Compression

Post by Tricorius »

G-Fiti wrote:Is it just me or are the images not working?
Hmm...I'm being cheap and hosting them out of dropbox, I'll look into moving them.

I attached the primary screenshot here for anyone having issues with the spoiler links in the original post.
Attachments
Setting for Locked &quot;Fallback&quot; (bottom) Belt
Setting for Locked "Fallback" (bottom) Belt
priority-belt-iron-5.png (3.69 MiB) Viewed 5161 times
Setting for Monitoring &quot;Priority&quot; (top) Belt
Setting for Monitoring "Priority" (top) Belt
priority-belt-iron-4.png (3.64 MiB) Viewed 5161 times
Here's the main Priority Belt Screenshot
Here's the main Priority Belt Screenshot
priority-belt-iron-1.png (2.77 MiB) Viewed 5161 times

Post Reply

Return to “Combinator Creations”