Mine depletion indicators (Muliplexing/Demultiplexing by Modulo Operations)

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
NamelessPC
Burner Inserter
Burner Inserter
Posts: 13
Joined: Tue Sep 13, 2016 2:03 am
Contact:

Mine depletion indicators (Muliplexing/Demultiplexing by Modulo Operations)

Post by NamelessPC »

I've already posted a picture of my base in this thread, but there were questions about my mine depletion indicators, so I thought I'd describe them in more detail.

Problem Statement

Iron, copper, coal, and stone mines can be spread quite far over the map. Each deposit has a finite amount of resources, and once a mine is exhausted a new one must be established elsewhere to replace it. Waiting until your base shuts down due to starvation before dealing with the problem can be frustrating, and constantly visiting your mines to check their reserves takes too much time. In true Factorio style, this calls for an automated solution!

Solution Overview

Each of my mines has six buffer boxes (that's the length of a train car). I use combinators at each mine to produce a signal based on whether there is any ore in those boxes. These signals are multiplexed onto a single circuit network spanning all mines across the map, then that signal is brought back to the main base, demultiplexed, and used to illuminate a set of indicator lights, one per mine. The lights get one of three colors: Red implies a depleted mine buffer. Green implies a supplied buffer. If more indicator lights are built than mines, the excess lights default to blue. Here's what the indicator lights look like. From left to right, 5 coal mine indicators, 10 copper, 10 iron, and 5 stone indicators.

(image rotated 90 degrees to fit the screen better. <--- North is that way)
indicator_lights.jpg
indicator_lights.jpg (75.9 KiB) Viewed 18674 times
Details

Signal Values

Each mine generates a simple signal based on the contents of its buffer boxes. There are three possible values:
-- 0 -- An "empty signal" indicating that there is no mine built (or at least it hasn't been enrolled in the circuit network yet)
-- 1 -- This mine has no ore left in its buffer boxes. It is depleted or nearly so.
-- 2 -- This mine has ore in its buffer boxes. Things are probably OK.

This value is computed using two combinators.
1. A decider combinator tied to all the buffer boxes. Rule: IF [ore type] > 0 THEN OUTPUT (1 [ore type])
2. A constant combinator that simply puts a out a signal of (1 [ore type])

At coal mines [ore type] is coal, at iron mines, [ore type] is iron ore, and so on. Here's an example of a copper mine with this setup.
mine_combinators.jpg
mine_combinators.jpg (253.47 KiB) Viewed 18674 times
You'll notice that the final signal goes through an extra arithmetic combinator before being put on the circuit network. Bear with me. That's going to take some time to explain.

Multiplexing

Now that each mine is computing its "depletion signal" value we need to get those signals back to the base where we can keep an eye on their values. The trick is to keep track of which signal came from which mine. You could try to keep each signal isolated to its own circuit network, but that's going to require a lot of careful planning and way too many power poles. Instead we can borrow a solution form the world of computer engineering called multiplexing. If you're not familiar, the basic idea is to smush a bunch of relatively small numbers together into one really big number in such a way that you can reverse the process downstream and retrieve each individual number again. I'll give you an example. Imagine we take the first copper mine's signal and multiply it by 1. The second copper mine we multiply by 10, third by 100, fourth by 1,000, and so on. Then we add all the numbers together by putting them on the same circuit network. We might get a number like this: 022121. Now the status of each mine is represented by a digit. The ones place is the first mine. It's depleted. The 10's place is the second mine. It's OK. The third mine is depleted. Four and five are OK. The 100,000's place is zero, which means we didn't build a sixth mine yet.

OK, so how do you decode that value back at the base? Here we borrow a mathematical tool from the world of discrete math: the modulo operator, or mod for short. Mod just means "the remainder after dividing". For example, 10 goes into 22,121 a total of 2,212 times evenly with a remainder of --1--, so 22,121 MOD 10 is 1, and that's the signal from our first mine. You can get the second mine's signal by dividing by 10 before applying the mod operator, in general, if your big mutexed value is X, then:
Mine signal 1 = X MOD 10
Mine signal 2 = (X/10) MOD 10
Mine signal 3 = (X/10/10) MOD 10
Mine signal 4 = (X/10/10/10) MOD 10
...
Mine signal n+1 = (X/10^n) MOD 10

"But NPC", I hear you say, "we don't have a MOD operator in Factorio!" Well, you can hack one. Factorio's arithmetic combinators use what's called "integer division". That means when you divide A by B, it doesn't round the result. It simply drops the remainder. For example 999/1,000 isn't one-ish as you'd expect. It's zero. So if you take a number, X, and divide it by another value, B, then multiply it by B again, you won't get back to the X you started with. You'll be short-changed by the remainder of X/B. And that's exactly what we're after. In short: X-(X/B*B) = X MOD B.

Great. Now you have enough conceptual tools to build this thing, right? Technically yes, but there's one more optimization we can make to the design. The mine signal values are always 0, 1, or 2. You can't have a 3, 4, 5, 6, 7, 8, or 9. So it's kind of a waste to use an entire decimal digit to represent them. Can we be more efficient? Turns out yes. We can reach back into our bag of mathematical tricks and pull out non-decimal bases. If you've ever had to work with binary, hexadecimal, or octal numbers you've already played in this space. But we're not going to use any of those bases. We have three unique values, so base 3 is the most efficient way to store them. If these words are foreign to you, don't worry too much. What it boils down to is that we can take all the math from above, and wherever we multiply, divide, or mod by 10, do so by 3 instead. You still get much smaller mutex values, and they'll still be fully reversible (i.e. they can be decoded at the base just fine).

So now you'll understand the role of the "multiplexer" arithmetic combinators in the picture above. They multiply the depletion signal value by a coefficient power of 3.
Mine 1 coefficient is 1 = 3^0
Mine 2 coefficient is 3 = 3^1
Mine 3 coefficient is 9 = 3^2
Mine 4 coefficient is 27 = 3^3
...
Mine n+1 coefficient is 3^n

The mine above happens to be copper mine 2, so its coefficient is 3.
mux_combinator.jpg
mux_combinator.jpg (236.87 KiB) Viewed 18674 times
Demultiplexing

I've already explained demultiplexing in the previous section, but since I was mean and pulled a change of base on you, I'll take the time to lay out the real base 3 math with an example. Let's use the stone depletion indicator bank from the first picture since it's smaller than iron or copper.
stone_lights.jpg
stone_lights.jpg (272.37 KiB) Viewed 18674 times
The multiplexed signal for stone comes in from the top on a green circuit. To be clear, all the mines' multiplexed values are on this circuit, but we're only going to deal with the stone signal in this bank of lights.

Two things to notice: 1) there is an ongoing calculation here, and its overall direction is up. That is, the original multiplexed value comes in to the lowest combinator in the bank and intermediate values are going to be passed up (i.e. north); and 2) there is a repeating pattern of six combinators, three arithmetic, then three decider. The three arithmetic combinators demutex a single mine's signal, and the three decider combinators translate the result to the three colors (blue, red and green). Here are the rules inside those boxes. Assume that the mutexed value on the circuit network is X:

