Multiple Fluid Selector Circuitry

[GluAp]

Hi there.

At the moment I'm playing Pyanodons mod set. You will encounter a lot of fluids that work as fuel for machines.
Since 2.0 makes fluids sharing the same pipeline possible I wanted to try to make it work.
My basic setup is composed of a fluid buffer tank with up to 8 pipe connectors where up to 7 are inputs.


Problem:

If I just use unregulated Pumps for the input of different fluids, it will only switch between fluids when the currently used one inside the buffer tank runs completly empty, resulting in this fluid blocking the other fluids and highly limiting throuput, as the currently used fluid is produced in smaller quantities and trickles into the buffer tank.

My idea:

Do some circuit magic. Basically a fluid selector combined with a simple RS latch.

Chose highest level available fluid that is higher than upper treshhold S, empty into tank until lower threshold R is reached. Between S and R don't consider the other fluids.
Switch to next highest fluid and do the same. Repeat.

I want it to be scalable and have the amount of logic not depend on the amount of different fluids. Further the fluids can't be hardcoded into the logic.

I used the selector combinator for finding the highest input fluid and I can do the RS-latch. But I can't make it happen to select only the highest level fluid, since that status will change when the level of the fluid decreases.

So I would need a memory cell that works with a constant (as in not pulsed) input signal and outputs the type of the currently used fluid until my reset point R is reached. So this part of the logic needs to consider the selector combinator output when the logic has R(eset) state and ignore it, while in S(et) state.

But I haven't seen a thing like that and I'm not able to figur this out myself. Do you have an idea?

I made an example setup where the steel chest resembles the missing piece of logic.

Fluid Selector.png (4.26 MiB) Viewed 890 times

[Shulmeister]

It's unclear to me when you want the signal to change without a clock to introduce hysteresis. The risk is that you will have 2 fluid with about the same quantity, 10K, and one will go to 9999, so then the other will be consumed, go to 9998, and then the first one again, to 9997 and then the second and so on very very fast.

With a clock you could make it so that every X amount of time, if the "current fuel" is not the most abundant fluid, finish the current fuel and start using the most abundant fluid. This just by pumping the most abundant fluid into the tank, and cutting the input of the "current fuel" so that when it is fully consumed in the tank, the abundant one being pumped in replaces it immediatly.

Maybe i'm not getting your goal properly ?

[Premu]

Actually, I had a very similar problem where I wanted to find the three types of items I have currently the largest deficit and store these until I receive a delivery.

This is the part of my circuitry which takes the selected value and writes a number in a memory cell designating its type. Constant combinators are used to transform the actual good to a number and back.

