Dealing with micro quantities on shipping rails

[YOLO KNIGHT]

I like to make metal volcano harvesters that use shipping rail loops to cool the metal and as far as I can tell a lot of people do. The only annoying thing is every now and then the sweeper picks up some microgram range amount of material that won't transfer temperature and winds up looping forever unless I manually change the temp sensor to let it off. Has anyone found a good way to deal with this automatically?

[Charletrom]

Put two conveyor thermo sensors side by side, run the automation wire through both, and have them output a green signal when the desired temp is reached. This way a normal mass packet behind the micro one will allow it to leave the loop.

Two adjacent micropackets would break this setup, but I’ve never seen that happen

[YOLO KNIGHT]

Yeah I've never seen adjacent micro-packets either. Thanks!

[wachunga]

My favorite solution is to never allow microgram packets on the rail to begin with. Stick a weight plate wherever the debris falls. That weight plate controls the conveyor loader through a filter gate. When there is debris on the plate for more than a few seconds it means the loader must be full and won't output small packets.

 

A potential complication is a debris formation temperature bug that was fixed but then reintroduced. Still in the game AFAIK. But most people don't care or are even aware. If you do care, have the debris fall onto the plate instead of forming right on it and the bug won't happen.

[JRup]

I shall shamelessly plug one of my older posts regarding this:

 

If you're certain that the heat exchange in the conveyor line is more than enough then skip the temperature check altogether and just dump the cooled down material at the end of the line. Results may vary.

[Zarquan]

I would put in a sensor on the line somewhere on the cooling system that detects if the material is still obscenely hot.  When it is, it will activate a conveyor chute or a conveyor shutoff on the next piece of rail, dumping the material out of the system.  If you have a chute, you can then have a weight sensor and a sweeper with a conveyor loader that loads it in to the cooling system when there is more than a gram (less than a gram is the threshold for thermal conductivity).   If you use a shutoff, you can have that output to a chute with the source of the iron, which will then combine with existing iron eventually and sort itself out.

6 hours ago, wachunga said:

My favorite solution is to never allow microgram packets on the rail to begin with. Stick a weight plate wherever the debris falls. That weight plate controls the conveyor loader through a filter gate. When there is debris on the plate for more than a few seconds it means the loader must be full and won't output small packets.

 

A potential complication is a debris formation temperature bug that was fixed but then reintroduced. Still in the game AFAIK. But most people don't care or are even aware. If you do care, have the debris fall onto the plate instead of forming right on it and the bug won't happen.

Problem is that if you can't do that with a volcano if it is in the steam room, as you can't replace the neutronium floor.

[wachunga]

7 hours ago, Zarquan said:

Problem is that if you can't do that with a volcano if it is in the steam room, as you can't replace the neutronium floor.

True. Didn't occur to me because I never run volcanoes directly in steam due to the aforementioned bug. I always drip the material into a pool of lead or crude.

One could use an automatic dispenser and an additional sweeper to first move debris onto the weight plate and then from there into your loader. Certainly less elegant though, hmm.

[melquiades]

19 hours ago, Charletrom said:

Put two conveyor thermo sensors side by side, run the automation wire through both, and have them output a green signal when the desired temp is reached. This way a normal mass packet behind the micro one will allow it to leave the loop.

Two adjacent micropackets would break this setup, but I’ve never seen that happen

 

Wouldn't that let a regular very hot packet to go through from time to time? like If a regular very hot packet is followed by a colder packet? I am currently using this and i think™ it can happen:

 

 

 

 

[YOLO KNIGHT]

It might, but when you're in the mcg mass range it's a rounding error and won't affect anything

[melquiades]

7 hours ago, YOLO KNIGHT said:

It might, but when you're in the mcg mass range it's a rounding error and won't affect anything

I might have not made myself clear, sorry, not my mother tongue... but i guess even if they are 50 kg and they slip through, they don't have much heat capacity to matter anyway.

Now i have to find some room in my set up for that... ugh.

[Charletrom]

33 minutes ago, melquiades said:

I might have not made myself clear, sorry, not my mother tongue... but i guess even if they are 50 kg and they slip through, they don't have much heat capacity to matter anyway.

Now i have to find some room in my set up for that... ugh.

I don’t ever have large temp variances between adjacent packets so I don’t encounter this issue. Your setup is very nice but is a bit more elaborate than what I use.

[meekay]

In my metal volcano tamers and cooling ponds, I set up a conveyor with a shutoff set to move material to the next stage once I've extracted the useful heat out of it. As you note this occasionally results in micro-quantities of metal on the rails that refuse to cool down. The gold volcanoes seem particularly susceptible to this. The simplest solution I've found is to tie in a Timer set to flush the conveyor once every ten cycles or so. If you set the timer to (size of room) seconds Green, click the Mode button, and then push the Red slider all the way to ten cycles, you'll end up with some funny-looking numbers for the green duration but it will work correctly.

Yes this means you'll occasionally end up with hot material in your output, but as a practical matter it won't be often enough or a large enough quantity to matter. I tend to send it on a big loop around the base through a bunch of "sorting facilities" where it will eventually land in a room full of priority-1 storage bins.

 

[JRup]

The timer sensor is a traditional way of sending packets down the line for cooling.

