Gas sensor slips packets

[Crapgame]

In this image you can see the unfiltered gases entering the sensor from the bottom.

The sensor is set to Hydrogen which then goes right and into the tank.

The remainder should just go up.

HOWEVER, that is just not happening.  As you can see, this filter is somehow letting chlorine pass as well.  Not all the time either which just adds to my confusion.  (You can see some chlorine exiting as expected up through the sensor.)

I've checked all of the other failure points (e.g. power outage and pipe backup) and there are no other issues.  I'm literally just watching this thing run so it's not like it is happening OOS.

I've used mechanical filters without issue but I just wanted something Q&D to get this job done.  My lack of faith in sensors has been renewed.

Any insight as to why this occurs?

 

[Flingdagger]

Using this cheap method of filtering is exactly that.  You get what you pay for.  For this type of filtering to work, your pipes can never back up on either the continued length of piping or the other side of the shut-off.  If it backs up on filter side, you get unwanted packets on other side and visa versa.  Any time I use the sensors I always make sure the flow can never stop or they are useless.

[psusi]

23 minutes ago, Flingdagger said:

Using this cheap method of filtering is exactly that.  You get what you pay for.  For this type of filtering to work, your pipes can never back up on either the continued length of piping or the other side of the shut-off.  If it backs up on filter side, you get unwanted packets on other side and visa versa.  Any time I use the sensors I always make sure the flow can never stop or they are useless.

He specifically said that it isn't backing up.

[Crapgame]

Also, that is why I have that gas storage tank there.  To make sure my filtered output doesn't back up.  You can see it still has room.

While you can't see it, the unfiltered pipe goes far away and is also not backed up.  You can even see an empty packet in the line in this image. 

 

[Flingdagger]

Is it possible that you have the T connected?  Try deleting just the one pipe segment on the output side of the shut-off then replacing it only dragging to the adjacent pipe to the right

 

[OxCD]

It comes from the fact that the flow isn't continuous. It could also come from flow bottleneck, or electric failure. I don't have needed overview to be sure.

But the thing is if you want to be sure of your filtering system, use this kind of loop, that includes backup, and you should not get any issue anymore.

[psusi]

22 minutes ago, OxCD said:

It comes from the fact that the flow isn't continuous

How does that matter?  I've never had this problem.

3 hours ago, Crapgame said:

Any insight as to why this occurs?

Try adding a bridge to the overflow that goes off to the left.  I don't know what lies further down that line, but maybe there is a source over there so the gas can get confused and decided to turn around and flow back to the shutoff after having passed it.

[OxCD]

23 hours ago, psusi said:

How does that matter?  I've never had this problem.

Then you should thanks the luck. Or mechanisms you do not master yet.

The sync between sensor and shut-off isn't reliable when there's too many gaps between packets.

[Crapgame]

2 hours ago, OxCD said:

It comes from the fact that the flow isn't continuous. It could also come from flow bottleneck, or electric failure. I don't have needed overview to be sure.

But the thing is if you want to be sure of your filtering system, use this kind of loop, that includes backup, and you should not get any issue anymore.

 

It can come from the fact that the flow isn't continuous INTO the sensor?  I have already confirmed that is is NOT a blockage on the outputs or electrical shenanigans.  I hadn't considered the flow of the incoming gases.ds

About your images, I see a sensor for H and O2.  What is the NOT gate set for?  No H?

Thanks for the suggestion BTW but if I was going to do that method I would just build the mech filter.  It is just as much work and I save 3 sensors.

I was honestly just hoping the sensor would...you know....sense.

If I had a job as a ticket taker and when the line got backed up I just started letting in two at a time, I'd get fired.

[psusi]

2 hours ago, OxCD said:

The sync between sensor and shut-off isn't reliable when there's to many gaps between packets.

Why?  How is a gap any different from the "wrong" element?  The sensor reads anything that is NOT the selected element as red, including an empty pipe.

2 hours ago, OxCD said:

Then you should thanks the luck. Or mechanisms you do not master yet.

That is both hand wavy and condescending.  I've made many such filters with very intermittent pipe flows ( no way to avoid it if you are filtering multiple gasses ) and I very much doubt that I accidentally worked around it using some other mechanism that is both unknown to me, and that you can not suggest ( which despite your condescending tone, indicates that you don't know it either ).

[OxCD]

15 hours ago, psusi said:

Why?  How is a gap any different from the "wrong" element?  The sensor reads anything that is NOT the selected element as red, including an empty pipe.

That is both hand wavy and condescending.  I've made many such filters with very intermittent pipe flows ( no way to avoid it if you are filtering multiple gasses ) and I very much doubt that I accidentally worked around it using some other mechanism that is both unknown to me, and that you can not suggest ( which despite your condescending tone, indicates that you don't know it either ).

That's when I quit All the best.

[Crapgame]

Alright break it up...

Still would like to know what that NOT gate is for.

 

[psusi]

1 hour ago, Crapgame said:

Still would like to know what that NOT gate is for

It is so that oxygen gets recirculated and has another chance to get picked up by the oxygen pipe, and everything NOT oxygen goes out the reject pipe.

[Crapgame]

3 hours ago, psusi said:

It is so that oxygen gets recirculated and has another chance to get picked up by the oxygen pipe, and everything NOT oxygen goes out the reject pipe.

