Factorio Forums

Hello again,

for one of my factories I needed a timer that is able to reset itself if a trigger occurs while the timer is still running. That is the result:
An Item moves over the Trigger and triggers one tick of its content. In this case red bottle x1. The Init Value combinator multiplies it by 200. That is the timer's start value. So it should count to zero in about 3 seconds (one tick = 1/60 second). For now we have 200x red bottles. At the Gate the 200x red bottles get summed up by the Remainder's output value. It contains always the negated value of the counter. So if the timer is at 150 the remainder is at -150. The Gate triggers the signal for one tick which starts the counter and makes sure that the counter doesn't get flooded by the remainders value. As this is our first run-through the remainder is at 0. So 200 gets passed to the counter. Now the counter feeds itself with its by 1 reduced output until it reaches zero. When at zero the signal gets deleted by the game rule (0 = no signal). So it cannot run negative.
But on the second run-through the timer is at.... lets say 80. So 2 seconds have passed. This time the remainder is at -80 (as the timer is at +80). Both signals get summed up at the gate (200 + (-80)). 120 is the new value that gets passed to the timer. So 80 (timer) + 120 and we are at 200 again. As already mentioned, the timer is flood save. No problems if many items trigger the timer quickly.

Probably you have some use for it. I used it for a smart stack inserter which is placed 2 belts behind the trigger in front of an underground belt which unfortunately cannot be connected to a circuit network. But that way the belt trigger can still set the filter of the inserter and be sure that the item gets picked up as the filter signal is extended by some ms.

It's really simple to build. But if you prefer the blueprint string, just tell me.

Greetings

Nice build! I really like the things you are making. Keep going!

You can do this with 2 combinators instead of 4:

Conveyor belt -> arithmetic combinator (Each * 200 -> Each) -> arithmetic combinator (Each - 1 -> Each) [feed back] -> output