0eNrlW+1u4jgUfRf/3A0r/JGQIO1Ks/sYVYUCmNZqSBjHaQdVvPteO9DQBDolvoFqhj9cbuzj6+OPc23glcyzSm60yg2ZvhK1KPKSTO9eSake8jSzvjxdSzIlqVbmcS2NWowWxXqu8tQUmuwCovKl/EGmdBecqLWUC7WU+nQVtrsPiMyNMkrWrboP21leredSA2bwcesB2RQl1C5y2yQg8gn/KwzIlkxHTAhoCfpjdJHN5vIxfVZQBco1WDN4vHT1S/tgpXRpZk0fzHZj235W2lTgeQumLjEa266U0mJYoNKklsRxQIqN1GkdFfkTqhWV2VSXAcMr6NDBLqcjvB4dbCg62Bk6+OV0iOvRQYeig56hQ3gtFnbFxfLpSt9spWO+/kBcTaHX9GFXnD6frvQvBl/n5lfktfuwK+4+n670HwZf57anSfCBCH68GMdnyNoDtZg6/nTXb2FCZJtUu8im5G8ocwwyy6V5KfSTa0zLJZkaXcmAPGgpIfxVmpVyZ6W8Zq6dP3ym/U4LDvStCdsetHCS5vhCmsVtaKY3ppl60pxcSHN4G5rZjWlmnjTTsY+K83jgXVami8c+G+2hHoKW9xjNVryzT43PydGhPjnDLz869Maj43U++uVHh914dHjvfIhHV1SQA93vROQf0lsRGrzNFgKtcjNb6WI9UzlgHVg+Iwait+j+tpSFvdPB35ay5mB3uKf4CWeThjOg7wxrsG28cdXY0KfDfaHdjDIjddu7j0XpIh9tstRICOE79BliBnde6LXrfyfJc73e30MeLhiPeraB7dMXr9nCSiNl5gsnjuCKXI7mWi2e+sM1U7+sslWl+yM1MwJ6WFoVnacecM1JOCteRkuZw3zajkrQioWptAeBzdlPZjDFYMZYwVd6USnTH7U56qTL5zRfyKU/5lFev9HFQpalyh9GVe6F2SyWVba1eLqYF2a00tbZH5a1WAVOZf6gYIJ6xtssHxy8Zv0ApU8Sel7JzAMvPNouUh+g6P3C9kCavN8PC5/VQpvlUuk0V9XaZr0eeMkJvPBSvPtzsjS5VJaiLy1LY/vC1qY2KIZAtTExVKqN6SlVbTgMvWpj4opWGx1RudrQaPLVBkbTsA4wopB1sFHVrIOOIWkdUAxd64B6iVsHzU/hOnDeMtdBxNC6DiiG4NWgZ1UvPtoZ56B6TuFOncGaU+spmCbS0k374oLblnPfjB9fQNWoJNgbs3X64+0qyLF1/J33yd8yjC+NUAwXIT0ZIb00wnC4CNnJCJlHisRdirRUuk6C6p3yK2VM2MkScp6EnCLhZUfIidFgOdEw6dAQmdAQSdBA+c9gqQ921oOd8KDlOnhpDmqGg53cxPipDfsosWHc45b5y2tVyASLY2TBYriCJXAFK8Y7zke4isXZUJIViWGO8CweQLVYGA2gWyFlQ53cmRhKvNhYxMj6JcZJhCxhMU0Y2ok94rFAUzLOJlGMqWZRGPII+7jO6XjCsDUtYlSIvardB+QFNMhqxx0NaCACfh+AxcGiYDHwRc7HwBc5Hwdf6HwcfKHziYCBxfbWJBDO4vty1pq4clAGUNjeil250CHzvRW7clAmSNxTeAKW9U3AB2veOmNrUmcm1mTOhIfUuunBBoXe21CG12VsL6E8rW0wwtrPrC1qm1u7bp7a/rC6KWpjZnUENKlt2xX7Zsuwe6BTGbkGwpv/oATkGcTZaXwYsUQkCbzxhEd8t/sfFnDQsQ==

Copy blueprint

Note - the signals A, B, and C which are multiplied with the stored values are almost always 1, except when the reset condition appears (in my case a train with the specific good leaves) - in that case it will be 0 for two ticks to allow a proper reset of that memory cell. Perhaps you can adapt my idea to your problem.

[GluAp]

Thank you very much for replying.

@Schulmeister

I actually DID solve it like that. I even figured if I want to have a 'soft' hierarchy of fluid type usage, I can use negetive offsets by constanc combinator or different buffer tank sizes.

I'd have liked to somehow refrain from clocked circuits. There's probably not a good reason I don't like them.
I was intrigued by the problem if there was a memory cell solution that more or less stored the type of fluid/signal and doesn't depend on it's value so to say.
I still feel that should somehow be possible but as I said, I could not figure it out, yet.

My first intuition was using a negetaive feedback loop that add's the negative value of the not-choosen signal. But this always resulted in a condition that makes my circuit fail for exactly one tick.

@Premu

I'm not perfectly sure if I understand your design completly. You have a fixed amount of signals (items) which you manually map to various powers of 2.
Each row of combinators basically maps the indexed signal to it's corresponding power of 2 and keeps this in memory until each corresponding reset signal will reset the cell/row. This way you seperate signal type and value.

So I guess you could remap the value from the power of 2 to back to it's signal type. That could be useful. But the whole concept is kind of not universal. For each signal type you have to manually map it to some power of 2. If you want to compare more signals you have to add another manually configured combinator row which I really want to avoid.

Although: when testing your BP I just noticed if there is no signal on the input side the whole cell will lose its memory. So this is not a memory cell, strictly speaking. Or am I missing the point?

ps: I think I found a flaw in the factorio circuit network. You don't have a "not" logic and a signal with value '0' does not exist on the circuit network.

[Premu]

Thank you very much for replying.


@Premu

I'm not perfectly sure if I understand your design completly. You have a fixed amount of signals (items) which you manually map to various powers of 2.
Each row of combinators basically maps the indexed signal to it's corresponding power of 2 and keeps this in memory until each corresponding reset signal will reset the cell/row. This way you seperate signal type and value.