Arithmetic combinator 1: A = X/3 ## Remember we're doing integer division here
Arithmetic combinator 2: B = A*3 ## B=X/3*3. This is encoded as stone bricks instead of stone because we need to compare it with the original stone value in the next step
Arithmetic combinator 3: C = X-B ## C=X-(X/3*3). Remember from before this is equivalent to C=X MOD 3.
Decider combinator 4: IF C = 0 THEN Blue
Decider combinator 5: IF C = 1 THEN Red
Decider combinator 6: IF C = 2 THEN Green

Tie a light to the output side of all three deciders et voila! You have an indicator light.

Now recall that to demutex each signal we have to keep dividing by our base (3) until we get to the digit that represents the right mine. So to demutex mine 2's signal value we first need to compute X/3. Luckily we already did that with arithmetic combinator 1. So Just lay down another bank of six combinators and tie the output from the old combinator #1 to the input of the new combinator #1. Continue chaining banks of six combinators together in this fashion until you get bored, run out of space, or think you'll never build that many stone mines.

Side note: There's a single arithmetic combinator at the very beginning (bottom). All it does is take the value of stone and multiply it by 1. This has two benefits: 1) it filters out all the other mutexed values for iron, copper, and coal; and 2) it keeps intermediate values (specifically the bricks value, B, from combinator #2) from bleeding back onto the larger circuit network. Neither of these are strictly necessary to make the system work, but it does tidy up the signals and make them easier to understand at a glance.

