Combinator Clock Help
-
Bleefulblorf
- Manual Inserter
- Posts: 3
- Joined: Sun Dec 03, 2023 8:32 am
- Contact:
Combinator Clock Help
Hello, I have 4 crafters for each science pack that are each capable of crafting 1 pack per second. For precision purposes I have each crafter’s inserter on a 1 second timer, in order to output exactly 4 of each pack per second. I also have each inserter displaying its contents by pulse. I want to create a combinator clock system connected to a light so that if an inserter does not pulse (as in it failed to provide a science pack), the light turns on or off, notifying me that there is some delay/shortage. My idea was to put the intended combined pulse of 4 into an arithmetic combinator and multiply by 15, yielding 60, then feed that 60 into another combinator subtracting 1 per tick, and having the light be on if the value is >0. If all crafters output on time, the light would remain on. If not, it would blink. However, my system of wiring the combinators did not work as intended and after over an hour of fiddling, I could not get it to work. Could someone help me with this clock, or recomend me an entirely better system instead? Thanks.
Re: Combinator Clock Help
You have told us no details of what went wrong, and you didn't share a blueprint of your setup so it's impossible to diagnose issues ourselves.Bleefulblorf wrote: ↑Sun Dec 03, 2023 8:54 amHowever, my system of wiring the combinators did not work as intended
Re: Combinator Clock Help
I tried to follow literally the description of the machine and ended up with 2 variations :Bleefulblorf wrote: ↑Sun Dec 03, 2023 8:54 amI want to create a combinator clock system connected to a light so that if an inserter does not pulse (as in it failed to provide a science pack), the light turns on or off, notifying me that there is some delay/shortage
1) 4 inserters are transfering science packs from 1 infinity chest filled with science pack, to another one to void them on timer of 1 per second.
If a cycle is missed by 1 of the inserter it light up a lamp and it increment a memory. So if you miss 10 cycle because no red science pack for 10 second, the lamp will stay "lit" untill you spend 10 cycle without problem.
2) Same setup, but this time the lamp will turn off as soon as the red science pack supply resume
I do not think it is the optimal solution regarding the number of combinator, especially the 2nd version but maybe it fit your need or help you make your own ?
I don't see how to make it work with the multiplication by 15 and removing 1 per tick. I don't understand when you want the lamp to turn on and off maybe ?
Re: Combinator Clock Help
Don't just put together some parts and start to work with this.
Instead, first describe your task in general, without a specific circuit in mind. What do you want to achieve?
From your description, I see you want to do this:
- You have a production line that produces one sort of item that ends up at some belt. Every second, you want to use an inserter to transfer one item to a different belt, so the factory behind it gets one item every second.
- If there is an item not available for transfer after one second, a lamp should light up. If an item was transferred, the lamp should stop lighting.
-You actually have 4 production lines with 4 different items and 4 inserters, so we will develop the requested circuit for 1 item, then build 4 copies of it.
We start with a timer that counts from zero. We use signal C for counting.
- create the timer with one decider combinator and one constant combinator
- set C=1 in the constant combinator
- connect the constant combinator to the input of the decider combinator
- create the counter loop by connecting the input of the decider combinator with its output (same color as the wire to the constant combinator)
After 1 second, our timer C counted 60 times, so this is our signal for the inserter to activate as well as for the signal for the lamp to light up.
- so we configure the inserter with this activation condition: C >= 60
- and we configure the condition in the lamp with one tick later: C > 60
This way the lamp lights up whenever an item should be transferred (we will slightly change that later), and the inserter activates.
- now we additionally configure the inserter to report its hand status as pulse, so it can be used as counter reset
- in the decider combinator, we set the condition to <item>=0 and output to C (input count)
This way the condition is true and counter will count as long as there is no item reported by the inserter. As soon as the inserter pulses an item, the decider condition is false and the counter resets to 1. (actually 0, but we get 1 because the 1 from the constant combinator is always added)
- also set the inserter stack size to 1 to make sure the inserter always only picks up only 1 item.
And that's it in general.
However, there are small things to improve. First, the lamp flashes every time, even if there is an item available. This is due to the latency. If the inserter is activated, it takes some ticks for it to actually grab an item and report that to the circuit and then for the timer to reset. It's about 5 ticks if using a yellow belt. So to actually taking 1 item every 60 ticks, we need to activate the inserter a few ticks earlyer. Reset the inserter condition to C >= 55.
The lamp will still flash once in a while, seems to depend on where on the belt the item appears - sometimes the inserter needs even more time.
So I increased the lamp condition to C > 63, and no flashing any more.
To visualize the different lamp conditions, I added 2 lamps: one yellow that indicates when exactly 1 second passed and the timer is due (C > 60), and one red that indicates when the inserter wasn't able to grab an item in time (C>63).
In case you want to additionally synchronize the different items and make sure that everything is halted if there is one item stalled, you can control the moving belts. This is a completely different approach. It works by counting the pieces on each belt.
Each lane stores up to 4 pieces. So we read the content of one belt, for each item, hold mode. With a decider combinator, we count the items where there are 4 items or more, and output C=1 for each match. Condition: EACH >= 4, output: C=1.
This will output the number of belts that have a full lane of items. If this is true for every of our 4 belts, we activate all belts with the next belt piece, so one item of each type is let through. If this is not true for every belt, the next piece belt piece is deactivated for all belts, and all items are stalled.
So the whole contraption waits for 4 items present on each lane, then activates. If there are less than 4 pieces, all belts are halted.
Instead, first describe your task in general, without a specific circuit in mind. What do you want to achieve?
From your description, I see you want to do this:
- You have a production line that produces one sort of item that ends up at some belt. Every second, you want to use an inserter to transfer one item to a different belt, so the factory behind it gets one item every second.
- If there is an item not available for transfer after one second, a lamp should light up. If an item was transferred, the lamp should stop lighting.
-You actually have 4 production lines with 4 different items and 4 inserters, so we will develop the requested circuit for 1 item, then build 4 copies of it.
We start with a timer that counts from zero. We use signal C for counting.
- create the timer with one decider combinator and one constant combinator
- set C=1 in the constant combinator
- connect the constant combinator to the input of the decider combinator
- create the counter loop by connecting the input of the decider combinator with its output (same color as the wire to the constant combinator)
After 1 second, our timer C counted 60 times, so this is our signal for the inserter to activate as well as for the signal for the lamp to light up.
- so we configure the inserter with this activation condition: C >= 60
- and we configure the condition in the lamp with one tick later: C > 60
This way the lamp lights up whenever an item should be transferred (we will slightly change that later), and the inserter activates.
- now we additionally configure the inserter to report its hand status as pulse, so it can be used as counter reset
- in the decider combinator, we set the condition to <item>=0 and output to C (input count)
This way the condition is true and counter will count as long as there is no item reported by the inserter. As soon as the inserter pulses an item, the decider condition is false and the counter resets to 1. (actually 0, but we get 1 because the 1 from the constant combinator is always added)
- also set the inserter stack size to 1 to make sure the inserter always only picks up only 1 item.
And that's it in general.
However, there are small things to improve. First, the lamp flashes every time, even if there is an item available. This is due to the latency. If the inserter is activated, it takes some ticks for it to actually grab an item and report that to the circuit and then for the timer to reset. It's about 5 ticks if using a yellow belt. So to actually taking 1 item every 60 ticks, we need to activate the inserter a few ticks earlyer. Reset the inserter condition to C >= 55.
The lamp will still flash once in a while, seems to depend on where on the belt the item appears - sometimes the inserter needs even more time.
So I increased the lamp condition to C > 63, and no flashing any more.
To visualize the different lamp conditions, I added 2 lamps: one yellow that indicates when exactly 1 second passed and the timer is due (C > 60), and one red that indicates when the inserter wasn't able to grab an item in time (C>63).
- Screenshot 2023-12-03 205045.png (104.71 KiB) Viewed 546 times
In case you want to additionally synchronize the different items and make sure that everything is halted if there is one item stalled, you can control the moving belts. This is a completely different approach. It works by counting the pieces on each belt.
Each lane stores up to 4 pieces. So we read the content of one belt, for each item, hold mode. With a decider combinator, we count the items where there are 4 items or more, and output C=1 for each match. Condition: EACH >= 4, output: C=1.
This will output the number of belts that have a full lane of items. If this is true for every of our 4 belts, we activate all belts with the next belt piece, so one item of each type is let through. If this is not true for every belt, the next piece belt piece is deactivated for all belts, and all items are stalled.
So the whole contraption waits for 4 items present on each lane, then activates. If there are less than 4 pieces, all belts are halted.
- Screenshot 2023-12-03 205255.png (263.29 KiB) Viewed 546 times
Re: Combinator Clock Help
Hey hijacking your explanation to point out that this is the reason in my previous blueprint that a decider combinator is set to detect when A = 3 , that is because of the same latency between the moment the inserter is activated and the moment it can send a pulse to tell what's in its hand, except as it's taking from a chest, the delay is not about 5 ticks, but rather 2.
When A=1 inserters are set to activate, and when A= 3 their content is added to a constant combinator that has -1 for each science pack, so that should yield a pulse with no science pack signals, unless an inserter failed to pick 1, in such case it send a -1.
Also wanted to say that i would advise OP to start use your blueprint as mine is more the result of some fiddling rather than as you describe, the ability to formulate the problem i'm facing in an abstract way and choosing amonsgt the possibilities offered by combinators the one that suit it the best. I started with some inserters and adding things here and there until it worked using techniques that's i'm familiar with because i like launching the game and get a thing going instead of taking time to think about what i'm going to do in the game beforehand.
Looking at it now, i realize i inverted the conditions when the lamp is lit, it is always off except to show a problem, whereas it should have been always on, except when there is a delay, it would blink.
worse i had forgotten this
Re: Combinator Clock Help
After I developed the 1 second timer and copied it 4 times, it dawned to me @Bleefulblorf might have had a different thing in mind than I originally thought: may be he wanted to synchronize the 4 belts in the first place so the lab area always gets an equal share of packs. And to indicate one pack is missing, for more than a second, he wanted to light a lamp.mmmPI wrote: ↑Sun Dec 03, 2023 8:46 pmAlso wanted to say that i would advise OP to start use your blueprint as mine is more the result of some fiddling rather than as you describe, the ability to formulate the problem i'm facing in an abstract way and choosing amonsgt the possibilities offered by combinators the one that suit it the best.
Synchronizing a number of belts is a non trivial thing. You came up with some complex wiring nobody will understand. I had this problem before, and I did such complex thing before, so I know this. This idea with "I increment counters for all items coming in, and decrement when they're going out, so in general the counters are always zero. In case a counter is bigger than some threshold, for example 5, I halt the belts that are above the threshold, so the system waits until enough items passed through so the counter is back below the threshold".
I forgot what I was doing the next day, and it didn't always working correctly, and I wasted more time.
Then I realized I needed a different approach and I came up with that simple belt detector+controller in the second screenshot. Sometimes you really need to forget what you did before and think fresh - just not approach it the same way as before.
I even invented that for same purpose as the OP - equal feeding of my lab area. The sushi belt that was feeding the labs became clogged, if there wasn't equal feeding. (In the end, the real solution for everything was not the circuit balancer. It was to get rid of the sushi belt for the labs. Most simple solution and multiple cases solved forever. No circuits, no complex repairing of what wasn't completely working as intended)