So I guess you could remap the value from the power of 2 to back to it's signal type. That could be useful. But the whole concept is kind of not universal. For each signal type you have to manually map it to some power of 2. If you want to compare more signals you have to add another manually configured combinator row which I really want to avoid.

Well, it was just a part of the whole design, the actual one has even more stuff. But yeah, I have a fixed amount of signals. I mapped them to powers of 2 so that I can simply add the three different values up and see from the sum which items were chosen. If you don't need that, you can just number them up. You'd still need to do that for all possible fluids, of course, but your blueprint can just contain all of them.

To remap that you only need a single combinator with inputs from the constant combinator with the ids for each fluid and the stored value. You just check if "each" == stored value, and return "each". So if for example you stored the ID for crude oil, the only output signal would be one for crued oil with a value > 0. Which you can use to activate the pump for crued oil.

Although: when testing your BP I just noticed if there is no signal on the input side the whole cell will lose its memory. So this is not a memory cell, strictly speaking. Or am I missing the point?

ps: I think I found a flaw in the factorio circuit network. You don't have a "not" logic and a signal with value '0' does not exist on the circuit network.

Hm, it works for me. An incoming signal can disappear, the value still sticks. The A,B and C values have to be one the whole time, of course, as these are the reset conditions which will turn to 0 only if I want to clear the cell.

PS: If you need a not, just check if a signal is 0, and use it as output. The 0 counted as not existing signal is annoying, though, which was also a problem in my blueprint. That's the reason I have also a constant combinator with all ones for the relevant values. So that I can add this constant combinator to a check for all these signals and ask for "each == 1" instead of "each == 0" and get actual results.

[GluAp]

Well - It does hold the memory for me too. I forgot to reset A/B/C to 1 ^^

The Py Mod has about 60 fluids with fuel value. That's a lot of combinators for every place I would like to use this contraption.

And about the 'not': I'm missing it as a selector. Like "not OIL => Output = every signal that's not oil."
You can't just take a decider with "OIL != 0 => Output = everything but oil-signal".

Wube could add a mapping function to the selector combinator that filter's a signal type on red(green) channel that is given by input on the other channel. That'd be great. ...

------------------------------------

Holy mother of factorio .... I think I found an actual solution that works.

At the moment I'm using a pullup feedbackloop to the input side of the selector combinator.
Let's assume we have different ordered signals x1>x2>x3 ... on the green wire input of the selector combinator and call this starting state.
It will per definiton select x1 as long as x1>x2. If some signal x is selected I will pull it up to a value k (k > max[x1, x2, .. xn]) and feed it back, so the new input signals are x1+k, x2, x3...
It's x1+k because x1 is the actual value of the buffertank and k the pulled up value. (So now I don't have the real value any more.)

If that's the case, the selector will always select (x1+k), where 'x1' is on green and 'k' on red wire. I now use a arithmetic combinator to calculate the difference (k - [x1, x2, ..xn]) (red wire (has only k) - green wire) so all but the first pair will result in negatives and can be filtered out, so only (k - x1) remains.

I can use (k - x1) to determine if it should keep on pulling it up.

Now I have to only get the conditions in the right order and it somehow works.
And now I'm kind of sad, because I was so happy it worked out, I just saved over my actual gamesave but I was in editor mode

I guess I hope I find a backup ...? Will be testing the circuit and if works to my expectations it will be posted

[Shulmeister]

I'd have liked to somehow refrain from clocked circuits. There's probably not a good reason I don't like them.
I was intrigued by the problem if there was a memory cell solution that more or less stored the type of fluid/signal and doesn't depend on it's value so to say.
I still feel that should somehow be possible but as I said, I could not figure it out, yet.

Maybe using a couple modified schimitt trigger or 2 buffer tanks you coud avoid clock setups ? To be fair you seem onto a more interesting way to do thans what I have achieved so far with them, so i'd be catching the opportunity to learn if you post a setup !

[GluAp]

Maybe using a couple modified schimitt trigger or 2 buffer tanks you coud avoid clock setups ? To be fair you seem onto a more interesting way to do thans what I have achieved so far with them, so i'd be catching the opportunity to learn if you post a setup !

Interesting idea with the Schmitt trigger. I definitly couldn't think of it, especially in discret logic, nonetheless I have heard of this some time ago in a minor subject I had to take. But now that I read about it again I think this is more or less what I realized by chance.
So no patent for me I guess

I too am realizing in this moment that I didn't properly read your first reply. Maybe I need to read this stuff in the morning ...
Anyway, this "per tick switching" circuit you described in your first reply was exactly the reason, why I was looking for another solution. And my clocked design worked exactly as you described it to me.

