Combinator Contraptions

vampiricdust · Post by **vampiricdust** » Mon Aug 10, 2015 5:40 am

I wish I could play a multiplayer with you guys... shit I got a lot to go over.

Anyways, Lupoviridae's miner is awesome & easy to use, but since you have to change the two equal combinators every time you place on an ore different than your blueprint, I decided to add in a fourth combinator that makes universal and can easily handle mixed yields. While I've had to break the neat looker's symmetry, for one extra combinator it is a blueprint & forget combinator setup. I've made a new one where I have the deciders along one side & a medium pole in the space that was opened by pulling the center decider to the side.

The Lone Wolfling · Post by **The Lone Wolfling** » Thu Oct 15, 2015 10:03 pm

I've been trying to build a stable / fast detector for when a chest is getting filled up with items with a fast inserter - any ideas? I can get a pulse every time the inserter inserts something by comparing the number of items in the chest with the same signal delayed by a dummy comparator, but I can't figure out how to get it to output a stable signal in a reasonable manner - is there an adjustable retriggerable monostable that works with one-tick input pulses? (In other words, a circuit that will output only when a certain configurable amount of time has passed since the last time the input was triggered.)

I've come up with something that sort of works, but is clunky, to put it mildly. Take an arithmetic comparator and feed its output back to itself, setting it to subtract 1. So it counts down really quickly. Have each of the input pulses set it to zero (by taking the counter's output, negating it, and feeding that back to the system multiplied by the pulse). Then the output is "is the negated output < 29" (or alternatively, "is the output > -29", but that's clunkier). Additionally, you want a decider combinator to check if the negated input is >28, and if so, feed +1 back to the counter, to stop it from counting all the time. This is 6 combinators, and does a whole lot of unnecessary work. It's also a couple ticks slower than it needs to be.

Lupoviridae · Post by **Lupoviridae** » Fri Oct 16, 2015 8:34 pm

The Lone Wolfling wrote:I've been trying to build a stable / fast detector for when a chest is getting filled up with items with a fast inserter - any ideas? I can get a pulse every time the inserter inserts something by comparing the number of items in the chest with the same signal delayed by a dummy comparator, but I can't figure out how to get it to output a stable signal in a reasonable manner - is there an adjustable retriggerable monostable that works with one-tick input pulses? (In other words, a circuit that will output only when a certain configurable amount of time has passed since the last time the input was triggered.)

I've come up with something that sort of works, but is clunky, to put it mildly. Take an arithmetic comparator and feed its output back to itself, setting it to subtract 1. So it counts down really quickly. Have each of the input pulses set it to zero (by taking the counter's output, negating it, and feeding that back to the system multiplied by the pulse). Then the output is "is the negated output < 29" (or alternatively, "is the output > -29", but that's clunkier). Additionally, you want a decider combinator to check if the negated input is >28, and if so, feed +1 back to the counter, to stop it from counting all the time. This is 6 combinators, and does a whole lot of unnecessary work. It's also a couple ticks slower than it needs to be.

Could you rephrase what you are aiming to accomplish? You want it to output a pulse when an item is added to the chest, but only if x amount of time has passed since the last addition? Or do you want it so every x seconds, it checks if the chest contents have increased or decreased?

The Lone Wolfling · Post by **The Lone Wolfling** » Sat Oct 17, 2015 12:59 am

I want a line that is "on" (for some definition of on") for the entire time items are being added to a chest, and off otherwise.

Lupoviridae · Post by **Lupoviridae** » Mon Oct 19, 2015 12:31 pm

The Lone Wolfling wrote:I want a line that is "on" (for some definition of on") for the entire time items are being added to a chest, and off otherwise.

Check the smart mining drill setup (also in this thread). It currently only produces a signal if x amount of time (configurable) has passed since an item was added to the chest. The setup can be easily inverted to produce a signal only if an item has been added recently. It works by introducing a unidirectional clock element. The count is reset to 0 each time an item is added. If the count ever goes over x, a signal is produced (or in your case, shut off). The leading edge of the signal shows instantaneous response to something placed in the chest, through the falling edge will have a slight time delay.

Are you expecting the chest to be filled rather irregularly in short bursts? Such as items delivered by train or some such?

The Lone Wolfling · Post by **The Lone Wolfling** » Mon Oct 19, 2015 3:49 pm

I saw the smart mining drill, but it doesn't do what you think it does:

Lupoviridae wrote: Together, this setup outputs a green signal when the box has remained empty for more than 5 seconds (aka both drills are dry).

I want an output indicating when the number of items is increasing.

And yes, this is part of a smart train station.

(Actually, ideally what I want is a signal that changes as soon as possible after either the chest is full or the number of items isn't increasing, while remaining steady while items are being added by a fast inserter. The other edge isn't as critical.)

Lupoviridae · Post by **Lupoviridae** » Mon Oct 19, 2015 5:48 pm

The Lone Wolfling wrote:I saw the smart mining drill, but it doesn't do what you think it does:

I want an output indicating when the number of items is increasing.

And yes, this is part of a smart train station.

(Actually, ideally what I want is a signal that changes as soon as possible after either the chest is full or the number of items isn't increasing, while remaining steady while items are being added by a fast inserter. The other edge isn't as critical.)

As it is formulated for the drills, no it doesn't do what you are looking for, but it can with a few additional elements.

If I can figure out exactly what you are trying to do I can provide the template. Basically you want signal A to be output while the train is being unloaded, and a quick switch to signal B when the train is empty (or leaves) or the chest is full; is this correct?

Edit: If this is right, check out this thread about belt counters.
https://forums.factorio.com/forum/vie ... =8&t=15014
Basically what I would suggest is set up a counter (which produces a pulse of signal each time a NEW item is added to the associated chest) for items coming directly out of the train. Have this chest feed into your storage chest instead of onto a belt. Instead of using the pulsed signal to count the items, make a unidirectional counter (similar to the smart mining drill setup) that resets each time it receives that pulsed signal. Basically, if you look at u/DOSorDIE's post showing the combinator layout on the first page, the only thing that needs to be changed is the top left combinators.

1) Change the decider from [If Blue == 0, output everything (input count)] to [If green == 0, output everything (input count)].
2) Change the constant combinator just right of this decider to output a constant Blue == 1.
Now the decider will count up the blue signal ad infinitum, until it receives a pulse of green signal, which only occurs if a new item is placed in the counter chest.
3) Attach another decider's input to the output of this counter, with [If Blue > 60, output Yellow == 1]
Yellow signal should only be output if the chest is full or not currently being filled, with about a 1s delay behind real-time. I believe this is what you want. You can probably even drop the delay down a little bit (maybe to if blue > 40), since your pulsed signals should be coming every .5s (30 ticks) or so.