Scalability

In theory this method is infinitely scalable. In practice you're limited by the maximum size for a single multiplexed value. If you had a million iron mines your iron signal could get as large as 3^1million - 1. That's a big number. I'm assuming that Factorio uses 64-bit signed integers to store circuit network signal values, in which case you can have up to 34 mines per resource by my estimation. Any more and you'll cause an overflow. That should be more than enough for sane bases, but of course this is Factorio. Sanity is for the weak. If you really want to expand this design to 35 mines and beyond you could do it by encoding the depletion signals for mines 35 thru 68 with another resource besides ore. I'll leave that as an exercise to the reader.

Happy factoring!
Last edited by ssilk on Thu Sep 15, 2016 10:04 am, edited 3 times in total.
Reason: Extended subject to lets see, what it is about.

NamelessPC
Burner Inserter
Burner Inserter
Posts: 13
Joined: Tue Sep 13, 2016 2:03 am
Contact:

Re: Mine depletion indicators

Post by NamelessPC »

By the way, I haven't downloaded the mod to create blueprint strings yet. If some enterprising soul would like to save me the trouble and blueprint a few of these structures I'd be obliged.

doxsroxs
Fast Inserter
Fast Inserter
Posts: 160
Joined: Mon Aug 01, 2016 4:19 pm
Contact:

Re: Mine depletion indicators (Muliplexing/Demultiplexing by Modulo Operations)

Post by doxsroxs »

Thats an interesting solution. We approached it in a slightly different way.
We are using a train system with combinator magick built by siggboy and the issue of depleted mines was driving us mad.

Currently we use a multi mining station where we load all ore types, fast to build and then blanket all nearby ore spots. Mixed ore is sent to central sorting facility and from there on to factories or a central storage if there is no factory demanding material at the moment.
Central storage buffers are huge and provide a buffer so the factory can run for hours without hickup.

However, we now need to keep track of storage levels there instead to ensure we do not get a stop in production. Plan is to make a central control panel. Might steal a few ideas from you :)

When it comes to blueprints, Im afraid building what you have based on pictures is simply not feasible for most of us, only way to distribute the detailed plans is via blueprints exported from your actual game.
Send train to station ID using combinator signal is a long overdue feature!
viewtopic.php?f=6&t=74663

NamelessPC
Burner Inserter
Burner Inserter
Posts: 13
Joined: Tue Sep 13, 2016 2:03 am
Contact:

Re: Mine depletion indicators (Muliplexing/Demultiplexing by Modulo Operations)

Post by NamelessPC »

doxsroxs: I'm glad to hear this might be helpful to someone. Let me know how it goes. Actually I almost adopted a design like yours in my base, but I found it easier to build a large block of dedicated trainstops for 1-1 trains. I might revisit that decision in my next base.

To your point about blueprints, I uploaded a save file in my other thread (linked at the top of the article). I should've stated that somewhere. It had gotten too late by the time I finished this article, but If no one beats me to it I'll figure out blueprint strings and post them later this evening.

NamelessPC
Burner Inserter
Burner Inserter
Posts: 13
Joined: Tue Sep 13, 2016 2:03 am
Contact:

Re: Mine depletion indicators (Muliplexing/Demultiplexing by Modulo Operations)

Post by NamelessPC »

As promised, here are some blueprints.

Indicator Lights
5 Light Demux -Coal-
5 Light Demux -Stone-
10 Light Demux -Copper-
10 Light Demux -Iron-
Loading Station