But just as I finished my design and was testing it I came to realize that my design is actually not working for me in the context I wanted it for
At the moment I have 3 different fluids that are somewhat linearly dependend, but only one is a primary product which will be used most of the time. So this fluid will be choosen by my circuit design first/most, statistically speaking. The other two fluid byproducts will stock up until the buffer is maxed out, will now limit the primary product production until it runs empty and will switch to the secondary products very late. It technically works as intended but isn't quiet efficient. I can tune the thresholds of the design, but it's still not that nice.

I guess it'll work perfectly fine if you use it for independend fluids/items. I will have to revert to my clocked circuit, for now.

Anyway - here it is:

0eNrNWF1u2zgQvgrBpzRLG5Zk2Zax7UsXu1sgT03zlAQGLY1jdiVSoCg7RuAD9CB7sT3JDin5N7YTu41bGEFG0sw3o29+RPKJDtMSci2kof0nmkARa5EboSTt0780gCRToYHkKgXy/j35JPPSMLwsmmTC0ZQRLmdEltkQNFEjUogHydOCXEyFGavSkOt3jGT8kQhrWdmQHHUrRfI7aTXDy0rBNGvImEsyBMKTr2VhILmTnyHZjAORXSBGI5yzupN38qPQcSkMqqYpiceqADIWD2MoDElhAmkdRO36AzFjDcVYpQkjpTQCnxuSaJUXJFFTSYwiqZpirEs9crEVGr6c81MQCY/mkDcuE6IhB26KposVH6Ucdc1UEa6RrQyMiEmssqGQ3ChdMDJSS6LMLAcyEqmxPMt0RhkVsZIF7d8+0UrHZlDyDDB1K8DGCpDO0UYm8Ej73pztsEogFgno3Sb+/J5RQJqMgMqru5gNquQjJlvgZJCIMmtACrHRGILNGsaLVSOq0nqiCNjwQ8w9ozPaD7rNcG5D2oL0j4Zs916ADNhhjnZhriEymmAdxtXzNqOYAqNVOhjCmE8E2qPRCniAjxMHVtgHI6ELM1jRbnOKgUyENiXeWUZWaTSAx2ObgAIszPF2CvuM173cQK2qaY7HWQ97IAELVv/j3kdDQvu2BRl9sLOC9kfY+7Ad8nMbp7Y0sgjz+a5ktU9IVrAnWZ5/1mzZ3jTcjtXWZiZ+OzkTOykKj28R74UW6azcOzClX+I8WiBGm5z3dlO+TkflgrJaGOCnYFFTbvCsE7kr2C47ML0ODggb667oapytali/uj25OFYv02u1WvY6y7l2sfbpB2pHbFUb23P9dQVyv7NEesdS1D0unechzG85xg4Po12DhR3t/LryvJGak8ZghQGD2h+uAegJ4ezlYiPE/779S89Dz/N42ifm5kcx9KYJ+76etJj5DHsDV5iDkVbZwC0Ll3RsJXVPC0fHtnD4a0w5z3fvdCKD1y/Rt4ctr3UsXfWioffKFd6bkDcBPTNjIR/sID83Y96JjEU/k7FluZ3hI+r5J6xFvePK6s2Xog1vcy16+R1rUXzflM8wpZuHBnZfe+HZowAfN8ditLZFr3ftRCr8A0igmvXbRAenEx39KkTXH+gfswM7zLX/Sq7dCURZANGLw5TqfILbs4tpre+axz60rXPrMd/+7hlKIUohSvZO4O5ZqVNLof2hFDAP73m11GOBk9oMJ7K/ED0nttEa77adGLDIqYZohI1mxQ6qdp1mF6Wek3r4uFKMrLXnrPEf+gqcU7T1rBzc42vYmYA5Bl2NgZrquszYQuhTuxJfMX/lTnyuRCaQ289QgCEfFyXyDtUmWDt8mFrVL3+7+t0L7IpghXyT50vktdOwTcybq8OY7U3MP1SJdmQN2q57lM7KlNsILhEPGwJywL2ULcxq2XXAgftirxx8kvhZwqL5sjgC28C/uWogCc8dIPvCQIYaq+NFRlM+BKx6+mdaioRc13tLsji1m/iWCvTmijvs+FE7ivBfEAWdYD7/Hy84DIE=

Copy blueprint

I put (hopefully) everything in the description. If anybody has questions I will try to explain.