The "remainder" and "gate" combinators effectively do nothing in your circuit (or maybe I did not understand what exactly you need it for, it's possible )

(Edit: I get it now, you want the timer to refresh to 200 and not extended with additional items. Is this only to extend the filter signal for the inserter? I'll try to find a simpler solution for this.)

Edit 2:

I've made a 2-combinator solution for your problem (and it's not timing dependent at all):
The right combinator does "Each > 0 => Each (input count)" (it's a register that remembers any item that has passed the belt detector).
The left combinator does "Each * -1 => Each" (value inverter).
The filter inserter is set to "Read hand contents (pulse)" and of course "Set filters".

When an item passes the belt, it will get remembered by the register (indefinitely), and be used as the filter value for the inserter. When the inserter grabs items, they get subtracted from the register again (it will eventually get cleared when no new items arrive).

If there are too many different items on the belt then this will fail (but your solution, too), because there is only 1 slot and there is currently no way to influence which signal get chosen as the current filter value.

Thanks for your input. I know your posted solution. I am using it in some of my factories. Especially for counting items on transport belts (loading/unloading).
But this time I needed a timed solution as I can not guarantee that the inserter will grab the item on the transport belt. See the screenshot below:
This is my newest project. But it is not ready yet for presentation (needs more optimization). This factory contains one huge circular belt with multiple lanes to transport every item. Think of a highway as the circular belt and its exits are the factories requesting the items. In fact that is the drone logistic network without drones
It's not effective as with drones, but its fun to implement

So to the problem:
The 2 purple filter inserters grab items from the underground transport belt. The filter is set by the delayed signal from the sensors in front of the underground belt. As I do not know if the inserters grabbed the item I need to reset the filter when the item has passed the inserter so the next item type can be set. I have chosen 40 ticks for the yellow transport belt. After that the item has been grabbed or skipped.
Another problem is that I usually have to use this combinator group for every single inserter, because they need to set their filters individually. That means for 8 multiple lanes, or 8 inserters I will need 8 * 4 combinators. But thats really too much.
I have set them in parallel mode now. So both get their filters by one of the sensors. Downside... if a copper plate arrives on the left belt and a gear-wheel at the same time on the right belt only one item type gets grabbed because both filters receive the same filter signal.

I hope I desribed the problem well enough.

So what I need is single signal extender for every lane individually. But I hope I will find a solution as I play further. Everyday I have new ideas of how to optimize things there. So I guees I just need more nights of sleep =)

OK, I guess a timer circuit is the best you can do in a situation where you do not know if the item gets grabbed.

Only, I do not understand why the filter inserter would fail to grab the item. The only reason why this could happen is because it already has another item in its hand, or because the filter has been set too late.

If you set the filter in time, the inserter will never fail to grab the item, and therefore, the register-counting solution should work.

How do you reproduce the case where the inserter actually does not grab the item it's supposed to?

For example if two items in a row arrive at the sensor belt. The first item gets grabbed and while the inserter is moving that item, the second item will pass by.

feng wrote:For example if two items in a row arrive at the sensor belt. The first item gets grabbed and while the inserter is moving that item, the second item will pass by.

OK, that makes sense. I forgot that it's an underground belt, so the items actually move past the inserter.

However, what you can do is make the register only count "1" or "0", and not the precise item count. So the register will make the inserter grab any number of "X", which will reset the filter. Since the inserter always moves at least 1 item, this should work. You could still get the precise count of items that have actually been moved from the inserter hand count.

Edit: I've just tried that approach -- like described above, with the register outputting "Count 1" instead of input count -- and it works.

Sorry for thread necro, this was one of the first results on google, and I found a nice solution that I'd like to share.

The wiki mentions a self-resetting clock can be made out of a decider combinator by attaching it's output to it's input. It describes how you can make the clock/timer reset when the timer value reaches a certain value, but actually, you can use whatever condition you like. Just remember that it's the condition to keep incrementing the clock. When it is NOT true, the decider doesn't output it's input, and the signal is reset to the constant combinator's output.

So, for the OP's example, they could have "red bottle = 0" as the condition. Using the setup in the image I shared the "0" signal is just the number of ticks since a red bottle was last seen. If you need it to reset after some time OR when the red bottle is seen, you can add an additional decider combinator to output a red bottle signal once the "0" signal goes over some threshold value.

I have a variation on the timer to share.
This one is a count down timer: For actual use, the inserter would be inserting science packs from the chest into a lab rather than another chest, but this is the setup I used to create and debug.

The use case is wanting to know when I am doing research, leading to increased power use to create the science packs, so I can start ramping up power before it is needed to build the science pack inputs.

On searching the reddit and the forums, I didn't find exactly what I wanted, and a lot of it was short on explanation (the better to force me to figure it out myself). Many thanks to GopherAtl for viewtopic.php?t=14556, it was most helpful after I had gone through the wiki! I am including the explanation in the hopes that it will help others who are just learning what can be done with the circuit network.

On the right is a simple latch:

• S (latch set) when the inserter grabs a red science pack; the inserter is limited to a stack size of 1, so it never grabs more than one red science pack at a time.
• R (latch reset) when the timer counts down to three (more on this later); and
• the latch itself which reads S and R, and outputs S=1 whenever S>R.

On the left, from the top down:

• The constant combinator contains a value for M, the number of minutes for the timer, in ticks. So for example, one minute is 60 seconds x 60 ticks per second or 3600. M also includes a fudge factor, in my blueprint 50 ticks (more on this later, too).
• Arithmetic combinator W: calculate the difference between M and the current timer value T, W = M-T. This is the value that may be needed to set, or reset, the timer back to M.
• Arithmetic combinator V: this is the reset value if it is needed; that is, if the timer is being set, or reset: V = W x Red science pack. This sets V to zero if the timer is not being set or reset.
• Arithmetic combinator D: this is the value to decrement the timer; it is only active if the latch is set: D = S x -1.
• Arithmetic combinator A: this is the actual amount to modify the timer: A = V + D.
  • When the timer is set, V will be M, and D will be zero.
  • When the timer is running, V will be zero, and D will be -1.
  • When the timer is reset, V will be W (M-T), and D will be -1, giving A = M-T-1 instead of M-T, hence one reason for the fudge factor.
  • When the timer is not running, V, D, A, and T are all zero.
• Arithmetic combinator T: The timer! T = T+A.

This timer has a cycle delay of three cycles, both when the timer is set, and when time runs out. This is why the latch reset is set to T=3, so when the cycle runs out, T is down to zero. This is a second reason for the fudge factor.

• On the first cycle, W is read, and V is written.
• On the second cycle, V is read, and A is written.
• On the third cycle, A is read, and T is written.

The final reason for the fudge factor is that my chests contain all 7 science pack types, so there is no guarantee of the order in which the science packs will be loaded. The maximum delay is when the red science pack is loaded first on one pass, and loaded last on the next pass. Which if I have done the math correctly, is (2 x 7 x 3)-1, or 41 ticks. 41+3+1=45, rounded up = 50.

Enjoy (or as my granddaughter would say: TA DA)

Copy blueprint