I keep getting a broken output pipe. Why?

[avc15]

Any way to deal with this?

The output pipe on my A/T breaks once in a while. It's not a continuous thing, just bound to happen when I wait long enough. Hot tank, cold tank both filled with P-Water. Primary coolant and secondary coolant are all P-water.

I know this spaghetti looks a bit tough but just focus on the A/T loop. I also know there's a slightly better arrangement for the bypass, but I'm really tight on space here. Not interested in changing it unless my pipe layout is the cause for coolant freezing in pipes. The boxed bridge is a "fill" connection that plugs gaps in primary coolant with secondary coolant when a packet freezes once in a while.

So, what I was originally dealing with was that the temp sensor isn't immediately adjacent to the A/T, so I added a 1 second delay. The combination of a buffer and a filter both set to 1 second will delay any change in state by exactly 1 second + 1 frame. Is the extra 1 frame what's doing me in here? I tried also setting both to 0.7 and 0.8 seconds, and I still got an occasional broken pipe segment.

This circuit is NOR logic - the A/T runs *if* my batteries are full enough, *and* hot tank temp is below 98C, *and* temp of sensed coolant 1 second ago is greater than -8C.

I assume what's happening here is I've got the wrong amount of time delay and sometimes a colder packet is getting processed by my A/T, which would cause the output pipe to break when that packet freezes. Any suggestions? Anyone else have a better idea?

[biopon]

That piping is terrible! You have two tiles that have no pipes on them. You need to work on those ASAP, I'm sure the AT will like it more.

On a serious note, and you're not going to like it, but is there any way to use a reservoir as a buffer? It makes things so much easier. Automation timings don't always line up with the game. Filters filter and buffers buffer, keeping sort of to the time requested, and then game objects take a while to respond to them; this latter seems asynchronous but could very well just be a multithread delay. 

In other words, the time you put into a filter/buffer is going to be that much, or a bit more. I've never seen it to be less, but that doesn't mean it can't happen. Two buffer/not oscillators started with the same trigger will drift away pretty quickly, pretty significantly.

 

[PhailRaptor]

The other advantage to using a Reservoir as a buffer is the fact that inputs into the Reservoir are are averaged across the contents, and the contents are averaged across the output.  That is to say, if your Reservoir is nearly full and very cold, and you input a small amount of very hot, the thermal difference from the small packet will be spread evenly across the entire contents of the reservoir.  This has the effect of greatly stabilizing temperatures across the system, even when input packets are of very different temperatures.

This also aids in disinfection processes of disinfection, because Germs are split the same way.

[avc15]

8 minutes ago, PhailRaptor said:

The other advantage to using a Reservoir as a buffer is the fact that inputs into the Reservoir are are averaged across the contents, and the contents are averaged across the output.  That is to say, if your Reservoir is nearly full and very cold, and you input a small amount of very hot, the thermal difference from the small packet will be spread evenly across the entire contents of the reservoir.  This has the effect of greatly stabilizing temperatures across the system, even when input packets are of very different temperatures.

This also aids in disinfection processes of disinfection, because Germs are split the same way.

Ah, the A/T goes onto a "mechanically stable" cycle, meaning it can't flip on and off constantly from packet to packet. I don't even need the reservoir to be very full, 200kg or so should do fine.

Good point, you.