Another nifty way of regulating the rate at which material is sent is now the conveyor meter, removing the need to check packet temperature if correctly set up (this way you'll never care about µg amounts on the line); both its automation ports will need to be used to ensure continuous operation. This will be of particular importance once the newest update is officially released.

I use this method for my gold volcano tamer.

[Saturnus]

An example of such a system without temperature control because it really doesn't matter what the output metal temperature is as long as it's below 100c so it can be transported safely through drip locks is my shiny new ultra compact, ultra energy efficient, grid connected or autonumous, mirrorable, and square universal metal volcano tamer. Only change to the setup below I found to be any improvement after long term testing is to flip the conveyor loader around to add a single extra rail section for the output metal to lose a tiny bit more heat.

The safe setting for the loop temp sensor is 98.0c precisely. And the min/max'ed setting is 100 minus average temp of steam towards the end of an eruption period (not an individual eruption) divided by 100. Example: 162c average = 100 - (162/100) = 98.4c

About 110kg/tile steam in the steam room is recommended.

Conveyor meter valve is set to the average output of the volcano in kg (rounded up). Example: 308g/s average = 0.308 "units" on the valve

The output conveyor rail does not have to travel the distance of the ST. As long as it passes through the metal below the meter valve, it's fine.

To those that don't know. AT Assisted self-cooling works by having a cross between a AT cooled and a self-cooled setup where it is important the temperature sensor loop is a little distance after the AT output so that when it triggers the AT it only runs for the exact number of seconds as the number of pipe sections between the AT and the sensor. If you have the temperature sensor in front of the AT as normal then you'd basically cool the entire loop before it stops, and likely overcooling the system. The object is to keep the ST between 95.0c and 99.9c. Not below, not above. And preferably as high as possible to maximize the self-cooling, so the AT has to run as little as possible.

 

[JRup]

1 hour ago, Saturnus said:

Conveyor meter valve is set to the average output of the volcano in kg (rounded up). Example: 308g/s average = 0.308 "units" on the valve

I've found that eruptions may sometimes interact with dormancy periods resulting in an occasional over/under production. Rounding the value up somewhat will have a beneficial effect in that an accumulation of material won't happen over the long run. Thus, I'd round to at least 0.325 "units".

This may not apply for colonies that won't garner more than a thousand cycles, for example. (Who plays on the same map for so long anyway? )

[LadenSwallow]

Note that due to conveyor packets not merging, setting a conveyor meter to 0.308 averages to less than 0.307 due to 2 partial packets every 20kg assuming all inputs were originally 20kg. To minimise this effect, try to find divisor that leaves no remainder. Also consider an alternative automation system than output to input on the meter - e.g. a timer sensor that will set it on/off green each second for future patch compatibility.

[JRup]

5 minutes ago, LadenSwallow said:

Also consider an alternative automation system than output to input on the meter - e.g. a timer sensor that will set it on/off green each second for future patch compatibility.

On the risk of sounding subjective, I've found timings for the meters to be fairly consistent in the new testing branch and not in need of a timer. Said timer would be redundant as fractional packages trigger the meter's own automation on delivery and result in a properly packed line most of the time.

If anything, it would be best to use packet sizes that are consistent with fractions of the full 20kg packet (e.g.: 100g, 200g, 400g, 500g, 1kg, 2kg, amongst others). This introduces other kind of problems such as remainders when the package to split is not 20kg which throws us back for a loop with the original problem of having disruptions in the line on account of the timing of loading another packet to split. It's still a non-issue in the context of the tamer presented above.

I'd still round up to 400g (0.4 "units") for the sake of not needing to deal with the gradual accumulation of material from several eruption/dormancy periods from said pauses in the material processing.

In short: the automation there is alright, the units can be rounded up a bit. Much depends on how long you decide to keep the save file active.

[Saturnus]

And here I thought going for simplicity and practicality over pedantry would be appreciated 

And btw, yes I am aware that in total if you round up from lets say 307.4g/s to 308g/s as in the example the actual output would be ever so slightly less than 307g/s on average.

That is intentional as the idea is not to completely vacate all the metal but to leave behind as little as possible... within reason. And let that slowly build up. We're talking leaving behind the rough equivalent of a single rail package, 20kg, over the length of a full activity/dormancy period.

You can always manually purge more metal by adjusting the setting should you feel enough has built up a few 1000 cycles later. 

 

[Saturnus]

Btw, there is room in the build for a timer sensor if you want. Then you can set it to the next evenly divisible value, and then figure out what the fraction should be to get the desired value. In the example used it's 307.4g/s. So if we set it to 400g/s and the timer to 123/37 it should be very close to the desired value (307.5g/s in this case because 123/160*400=307.5).

However, if you think that a timer sensor is more precise over 100s of cycles than the simple meter valve hack, boy have I got news for you. 

[LadenSwallow]

I would always advocate for the use of a meter valve since their introduction. Aside from limiting outflow, it also applies a lever type effect - amplifying the heat exchange effect at the expense of potential throughput, throughput that is actually limited by the volcano.

My previous comment was based on my previous use of a simple wire (only connected) into a NOT gate with the output of the NOT gate controlling the reset port on the meter valve. So I didn't ever use the output port of a meter valve at all.

The upcoming patch is negating the continuous green to a reset port approach for meter valves, so my previous comment was with regards to an alternative approach to pulsing a green signal for when the packet size doesn't evenly divide the 20kg packet size of the conveyor rail. Pulsing continuous reset signals from a source other than the meter valve itself would prevent 2 consecutive packets of less than meter valve size (causing 1 packet of less than meter valve size before resetting for the next packet on the rails). A non-issue for a packet size that evenly divides.

Thank you for demonstrating a system to enable both regular packet sizes and precise output. I'm unsure on the effect the interruption to packets will have on consistency of temperature output - my initial thought would be temporary miniscule deviations from the consistent average output, where the deviations cancel out over time. I think I would just stick to simply the meter valve, either self resetting or timer resetting.