I believe this works as a Schmitt Trigger. Maybe someone can confirm this. Than I could adjust the topic title for better SEO.

[mmmPI]

To be fair you seem onto a more interesting way to do thans what I have achieved so far with them

can you show what it look like ?

I put (hopefully) everything in the description. If anybody has questions I will try to explain.

I believe this works as a Schmitt Trigger. Maybe someone can confirm this. Than I could adjust the topic title for better SEO.

It does look a lot like the space age version of this viewtopic.php?t=112005

[GluAp]

It does look a lot like the space age version of this viewtopic.php?t=112005

No. Maybe. A little bit?

From distanly looking over the design Tomiket built, it seems to behave like a Schmitt Trigger, yes.
For my taste it is realized more like a boolean truth/lookup table or distantly a conjunction of boolean terms.
He maps 4 input states onto variables and combines it to 1 output.

As others have pointed out - this could be done with a SR-Latch more efficiently. Although it works on one type of input signal only.

My design allows a Schmitt Trigger like histeresis to work on an arbitrary choosen signal input. The main focus beeing that the circuit will keep this signal type until the reset state is reached, even if the input signal switches the input signal type in between.
That was the hard part for me which I haven't seen around yet.

Additionally I believe this couldn't be done before 2.0 (aka without selector combinator) in a way that allows an arbitrary amount of input signals. For a fixed amount of signals you could have built a lookup / sorting logic but that's just boring.

What I just realize: I haven't actually tested how my design works with short-pulsed input switches. My guess is that it won't actually work/start properly. If somebody wants to test this, please go ahead. There might be a somewhat easy and dirty but manual fix.

[mmmPI]

It does look a lot like the space age version of this viewtopic.php?t=112005

No. Maybe. A little bit?

Enough that i recognized it weird how (human) memory works x) I meant it as a confirmation when you said " maybe someone can confirm".

[Nidan]

Wube could add a mapping function to the selector combinator that filter's a signal type on red(green) channel that is given by input on the other channel. That'd be great. ...

In case you still need a solution for this, here's a hint: With 2.0 you can do this with a single decider combinator. Check 124776 for the solution and a bunch of other bits and pieces that might come in handy.

[GluAp]

Thank you. That's a nice combinator collection thread I had not seen before. Great Work. Bookmarked immediatly.

Unfortunatly what I wrote was not how I intended a mapping function to work. Since mapping for me is different to filtering.
Say we have 3 Signals on one wire channel. With some conditions met I'd like to map them to a yet unspecified but dynamic 4th signal type that's given on the other wire channel. For example map signals '1', '2' and '3' to 'X'. But if 'X' changes to 'Y' everything will be mapped to 'Y'.

You can build such a contraption with static signal types, I'm sure of it. It'd probably use a lot of combinators.
Even if it is possible to make it dynamic it probably wouldn't work for the edge case when the mapped-to signal has a null value.

To be honest - I know that I would have wanted something like that several times for problems I encountered, but atm I can't reimagine what my usecase would have been.

[Nidan]

Apparently I managed to miss the "mapping" in the part I quoted and focused on the "filtering" part...

Say we have 3 Signals on one wire channel. With some conditions met I'd like to map them to a yet unspecified but dynamic 4th signal type that's given on the other wire channel. For example map signals '1', '2' and '3' to 'X'. But if 'X' changes to 'Y' everything will be mapped to 'Y'.

If you have the circuitry for mapping onto a static signal, making it dynamic should take only a single arithmetic combinator: each[red] * static[green] -> each. Supply target signal(s) with value 1 on red wire.

[GluAp]

If you have the circuitry for mapping onto a static signal, making it dynamic should take only a single arithmetic combinator: each[red] * static[green] -> each. Supply target signal(s) with value 1 on red wire.

I'm not sure I can follow your description. You just made my point.

When using an arithmetic combinator with many signals on [red] and STATIC signal on [green] I can do what you just described.
But my whole suggestion was that this exclusivly does not work, if you have a changing/unknown signal on [green]. I can't perform any actions with an unknown signal.

Even each[red] * each[green] -> each.

Does not work. Especially if you wanted to map [x1, x2, .., xn] (red) * [y1='0'] (green) => y1.

And ultimatly a mapping function should be implemented with the decider combinator.

Maybe what I'm describing is more similar to a multiplexer? So basically a decider with a dedicated select channel that has programmable AND/OR logic functionality to switch different input to different outputs.

I'm sorry if I'm confusing you

[mmmPI]