Which I would assume could include H?

If we're figuring that sensors miss packets and this set up checks for H, then O2, then NOT O2, then we're accepting missed H?

[OxCD]

@Crapgame you're complicating the thing. The loop is not necessarly The One you need. It's a concept example. You can make the loop as big as you want, and have 8 sensors/shutoff to sort 8 differents gas, if you need so, or smaller also. The setup advice is about the bridged loop design, not the sensor/shutoff combo that you clearly already know well.

And if your flow is irregular, you may also think about using a in-line packet stacker prior this filtering loop.

Then it should handle irregular flow, bottleneck, electric failure, etc... Nearly everything.

[psusi]

17 minutes ago, Crapgame said:

Which I would assume could include H?

If the primary H pipe backs up, yes.

17 minutes ago, Crapgame said:

If we're figuring that sensors miss packets and this set up checks for H, then O2, then NOT O2, then we're accepting missed H?

Like I said; I've never seen that happen.  In my last world I had an industrial room that had ethanol distillers, a petrol gen, and fertilizer makers in it, and had a gas pump initially intended to capture the NG.  Initially it used a shutoff filter to send the NG to a reservoir and vent the rest back out nearby ( there were carbon skimmers around to eat that ).  Later I had some chlorine floating around so I added another filter to send that off somewhere else and and then I added a CO2 filter to send some CO2 down to my slickster ranch and vent the remaining oxygen further up where there's always oxygen instead of mixing it in near the CO2 layer.  I never had the wrong gas go anywhere by the time I reached the temporal tear around cycle 1400.

Oh, I had another one down near my oil rig to pick up the NG the thing vented and send it to a NG gen to burn off and put any other gas back ( mostly CO2 for the slicksters ) and it never got damaged either.

[nakomaru]

I can't tell if there's still any confusion, but the situation is as OxCD has described. You must not have single isolated packets to use this sort of filtering. Saturnus also indicates essentially this reason in the referenced post.

As a recommendation, I would say you should almost never use T sections. Use bridges instead to ensure priority and continuous flow. At the same time, this will reduce single pipe network complexity (i.e. take better advantage of multithreading).

[Edoc_]

I have seen that the combo sensor + shutoff is unreliable. What I'm doing is sensor + filter and activate the filter only to extract the element detected otherwise it bypasses it.

[TheMule]

22 hours ago, Flingdagger said:

Is it possible that you have the T connected?  Try deleting just the one pipe segment on the output side of the shut-off then replacing it only dragging to the adjacent pipe to the right

 

The OP didn't reply so I'm reiterating this. Deconstruct the shutoff and see how's the piping under it.

[psusi]

13 hours ago, OxCD said:

And if your flow is irregular, you may also think about using a in-line packet stacker prior this filtering loop.

That only works if the gas is already of a single type.

9 hours ago, nakomaru said:

I can't tell if there's still any confusion, but the situation is as OxCD has described. You must not have single isolated packets to use this sort of filtering. Saturnus also indicates essentially this reason in the referenced post.

He said that causes a problem with temperature sensors, not element sensors.  When temperature sensors see an empty pipe they see it as 0 K.  When element sensors see an empty pipe, they hold the previous status.

[OxCD]

1 hour ago, psusi said:

That only works if the gas is already of a single type.

Why ? If you're refering to the sensor used (element sensor set to hydrogen in this example), just set to something you'll never get into the pipe (fe: steam) and attach a NOT gate. Or use thermo-sensor and set below 4000°C. And the packet stacker will do its job.

1 hour ago, TheMule said:

The OP didn't reply so I'm reiterating this. Deconstruct the shutoff and see how's the piping under it.

Basically it's a good idea (it's a common mistake). However see below the difference, you can spot the pipe below the shut-off. Which is not the case in OP's post.

[Crapgame]

1 hour ago, TheMule said:

The OP didn't reply so I'm reiterating this. Deconstruct the shutoff and see how's the piping under it.

Piping is good there, thanks.  I learned that one the hard way with my first sensor.

[Edoc_]

2 hours ago, psusi said:

When temperature sensors see an empty pipe they see it as 0 K.  When element sensors see an empty pipe, they hold the previous status.

This explains a lot, thanks !

[psusi]

2 hours ago, OxCD said:

Why ? If you're refering to the sensor used (element sensor set to hydrogen in this example), just set to something you'll never get into the pipe (fe: steam) and attach a NOT gate. Or use thermo-sensor and set below 4000°C. And the packet stacker will do its job.

Ohh... yes, I suppose that will still get rid of any empty spaces... for some reason I was thinking the goal was to stack FULL packets, which won't happen if there are mixed gasses.

 

[nakomaru]

4 hours ago, psusi said:

He said that causes a problem with temperature sensors, not element sensors.  When temperature sensors see an empty pipe they see it as 0 K.  When element sensors see an empty pipe, they hold the previous status.

And I said essentially. The problem was with the shutoff not responding in time to a single packet regardless of sensor. But it seems that both the temperature and element sensor + shutoff vs single packets has been fixed (both tested, used to not work):

In that case I suspect the multiple T junctions are causing some hitching in flow which makes your shutoff go out of sync. Try it without T junction merging.