Furthermore, since the items will be drawn form a cargo wagon the inserter movements should be concerted, meaning you should only need one "line" of the combinators shown in the counter setup, so long as you connect the counter chests together by red and green wire, and the secondary smart inserters together by green wire. This means a total of about 7 combinators for the whole setup. Sorry if this is confusing, let me know if you'd like me to build it in-game to show you what I mean.

The Lone Wolfling · Post by **The Lone Wolfling** » Mon Oct 19, 2015 10:54 pm

That's basically what I have now, only slower and bulkier. I was hoping to streamline it and/or make it faster.

Yes, that's essentially what I want. An interesting twist, however, is that the "are chests being filled" part has to wait for signal A to be high (coming from a train detector) - and that's on the critical latency path. Otherwise the train will arrive and immediately leave before the detector has a chance to trigger.

Lupoviridae · Post by **Lupoviridae** » Mon Oct 19, 2015 11:20 pm

The Lone Wolfling wrote:That's basically what I have now, only slower and bulkier. I was hoping to streamline it and/or make it faster.

Yes, that's essentially what I want. An interesting twist, however, is that the "are chests being filled" part has to wait for signal A to be high (coming from a train detector) - and that's on the critical latency path. Otherwise the train will arrive and immediately leave before the detector has a chance to trigger.

What I outlined above can turn the signal on immediately on arrival of the train, and shut off 0.6s after the train leaves or the chest fills. You aren't going to get much faster. Fast inserters take about .5s to complete a turn, so you need to wait at least that long before the signal can shut off. If you really want you can probably cut out a few combinators by using XKnight'sflow counter design I think.

Lupoviridae · Post by **Lupoviridae** » Mon Oct 19, 2015 11:59 pm

Just tested this, and it works perfectly.

: Capture.PNG (724.3 KiB) Viewed 21556 times

Managed to get the falling edge of the signal 0.5s after the last item was removed from the train. A full rotation of an inserter is actually 0.426 seconds i believe, so this is pretty literally as responsive as possible. Check out the save.

Keith5.zip: (4.26 MiB) Downloaded 427 times