I'm sorry if I'm confusing you

To me the confusing part is the usecase x)

Edit :

To be more specific, i tested the blueprint and i don't understand the role of the upper limit, if i set 25 K with fluid tank that can have 25 K fluid, whenever the value of 25K is achieved by a fluid and the machine switches to try and consume it, it seem to no longer provide any fuel/output , and look broken.

Are you supposed to set a number stricly superior to whaetever the fluid quantities could be ?

[Nidan]

I'm not saying that the arithmetic combinator is the mapping; it is not. As consequence, your attempt at interpretation went off the rails. I don't even know how that mapping is supposed to look like (mathematically), the description is quite vague.

From

For example map signals '1', '2' and '3' to 'X'. But if 'X' changes to 'Y' everything will be mapped to 'Y'.

I only handle the seconds sentence. When you have something that map signals '1', '2' and '3' to 'X', then converting that 'X' to 'Y' (or 'Z' or 'iron-plate' or …) can be done by adding a single arithmetic combinator, configured as 'X'[green] * Each[red] -> Each. 'Y' (or 'Z' or 'iron-plate' or …) is the signal that would come in on the red wire, with value 1.

[GluAp]

I guess I see the misunderstanding:

Let's make an example of it. Whether it is useful or not.

I would like to have a single (decider) combinator that has 3 in signals on red wire:

in_r1: signal type = nuclear fuel; value = 500
in_r2: signal type = solid fuel; value = 300
in_r3: signal type = 'C'; value = 1000

On green wire it has 1 in signal:

in_g1: signal type = {assume 'S' or 'R'}; value = [s_int_32]

There shall be these lines of logic / out:

out_1 ==
{
IF (in_r1 < in_r2 < C) : (value = in_r2; signal type = type(in_g1))
IF (in_r2 < in_r1 < C) : (value = in_r1; signal type = type(in_g1))
IF (C < in_r1 OR C < in_r2) : (value = C ; signal type = 'R'))
}

This will result to:

out == (signal type {'S' or 'R'}; value = 500)

Honestly - I don't know what this does.... I guess this could be a feedback loop. My programming days are long gone and I hope you can follow my notation.

The important part is, that in_g1 is used as a symbol. This can be used to map nuclear fuel = 500 as input signal to output 'S' = 500 or 'R' = 500 not depending on the actual value or type of the green wire input ('S' or 'R'). It just passes the signal type trough with a newly assigned value. It shall even work if in_g1 is set to zero.

When you have something that map signals '1', '2' and '3' to 'X', then converting that 'X' to 'Y' (or 'Z' or 'iron-plate' or …) can be done by adding a single arithmetic combinator, configured as 'X'[green] * Each[red] -> Each. 'Y' (or 'Z' or 'iron-plate' or …) is the signal that would come in on the red wire, with value 1.

Yes and No. Yes - you can expect 'X' and convert it to 'Y'. But you would have to know that you're expecting 'X' and code it as a static case. But I don't know if the green wire input will be 'Y', or 'Z', or 'iron-plate'. But I do know I'd like the output to be 'copper-plate' nonetheless. So it has to map any input value from red wire signals to the signal type of the green wire and we don't care about what the green wire actually signal is.

So to say - it'd be great if there was an additional checkbox in the combinator GUI where you could check a box to let a wire type evaluate symbolically and not by value.

[mmmPI]

Honestly - I don't know what this does.... I guess this could be a feedback loop. My programming days are long gone and I hope you can follow my notation.

I am not sure i can follow the notation, but i wanted to be sure i didn't make a mistake, because i realize it's not exactly working as a schmitt trigger, which aims at controlling that the input signals reaches the "upper bound" before flopping. I may have spoken too soon when "confirming". When i tried again the posted blueprint, i realize it wouldn't work when the value reaches the upper bound when you set it to the quantity of the fluid tank, but if you need to set it above then the blueprint just picks the maximum signal even if it's not at the specified limit. It look a lot like a schmitt trigger but isn't one.

Then i tried to understand how the posted blueprint could serve the mentionned purpose in the OP , the usecase, but i don't think it can.

The wiring (i think plz correct me this is hypothesis) should account for 2 differents sets of inputs i thought, 1) for the fluid that could serve as fuel to know their quantity and 2) the quantity of fluid in the buffer tank, to know when to switch.

As such i am not sure i understand the usecase of the machine

[eugenekay]

These circuits make Barrels seem like a sane alternative for Fluid Handling.

this is (mostly) a joke. I like modded fluids too