These can't be templated as easily because every train stop will be slightly different. The example below is for copper mine #2. When you instantiate this do the following:
1) Change the signal's resource type in all three combinators from copper to the current mine's type (iron, coal, copper, or stone)
2) Change the multiplier coefficient in the arithmetic combinator from 3 to whatever is appropriate for the current mine. Here's the table from before:
- Mine 1 coefficient is 1 = 3^0
- Mine 2 coefficient is 3 = 3^1
- Mine 3 coefficient is 9 = 3^2
- Mine 4 coefficient is 27 = 3^3
- ...
- Mine n+1 coefficient is 3^n
Example Loading Station -Copper Mine 2-

nevniv
Inserter
Inserter
Posts: 49
Joined: Wed Sep 21, 2016 1:37 am
Contact:

Re: Mine depletion indicators (Muliplexing/Demultiplexing by Modulo Operations)

Post by nevniv »

This is awesome (as is your base). I feel like I would have to retire to get into the mindset to do something like this and I still think its a stretch.

Acarin
Long Handed Inserter
Long Handed Inserter
Posts: 94
Joined: Thu Sep 01, 2016 3:58 pm
Contact:

Re: Mine depletion indicators (Muliplexing/Demultiplexing by Modulo Operations)

Post by Acarin »

I love this setup, Nameless, and would just like to say thanks for sharing it. One possible 'upgrade' that I am considering, however, is switching it over to a base-4 system and introducing a yellow signal for when the outpost chests contain more than zero, but less than a full car-load of ore (ie each set of 6 chests monitored contains less than 2000 ore in total). This would also enable me to monitor outposts as they are running low on resources, rather than only when they are completely dry. The lower the resource level, the longer it will take to complete a trainload, and the longer the yellow light stays on. Eventually, it will of course still turn red to indicate total depletion, but at least there will be some warning first?

NamelessPC
Burner Inserter
Burner Inserter
Posts: 13
Joined: Tue Sep 13, 2016 2:03 am
Contact:

Re: Mine depletion indicators (Muliplexing/Demultiplexing by Modulo Operations)

Post by NamelessPC »

Acarin: I like the idea of a "running low" indicator, but I suspect your criteria might not give you quite what you're looking for. The buffer quantity fluctuates quite a bit depending on the size of the mine, location of the train, and the resource type. I found that the base 3 system does give you at least a little warning. When mines are running low the lights will flicker red-green, since the train is being loaded faster than the buffer boxes can be refilled. If you want to pursue yellow lights, however, you might try adding the conveyor belt to the circuit network just upstream of the buffer to sample the flow rate. If it falls too low then trigger a yellow light. In fact the conveyor belt might be a better source to base all three light colors on. If you get it either solution working well feel free to share a blueprint string.

Silverwing
Manual Inserter
Manual Inserter
Posts: 4
Joined: Tue Oct 11, 2016 3:38 pm
Contact:

Re: Mine depletion indicators (Muliplexing/Demultiplexing by Modulo Operations)

Post by Silverwing »

When I first read this I thought to myself what a great idea. I have only starting working with Factorio but it doesn't take long to realize that keeping track of your mines is a daunting task.

Then I started reading and my head started to hurt and my vision blurred. I have been working with computers most of my life and am very familiar with base math (binary, hex, oct) and the concept of multiplex computations. However, I never really stopped to examine the science behind it - it just worked. I can't express how much I enjoyed working with this idea and setting up my own multiplexed circuit.

I started out by just simulating different mines with constant combinators, one for each ore type and then added additional simulations to test out the concept. It was tremendous fun, thank you so much for sharing this it was a delightful way to learn something new

Wackerstamfer
Long Handed Inserter
Long Handed Inserter
Posts: 80
Joined: Sat Oct 22, 2016 9:38 pm
Contact:

Re: Mine depletion indicators (Muliplexing/Demultiplexing by Modulo Operations)

Post by Wackerstamfer »

NamelessPC wrote:Acarin: I like the idea of a "running low" indicator, but I suspect your criteria might not give you quite what you're looking for. The buffer quantity fluctuates quite a bit depending on the size of the mine, location of the train, and the resource type.