Dump a bunch of items into the cargo wagon and watch the light turn on instantly. The moment the cargo wagon is empty, the light shuts off. The same also occurs if the iron chest fills up or the train leaves.

Have I met the challenge?

The Lone Wolfling · Post by **The Lone Wolfling** » Tue Oct 20, 2015 4:22 pm

Unfortunately, it doesn't work perfectly.

It doesn't work when the output is clogged - the train won't unload even though there's plenty of space.

It also continues counting needlessly when the train isn't unloading.

It also doesn't have the "wait for train to arrive" part, unless I'm missing something.

Lupoviridae · Post by **Lupoviridae** » Tue Oct 20, 2015 5:38 pm

The Lone Wolfling wrote: It doesn't work when the output is clogged - the train won't unload even though there's plenty of space.

If by "the output is clogged" you mean the detector (smart chest) has something in it, this is intentional. It allows the storage chest to fill up (the iron chests in this case). The smart chests are not intended to fill up, they just convey the signal that "something has just been unloaded".

The Lone Wolfling wrote: Actually, ideally what I want is a signal that changes as soon as possible after either the chest is full or the number of items isn't increasing, while remaining steady while items are being added by a fast inserter. The other edge isn't as critical.

Pretty sure this is exactly what you asked for. No signal if the storage chest is full, aka "the output is clogged".

The Lone Wolfling wrote: It also continues counting needlessly when the train isn't unloading.

I'm guessing you mean the unidirectional clock elements. Again, intentional. Them counting up doesn't affect the final signal you are trying to produce. They reset when the train arrives once more. Basically these count the time since the last item was unloaded from the train into storage. When the train is away, yes, this number gets pretty high. Unidirectional clocks are essential if you want to create a combinator setup that uses tick-level timing.

The Lone Wolfling wrote: In other words, a circuit that will output only when a certain configurable amount of time has passed since the last time the input was triggered.

How do you expect to trigger "when a certain configurable amount of time has passed", unless you are counting how much time has passed?

The Lone Wolfling wrote: It also doesn't have the "wait for train to arrive" part, unless I'm missing something.

The light turns on almost immediately when the train arrives. This setup produces a constant signal only if a train is present and being actively unloaded. What else were you looking for? As far as I can tell this does what you asked for with the minimum possible delay (.492 seconds on the rising edge, .5 seconds on the falling edge).

Edit: To get your constant signal, you will need to replace the light with a combinator set to produce a signal when Blue < 30 (like the light is currently set). Sorry if this wasn't clear.

goku90504 · Post by **goku90504** » Mon Nov 23, 2015 2:05 am

what version is this from? I recently bought the game (in the last week or two) and I've got a free play game where I've done all the research but I don't have access to a few items mentioned in the wiki such as the combinator's or the personal roboport

Xeteth · Post by **Xeteth** » Mon Nov 23, 2015 1:04 pm

goku90504 wrote:what version is this from? I recently bought the game (in the last week or two) and I've got a free play game where I've done all the research but I don't have access to a few items mentioned in the wiki such as the combinator's or the personal roboport

I am guessing you are running on version 0.11.x - you need to update to the 'experimental' branch (that is pretty much what everyone uses and is currently more or less the stable 0.12 release), this can be done under settings; something like "Enable experimental updates".

phi1010 · Post by **phi1010** » Mon Aug 22, 2016 10:12 pm

viewtopic.php?p=94729#p94729

XKnight wrote:Today I rewatched my previous memory cell, and I found that it is also complex and not optimal.
Update:
if ["0" signal = 1] it remembers input value
if ["0" signal > 1] it clears the stored value
So, you can use it only with ["0" signal = 0 or 1] as a memory cell.

=1 vs >1 is not the same as
=1 or =0

1/0 seems to work; 1/2 does not.
1/0 causes the internal trigger signal value to count up, and cause an integer overflow, if you store the value too long.

The factorio Lua API describes the signal count to be an uint (usually 0--4.294.967.295, that would make about 2,2 years in real time), but since factorio allows negative values, I suspect the actual lifetime of your memory to be half of that.

XKnight · Post by **XKnight** » Mon Aug 22, 2016 10:43 pm

phi1010 wrote: 1/0 causes the internal trigger signal value to count up, and cause an integer overflow, if you store the value too long.
The factorio Lua API describes the signal count to be an uint (usually 0--4.294.967.295, that would make about 2,2 years in real time), but since factorio allows negative values, I suspect the actual lifetime of your memory to be half of that.

