Gas meter valve automate reset issue

[zealyahweh]

I have a setup to have a gas meter valve send 25kg steam to sauna each time after Dup uses it.

So there will be no accumulated steam in the pipe and I can place sauna in the middle of my base without worrying about heating the base too much or steam condensing to water.

The problem is that after resetting the gas meter valve, it sometimes sends 26kg steam instead of the set 25kg. This happens randomly so I can't simply change the value to 24kg.

This is the automation setup:

each time sauna outputs 25kg water, then triggers reset of gas meter valve to send another 25kg steam to sauna.
and 25kg steam limit is reached, reset liquid meter valve.

the signal counter is to convert always on signal from meter valve to a short impulse to reset.

It looks like that the impulse is just not short enough for reset, it reset twice after first 1kg steam is sent so a total 26kg is sent.

it does not make sense meter valve reset itself each tick during the reset signal pulse, it should reset only once during the whole signal.

And as this happens more often on 2x and 3x game speed it seems a bug to me. The game mechanism should behave the same whatever the game speed is.

BTW, is there any reliable way to automate reset meter valve?

[Gurgel]

Do a loop and feed the overflow back to the starting point. Same idea like when fueling a rocket with LOX or liquid hydrogen. 

[zealyahweh]

35 minutes ago, Gurgel said:

Do a loop and feed the overflow back to the starting point. Same idea like when fueling a rocket with LOX or liquid hydrogen. 

very smart! That certainly solve the problem. thank you very much.

anyway, I still hope klei can improve that reset port. right now reset by automation is just like a joke.

[Gurgel]

I think there may be a race-condition in there. Very hard to fix, maybe impossible. Or not. But one aspect of Oni is that things only sort-of work and you have to build in redundancy and regulators. Just look at what the components look like x-)

[blakemw]

This is a known issue, it was even attempted to be fixed in one patch but the fix was a bit of a disaster and it was rolled back.

The "easy" solution to this race condition is ensuring the Meter is powered off while it is receiving the reset signal, that prevents the issue which is receiving the reset signal at the same time as it is emitting a packet. Essentially you have to feed the reset signal into a Power Shutoff via a NOT gate, and delay it going to the Meter with a FILTER gate for long enough that the Power disconnect has taken effect.

[Gurgel]

4 hours ago, blakemw said:

This is a known issue, it was even attempted to be fixed in one patch but the fix was a bit of a disaster and it was rolled back.

The "easy" solution to this race condition is ensuring the Meter is powered off while it is receiving the reset signal, that prevents the issue which is receiving the reset signal at the same time as it is emitting a packet. Essentially you have to feed the reset signal into a Power Shutoff via a NOT gate, and delay it going to the Meter with a FILTER gate for long enough that the Power disconnect has taken effect.

Interesting. And a typical race-condition fix. So definitely fixable, we just have not complained loudly enough yet 

[blakemw]

4 hours ago, Gurgel said:

Interesting. And a typical race-condition fix. So definitely fixable, we just have not complained loudly enough yet 

One of the issues with the race condition is how to fix it.

In a beta patch the devs went with a scheme where only a "rising edge" (signal transitioning from red to green) would cause a reset. This broke the existing behaviour where you can just keep sending a green signal to keep emitting more packets. But the implementation was also bugged and would result in Meters getting stuck, you could fix that by mashing the signal on and off, but it still wasn't a "send a signal, get X amount of stuff emitted" solution, it was badly broken if that's what you wanted, I assume it was the bug which caused the rollback, though I was certainly unhappy about the backwards incompatibility and the amount of clunkiness required to get continuous emission behaviour. 

There are a couple of other potential solutions:

1.  A meter only becomes receptive to a green signal once Amount == Limit, this maintains backwards compatibility, is probably quite easy to implement (it's literally just throwing in an If statement) and is fantastically user-friendly for the specific case where you only want exact multiples of Limit to be emitted (e.g. feeding a Payload Launcher in 200 kg batches). There may still be double emitting issue if Limit is smaller or equal than the packet size (e.g. emitting small quantities of food on a periodic bases, way smaller than the 20 kg package size of Conveyors), additional logic may be required to prevent double-emitting in that case.
2. A meter has a one second cooldown after being reset, when it cannot be reset again. This means that any scheme which keeps a green signal reasonably short wouldn't suffer from double-emitting, while completely preserving backwards compatibility, and it's also good if the Amount == Limit scheme is considered too user-friendly.

[JRup]

Could you post the liquid and gas pipe overlays for those of us that are curious?

[Gurgel]

6 hours ago, blakemw said:

In a beta patch the devs went with a scheme where only a "rising edge" (signal transitioning from red to green) would cause a reset.

Ah, yes. Flank-trigger vs. level-trigger. Looks simple, but is really something that only seasoned and experienced experts can handle well. The possibilities to screw it up are numerous and often quite surprising. IMO, RESET should always be level-trigger, because if you reset anything you depend on it being reset afterwards. Flank-trigger does not ensure that, level does.  

[JRup]

One of the main issues with the change to meter valves back then was that the "memory effect" that was added was too good. Certain cases would disable the valve completely.

Anyway, here's my take on the sauna + meter valve build. It's working in my base at the moment:

 

Each time the sauna is used it will discard exactly 25kg worth of water converted from whichever temperature steam is put inside so the liquid sensor provides the relevant feedback. An edge detector (the AND+NOT gates in that config) will provide the relevant reset signal for each saunas respective meter valve. The output signal from the meter valve is not used in this case.

If anything, I only wish the valve's sprite were smaller so that it would not overlap with any tiles it's bordering/touching, part of the eye candy is blocked, tragic:

[zealyahweh]

9 hours ago, JRup said:

Each time the sauna is used it will discard exactly 25kg worth of water converted from whichever temperature steam is put inside so the liquid sensor provides the relevant feedback. An edge detector (the AND+NOT gates in that config) will provide the relevant reset signal for each saunas respective meter valve. The output signal from the meter valve is not used in this case.

I somehow find the problem is that I'm using a %1 signal counter as edge detector, as it is smaller.

But as I just tested, the signal pulse from the signal counter is a bit longer than the AND+NOT combination,

it makes a lot of sense that the extra tick of signal is causing the extra steam package.

I will test AND+NOT setup and update later

[blakemw]

57 minutes ago, zealyahweh said:

it makes a lot of sense that the extra tick of signal is causing the extra steam package.

FYI it literally doesn't matter how short the signal is. The simulation isn't deterministic enough.
If the signal is extremely short it is possible to avoid emitting an extra packet on certain game speeds. BUT, if the signal is extremely short it's also possible the meter fails to reset because the signal was too short for it to notice on certain game speeds, so if you eliminate the possibility of emitting an extra packet, you introduce the possibility of emitting nothing. Again, the simulation is not deterministic, things are kind of simulated in a certain order and schedule, but not strictly. It's possible the signal will be green then go red again before the machine gets around to checking it. To make this even more fun, the behaviour will change with game speed and how loaded the simulation is! So your system could be working perfectly when you're watching it closely at 1x speed, but turn up the speed and it breaks down.

If you want to avoid issues, just use a Power Shutoff so the Meter is turned off while it is receiving the green signal preventing it entirely from emitting a packet while receiving the reset signal, set it up so it's turned off for an extra 0.2 seconds on either side of receiving the green signal, because it also takes a while for machines to notice their power has been cut off. It's not very hard with some BUFFER and FILTER gates.
For example, assume the reset signal is at least 0.6s long (or use a BUFFER to ensure this), send it through a FILTER gate (0.4s) to the Meter, send it through a NOT and FILTER (0.6s) to the Power Shutoff that disconnects the Meter. This will be stable at all game speeds including ultra speed in debug.