NamelessPC wrote:Acarin: If you want to pursue yellow lights, however, you might try adding the conveyor belt to the circuit network just upstream of the buffer to sample the flow rate. If it falls too low then trigger a yellow light. In fact the conveyor belt might be a better source to base all three light colors on. If you get it either solution working well feel free to share a blueprint string.
THIS! Exactly what I came up with. I've made a contraption that keeps track of the max amount of ore on the belt from the mines to the station and calculates the percentage of current amount of ore on the belt related to the maximum amount. Then I have 3 colors, red <10% , yellow 10%< >60% , and green >60%.

Gives perfect early warnings, but it it sometimes necessary to reset the max value if it was a really large orefield.

It was really fun to figure this one out, thanks! :D

Silverwing
Manual Inserter
Manual Inserter
Posts: 4
Joined: Tue Oct 11, 2016 3:38 pm
Contact:

Re: Mine depletion indicators (Muliplexing/Demultiplexing by Modulo Operations)

Post by Silverwing »

All due credit to NPC, and Siggboy for all their hard work. I took to hart what NPC said about a flow rate calculator for mining and relaying that through the multiplex. What I came up with was way to complicated, but fortunately Siggboy posted a design that did the same thing but with only a few combinators. I tied this into NPC's multiplex circuit and vio'la a beautiful flow rate calculator. I added Nixie tubes for a digital display, but the circuit works very well without them.
Flow rate calculator
The flow measure is configurable to the desired interval, as displayed here the interval is set to 1 minute (3600 ticks)
The design is not complicated so I won't post a long winded explanation. If you have a question just ask.
Blueprint
EDIT: One additional note, since a full belt and a empty belt would look the same to the flow calculator, I added a second belt segment set to hold, and add my base threshold back into the multiplex circuit if it detects that the belt is full.

Wackerstamfer
Long Handed Inserter
Long Handed Inserter
Posts: 80
Joined: Sat Oct 22, 2016 9:38 pm
Contact:

Re: Mine depletion indicators (Muliplexing/Demultiplexing by Modulo Operations)

Post by Wackerstamfer »

This is what I came up with
fact.png
fact.png (453.63 KiB) Viewed 17106 times
(I dont have blueprintstring mod) :roll:

User avatar
DemiPixel
Long Handed Inserter
Long Handed Inserter
Posts: 72
Joined: Mon Mar 21, 2016 7:27 am
Contact:

Re: Mine depletion indicators (Muliplexing/Demultiplexing by Modulo Operations)

Post by DemiPixel »

Or, instead of displaying it with lights, you could "simulate" the belts at your base for a cooler effect (size needs to be made smaller, or the simulated belt's inputs/outputs should be distant from the viewing area):

https://www.youtube.com/watch?v=XzWpKh8Bkzs

This does not include the communication system, but I've found the best system is often the tick system instead of multiplexing. Increase a counter every tick or two ticks, requesting for the throughput of the mine and then saving it. Each mine only needs to be given their ID in a constant combinator (not their multiplex multiplier) and gives an update time of 1 to 2 seconds with 60 IDs (supports up to MAX_INT).

User avatar
DRY411S
Filter Inserter
Filter Inserter
Posts: 726
Joined: Sun Mar 13, 2016 9:48 am
Contact:

Re: Mine depletion indicators (Muliplexing/Demultiplexing by Modulo Operations)

Post by DRY411S »

This is great! I'm looking to adapt it to include a yellow light, for a bot based outpost, so no belt flow measurement possible.

Can I suggest a possible improvement, which is to make a single generic blueprint suitable for all ore types. On the 'isolater' combinator at the bottom right, convert the ore input into an output variable and then where you use ore and plate as 'variables' when travelling North through the combinator 'stack', just use 2 named variables instead.

With the 1 generic blueprint, you'd place it down once for for each ore type, then just set the ore type as the input on the 'isolater'.

[ i.e. In computing terms, get rid of the hard coding, and define a function that has an input parameter :) ]

User avatar
DRY411S
Filter Inserter
Filter Inserter
Posts: 726
Joined: Sun Mar 13, 2016 9:48 am
Contact:

Re: Mine depletion indicators (Muliplexing/Demultiplexing by Modulo Operations)

Post by DRY411S »