I am 100% sure that you've made some mistake, take a look more attentively.
Triger signal will never count up

(It is even visible on the movie - combinators blink only when input signal is updated)

Movie

Blueprint

phi1010 · Post by **phi1010** » Tue Aug 23, 2016 12:57 am

XKnight wrote:(It is even visible on the movie - combinators blink only when input signal is updated)

We might be talking about different designs.

The movie shows ">" and "<" combinators; the image in the linked post (viewtopic.php?p=94729#p94729) shows "=" and "<", doesn't seem to be the same.

EDIT / PS: The Blueprint shows me "=" and "<" too... that neither seems to go together with the gif.

XKnight · Post by **XKnight** » Tue Aug 23, 2016 1:36 am

phi1010 wrote:
XKnight wrote:(It is even visible on the movie - combinators blink only when input signal is updated)
We might be talking about different designs.

The movie shows ">" and "<" combinators; the image in the linked post (viewtopic.php?p=94729#p94729) shows "=" and "<", doesn't seem to be the same.

EDIT / PS: The Blueprint shows me "=" and "<" too... that neither seems to go together with the gif.

Yeah, perhaps I recorded video with "> 0", but lately decided to switch it back to "= 1" (why? I don't know

).
But results are the same in both cases

phi1010 · Post by **phi1010** » Wed Aug 24, 2016 1:31 am

XKnight wrote:
phi1010 wrote:
XKnight wrote:(It is even visible on the movie - combinators blink only when input signal is updated)
We might be talking about different designs.

The movie shows ">" and "<" combinators; the image in the linked post (viewtopic.php?p=94729#p94729) shows "=" and "<", doesn't seem to be the same.

EDIT / PS: The Blueprint shows me "=" and "<" too... that neither seems to go together with the gif.
Yeah, perhaps I recorded video with "> 0", but lately decided to switch it back to "= 1" (why? I don't know ).
But results are the same in both cases

Eh... i know i'm evil... the movie and blueprint still have another (probably insignificant) difference to the image from the earlier post: movie and blueprint connect the input data ("1" and "0") to both combinators, not just the trigger signal... the image did not...

I might have caught your circuit (the one from the still image) on the wrong foot, providing quick input while still building it and making a mistake somewhere, and causing it to start counting that way... I don't see how I got it to count up, but my excel sheet tells me that the correct version is unstable anyways until the output has reached the value 1 for the trigger signal type. This happen's as soon you trigger the signal for two ticks in a row. If you don't reset the circuit before using it, it shouldn't be able to remember anything for more than one tick -- as almost every combinator does... well, maybe not the y=x*0-combinator

Tell me if I'm wrong... please don't, i've checked twice. =D

Blueprint

For anyone who'd like to know what actually happens:

Numbers

Localized Formuals

XKnight · Post by **XKnight** » Wed Aug 24, 2016 10:31 am

phi1010 wrote: I might have caught your circuit (the one from the still image) on the wrong foot, providing quick input while still building it and making a mistake somewhere, and causing it to start counting that way... I don't see how I got it to count up, but my excel sheet tells me that the correct version is unstable anyways until the output has reached the value 1 for the trigger signal type. This happen's as soon you trigger the signal for two ticks in a row. If you don't reset the circuit before using it, it shouldn't be able to remember anything for more than one tick -- as almost every combinator does... well, maybe not the y=x*0-combinator

Tell me if I'm wrong... please don't, i've checked twice. =D

Yes, you are right, but I would like to call this an "initialization phase", where you should manually check if this memory cell is ok or not.
So, at first you shuild build this cuircuit, then you should manually send trigger signal for 2 ticks and intilization phase will be finished.
After that memory cell will be able to record any signals with 1 tick duration.

Factorio Forums

Combinator Contraptions

Re: Combinator Contraptions

Re: Combinator Contraptions

Re: Combinator Contraptions

Re: Combinator Contraptions

Re: Combinator Contraptions

Re: Combinator Contraptions

Re: Combinator Contraptions

Re: Combinator Contraptions

Re: Combinator Contraptions

Re: Combinator Contraptions

Re: Combinator Contraptions

Re: Combinator Contraptions

Re: Combinator Contraptions

Re: Combinator Contraptions

Re: Combinator Contraptions

Re: Combinator Contraptions

Re: Combinator Contraptions

Re: Combinator Contraptions

Re: Combinator Contraptions

Re: Combinator Contraptions