intermediate circuitry in factorio part 1: Flip Flops and Latches!
Вставка
- Опубліковано 28 лип 2024
- This is the first follow up to my basic overview in factorio circuitry.
I will be talking over Flip-flops and latches today and illustrating such with practical examples.
I know, there's more to intermediate circuit creations than just this current subject but i had to split the rest into their own separate videos to make talking over it more digestible.
part two: • Memory Cells in Factor...
Chapters:
00:00 intro
00:24 subject today
01:03 theory
02:18 scenario 1 problem
02:50 wiki info
02:58 scenario 1 breakdown
04:35 memory cell interlude
05:10 scenario 2 problem
06:05 scenario 2 buildup
07:07 scenario 2 demo
07:33 scenario 2 breakdown
09:17 latch comparison
09:40 wiki info
10:00 survival example and outro
Anyway, here are the links that i mentioned:
RS latch 1: wiki.factorio.com/Tutorial:Ci...
RS latch 2: wiki.factorio.com/Tutorial:Co...
music used:
Super Mario Odyssey - Bonneton
Super Mario Odyssey - Caves
Super Mario Odyssey - Run, Jump, Throw! 2
Super Mario Odyssey - Shop
background art layers from: cdn.factorio.com/assets/img/a...
and: cdn.factorio.com/assets/img/a... - Ігри
very clear and understandable. more circuit videos please🎉
follow-up to this part is already in the making 👍
i already knew about sr latches but the simplified version with the arithmetic combinator has blown me away! a combinator saved is a combinator earned after all :) +like!
Ah this explanation is understandable, I thank you. This is so much better then the wiki.
Glad it was helpful!
I used a work around when I couldn't remember how to make a latch where one inserter stores an placeholder item in a chest when item y drops to x amount and while the placeholder item is in the chest another inserter adds the missing item to wherever it's needed/being counted, until a third inserter hits the cutoff and removes the item onto a conveyor going back to the first inserter.
The only reason I needed it was to regulate items on a giant sushi belt and, for that, it seemed to work.
that's also a pretty reliable way to get the same logic without using combinators. The only thing that could lead to de-sync when using such a setup is the small priming time for the placeholder item to make its way back on the conveyor belt but overall not that big of a deal if timings aren't critical.
Very awesome video!! I can see a lot of uses for this.
Great video and explanation.
Immensely helpful, thank you
I'm looking forward to watching this later. Thank you for the video.
I am embarrassed at how bad I am at circuits. But I guess it's a mental brownout. I am bad at them so I avoid them and my brain doesn't get any coal to get better at circuits.
don't worry about it, we all started at 0 with circuits, myself included👍
i might still not understand circuits but it's definitely on me because this was explained clearly and concisely.
the diagram on sr latches was really good but it was hard for me to tell the difference between the "on" and "off" colours. i only noticed the difference cos i knew what an sr latch was and was expecting them to change, very informative video otherwise so i wanted to let you know
yeah, when looking at it in hindsight, illustrating on/off with two different colors would've been the smarter way 🤔...
Note for future me:
What you want to see is at 3:30. S is the starting condition, R is the stop condition, S can be equal to 2 for a short time at the 3rd combinator input, but it does not break anything.
neat. the first example is exactly why i'm here.
edit: unfortunately it seems to be unusable in my scenario, but still a good video.
Seeing this step by step was definitely helpful. Im sure ill find a use for- oh, oh hi space exploration, uhm... no, no i wasnt avoiding you! Hey, i gotta go, i hear theres this "grass" stuff i should touch sooooo bye!
I like your funny words, magic man.
I use a different 3 combinator latch design because I have a few small issues with the one shown.
First when the set and reset signals are simultaneously received the output is depends on the state the circuit was in prior. The memory cell was empty when both signals become true the output will be 0, if the memory cell was already latched when both S&R are occurring then it will remain latched.
In order to overcome this flaw I use 2 decider and 1 arithmetic for my 3 piece latch. Both deciders' inputs are wired to the greater world with red. Decider 1: outputs S=1 when input signal meets condition, output is wired to inputs of of both other combinators with green. Decider 2: outputs S=S(in) while reset condition is not true or as I like to call it continuing condition is true, output is wired to arithmetic with red. Arithmetic is defined as S/S output to S, output is wired to decider 2 with red and to device that responding to the S signal.
I'm not quite sure how you would get into the scenario, where both set and reset signals are simultaneously sent to the latch. could you possibly tell me how exactly this could be replicated?
The only possible way that i could think of ATM is a de-sync where the latches input combinators react to changes in the red network on different frames. based on my example, i would not categorize the resulting error mechanic as a flaw inside the latch itself but as a result of misapplying the wires of the latch construction in an unfitting way.
despite that, if i understood it correctly your proposed version of a latch could definitely handle this de-sync scenario.
@@center_pivot The latch I use comes from situations where the set signal and the reset signal are not on the same channel. For example set condition of A>10 and reset condition of B
This extra information definitely helped out a lot to grasp the underlying situation 👍.
I'm still not quite why you're sending all trains back to the reloading stations when just one runs out of ammo but i bet that there's a good reason for it or i misunderstood something lol.
I really need a second part D:
will be done next week. probably...maybe...
Is it possible to setup the second version with a universal input? It seems it's locked to the input that it was set to work with. The first one has the benefit of working correctly with the "everything" and "anything" settings.
I need a way to store a clock state so I can interrupt it and resume from where I left off. Below is the TLDR, but is it possible to do this with an SR latch or what would be required instead?
TLDR: I have a clock in my factory that counts to 120 ticks repeatedly (equal to the cooldown of an electric miner drill). A decider combinator is attached to it that sends an enable signal to a belt leading up to a drill deposit for all but a small 25 tick window in that cycle. This configuration allows the drill to continue its regular contribution to the belt with minimal to no interruption even as the belt approaches 100% saturation.
However, things become a little more complicated when mining efficiency is researched because (to achieve the added efficiency) instead of simply boosting the drills contribution interval, it is given a secondary cooldown that runs slower than (and synchronously with) the first. This means that if at any point one cooldown is interrupted at elapse time by belt saturation, the other one is interrupted too. So, not only can this problem not be solved by speeding up the clock cycle, but simply adding an additional clock doesn't get us all the way there either.
Instead, you have to actually implement a way to pause clock A when clock B ceases sending go signal B, the have clock A resume from whatever state it was in at the time of interruption.
To understand this, consider the scenario where the belt is at 98% saturation, cooldown A is at 60% completion and cooldown B is at 100%. Initially, both clocks are sending a go signal so the drill cannot deposit and both cooldown counters halt. However, in this scenario clock B will cease go signal B in 70 ticks. When it does, the collective network go signal will reduce from 2 to 1 (clock A will still be sending go signal A) and the leading belt will halt for 25 ticks allowing the drill time to contribute and (crucially) cooldown A to continue approaching 100%.
Ideally, clock A would be "paused" but not "halted" while clock B ceased go signal B. This is what I am trying to achieve. The following assumes this is what happens.
Since the precise belt state at any one point is essentially random, we'll assume that precisely 12 ticks after clock B ceases go signal B the drill is able to deposit the ore from cooldown B and the remaining 48 ticks until cooldown A reaches elapse time will resume. As long as the initial state of both clocks were configured correctly, then cooldown A will reach elapse time exactly 12 ticks after clock A ceases its own go signal. Like clockwork.
Well I found a solution but it's unsatisfying simple😅. I just configured the clock to add the signal "V" to the signal "I" instead of "I" to "I". The quantity of "V" can be changed to 0 to interrupt the clock without initializing it, and changed to 1 to resume from its previous state.
Hello Centre pivot,
This is a great video. Thanks to you my power setup is now very efficient! I completely understand scenario 1, bit I'm struggling a lot with applying scenario 2 to the same power setup. In the last 3 days I must've rewatched it more than a dozen times but I'm still struggling.
Using red wire, I've connected an accumulator to a power switch, then to a decider input, and combinator output. Using green wire, I've connected decider output to combinator input. I want my setup to disconnect the powerswitch when the accumulator charge reaches 80% and reconnect at 20%. How should I set the internal conditions? Using the formula of multiplying the green signal with the difference of 80-20 (60) doesn't work. I think I'm doing something wrong.
I wanted to apply what I learnt and even used the wiki page you showed to solve this on my own. However, after the days it's like I'm banging my head against the wall.
I'd really appreciate if you could help 😬🙏
uh, everything sounds good wiring and setup wise. conditions should be 'A < 20' for both power switch and decider combinator. the arithmetic combinator then should multiply the deciders output (make sure to set it to output 'A' with value of 1) with the difference of 20-80 (other way around) which gives us 'A * -60'. if you're seeing the SR latch flicker on and off after that, scrap the compact version and go with something like this (imgur.com/a/EFEvv4E). does the exact same but synchronizes the timing of signal receipt with the action the power switch makes.
@@center_pivot this is the third fourth time I’m replying, but for some reason they keep getting deleted.
I just wanted to say thank you for the quick reply. You are indeed correct about the flicker. It worked fine on my test set up, but started flickering on my power grid. Thank you for the link. I’ll try and understand it, but will probably stick with the three Combinator version. I looked at the two Combinator version as an upgrade over the three Combinator version.
this is the third fourth time I’m replying, but for some reason they keep getting deleted.
I just wanted to say thank you for the quick reply. You are indeed correct about the flicker. It worked fine on my test set up, but started flickering on my power grid. Thank you for the link. I’ll try and understand it, but will probably stick with the three Combinator version. I looked at the two Combinator version as an upgrade over the three Combinator version.
More please!
part 2 will come 𝓈𝑜𝑜𝓃™
@@center_pivot can't wait - thanks
A covarex example would be nice!
I'll see if i can include one somehow. no promises though
Hej nice series, wilk you continue on? Maybe some advanced concepts?
yes, this series isn't finished yet and I'll eventually release more videos about circuitry (whenever i find time to make them 😅).
@@center_pivot very cool, will there be concepts like queueing? Fifo or filo? Or writing and reading from memory bank?
@@wilk85 depends if i can find a useful scenario to apply it ^_^
@@center_pivot and without this in form of tutorial?
Fifo, lifo fir queueinf trains
Memory bank practically for everything;
I understand the chest buffer example is just a demonstration, but I really don’t see the benefit of doing that over a priority splitter going to the chest first and then the science. Nor do I really see the benefit of consolidating the stream of ammo into larger “packets”, instead of just taking ammo out when over 5k
yup, it's primary purpose was to illustrate the concept.👍
youre making it too overcomplicated. doesnt make sense.