EDIT: IMPROVED VERSION

I'd appreciate feedback on this outpost combinator array, designed to send a Red (1), Amber(2) or Green(3) signal back to the factory on the green wire. It is designed to minimise hardcoding and edits once the blueprint is placed.
Tall screenshot
On the right is a constant combinator
You should edit 3 of the variables in the combinator when you place the blueprint

'R' is the level of ore in the chests which will cause a red light to show at the factory if the ore stored is less than this
'A' is the level of ore in the chests which will cause an amber light if the ore is between 'R' and 'A', and a green light if the ore is greater than 'A'.
'4' is the mine coefficient. Mine 1 '4' = 4, mine 2 '4' = 4*4 = 16, mine 3 '4' = 4*4*4 = 64, etc.

On the left is the stack that computes what is sent back to the factory from the bottom combinator. In the blueprint, and in the screenshot, for testing purposes, a constant combinator is sending a copper ore count.

HOW TO USE IT IN AN OUTPOST.
  1. Place the blueprint.
  2. Delete the top left constant combinator.
  3. Send your ore count on a green wire to the top combinator.
  4. Click the top combinator and change to the correct ore type for your outpost
  5. Click the bottom combinator to set the ore type for your outpost
  6. Send the output from the bottom combinator on a green wire back to the demultiplexer at the factory.
HOW IT WORKS
  1. The Ore count is loaded in the top combinator into the variable 'O'
  2. The next combinator sends an output of '1' (which actually equals minus 1!) if the ore count is less than 'A'
  3. The next combinator sends an output of '1' if the ore count is less than 'R'
  4. The next one adds the '1's to 3 and outputs it in the 'D' variable (Demultiplexed) [Remember 3 = green. The 'R' and 'A' decider combinators will be adding 0, -1 or -2 to this.]
  5. The next one multiplies 'D' by '4' (4 = 4,16,64 etc) and outputs the answer in the 'M' variable (Now Multiplexed)
  6. The final one loads 'M' into the ore type variable and sends it back to the factory.
I will post my RAG demultiplexer in another post, but I'm looking for feedback on this now because it feels as though there's too many combinators for what it does.

Here's the blueprint string (0.14)
Blueprint string

User avatar
DRY411S
Filter Inserter
Filter Inserter
Posts: 726
Joined: Sun Mar 13, 2016 9:48 am
Contact:

Re: Mine depletion indicators (Muliplexing/Demultiplexing by Modulo Operations)

Post by DRY411S »

So here's the other end of multiplexer/demultiplexer that receives the signals from the outposts to support BRAG display

B = no connection to a mine with that number
R = ore levels are below a low threshold set at the outpost
A = ore levels are between the low and high thresholds set at the outpost
G = ore levels are above the high threshold set at the outpost

(Thresholds are set at the outpost, to cope with the fact that different outposts may use different train lengths)

The BRAG display for the first mine uses this combinator setup.
First row display screenshot
Here's the blue print
First row display blueprint string
HOW TO USE THIS
  1. Place the blueprint anywhere in your factory
  2. Connect the bottom combinator to the green wire that is sending all the ore counts from all your outposts
  3. Click the bottom combinator and change the ore type for this 'stack' of lights.
[Note you will need to place this blueprint for each different ore type that you want to display]

ADDING MORE LIGHTS FOR ADDITIONAL MINES

Another row of lights is the top two rows of the first mine, with 2 additional connections. Here's a screenshot with exaggerated space between the two rows of lights so you can see the connections. They're red wires in the screen shot, but green also works.
Next row connections
However, the easiest way to add a new row of lights for the next mine, is to use this blueprint and place it so that it overlaps with the previous rows, as shown in this screenshot. This will connect the new row to the previous one for you.
Stamp down another row
Blueprint for adding rows to the BRAG display
Hope that this and the previous post are useful for people. It's worth mentioning at this point that everywhere in this post and the previous one, where 'ore' or 'ore type' are mentioned, this set up can be used for anything that you may want to load at one station and bring to an unloader where you want to see the BRAG levels at the other location.

Post Reply

Return to “Combinator Creations”