I'm trying to build a crusher that will select an item from a source belt, derive the recipe for it, and then process that item.
The simplest reasonable setup I can think of is to make the input belt send a signal to the crusher to set the recipe. The input should read the ingredients required and fill the crusher. The output arm should wait for the recipe to be finished before unloading anything.
Unfortunately, what ends up happening is that the crusher gets a signal and sets it's recipe. This allows the input arm to feed it an asteroid chunk. However, before it can start processing, the output arm grabs the contents and removes them from the crusher.
I thought of trying to subtract the "recipe ingredients" from the "contents" on a signal network, but there's no way to differentiate them. It would be helpful if I could specify that either output is on the red or green wires (or use negative values for ingredients), but alas this is not supported right now.
Is there any way to make recipe selection (for crushers, or anything, really-- but I've only experimented with crushers) work in this kind of dynamic and fast-changing environment?
Re: multi-purpose crusher. Not crushing anything
Posted: Sat Nov 30, 2024 7:32 am
by fryyyy
Yes, this is very possible.
The issue you're running into is the recipe changes before the grinder begins to grind. Once it is grinding, a change in recipe wont take effect until the grind is complete. A "dirty" solution is to, when determining which recipe to set, also read the contents of the inserting inserter and the grinder. There's still an issue with this: if another asteroid type comes into the detectable region, you could get a recipe switch, ruining your attempt to grind.
The full solution is to read the source square (likely a belt) and the inserter+grinder combo separately. The source square will set the initial recipe and allow the inserter to target that type of asteroid for insertion. Then you want to shut off detecting the source square while the inserter or grinder have contents to prevent new asteroid types from switching the grinder's recipe. Detecting the contents of the inserter+grinder will keep the recipe active until grinding is complete.
Here is a blueprint, I aimed for readability so there's room for optimization. Each of the combinators have descriptions to let you know what they do.
I was trying to come up with something like that but for asteroid reprocessing, and i see same issue in this blueprint, it cant handle asteroid reprocessing because crusher gets basic recipe from item in inserter
Re: multi-purpose crusher. Not crushing anything
Posted: Tue Dec 03, 2024 3:24 pm
by allbodies
I was trying to do something similar, but instead of inserting items from a belt I'm inserting asteroid chunks into the crusher straight out of the Space Platform hub.
I'm also not setting recipes based on the item picked up - rather I'm using decider combinators to determine which recipes to send to the crusher based on asteroid chunks present in the hub as well as the capacity of the belts the crusher is distributing outputs to. Resultant materials go out onto belts and asteroid chunks insert back into the space platform hub for reprocessing.
Anyways, I also got into the death loop of inserters inserting into and out of the crusher simultaneously, which is how I found your thread.
I have one decider combinator per resource/recipe and they are configured as follows:
if [asteroid_chunk_count] > 0 AND [output_item] < [whatever I think my belts can hold without clogging up things] THEN [send the appropriate recipe to a selector combinator]. The selector combinator then sends the recipes to the crusher one at a time.
To solve my issue:
- I added the contents of the inserter arm to the [asteroid_chunk_count] network
- I added the contents of the crusher to the [asteroid_chunk_count] network
This at least gives my crusher enough time to start processing before the other inserter (which is filtered specifically for asteroid chunks) picks the asteroid chunk back out of the crusher.
Sorry for the longwinded explanation, but I hope this helps.