Chemistry Automation

Constant craft with fluid AE

When automating recipes with fluids, you might run into some issues. You can't quite use a fluid in an AE pattern, fluid movement can feel more difficult than items, and trying to run more than a few recipes in the same LCR can seem impossible. This page is dedicated to solving all of those issues, and possibly even more. While only three options are shown here, it's entirely up to you how you set any of this up. Once you understand the basics of automating Multiblocks, fluid logistic options, and cycling recipes, you will be able to freely explore the world of multiblock logistics.

First off, there will be a more simplistic method for automation. Simpler to setup and understand, yet lacking in many areas. Afterwards is a more complex method, that will give better results when it's bonuses start becoming more apparent. The simple option focuses on constantly filling the LCRs, while the more complex option focuses on combining all your recipes into a single LCR.

Automation Challenge

Applied Energistics has fluid support through the Extra Cells addon. This includes import, export and storage busses and interfaces, but there are no processing patterns that can be used for autocrafting fluids. Here we want to build the next best thing: A setup that stockpiles a configurable amount of all the sweet chemicals we need.

Since we want to use Large chemical reactors for our setup, we have to deal with the problem, that GT multiblocks void output, if there is no available space in the output hatches. This can be achieved through redstone covers on the controller or, what we will do here, regulation of the input amount.

Components of the setup

The GT Large Chemical Reactor is our main machine, the rest is only logistics and regulation.

GT Super Tanks are used as fluid storage, since they offer good capacity in a compact block format. They are also cheaper and less prone to random failures when updating the modpack. They can take GT covers. (Basically don't use extra cells storage drives)

GT Fluid Detector covers can be slapped onto GT tanks and give out a redstone signal, that is strongest when the tank is empty and weakest when the tank is full. This can be inverted to get a redstone signal proportional to the amount of stored fluid. Note that the latter mode is called inverted and the former is the standard mode.

Dense Redcrystals from Automagy are redstone contraptions, that output a signal only if the input signal is equal or stronger to a configurable threshold. This threshold can be adjusted by rightclicking the center crystal with a Thaumcraft wand. You can also use the wand to configure, with which sides the crystal can interact by toggling the smaller crystals on the sides on and off.

Extra Cells Fluid Export Busses just do what the name suggest, they output fluids from the network to the tank they are connected to. The fluid to export can be set by clicking with a portable fluid container (for example IC2 cells or universal cells) onto the center square in the GUI. They can also take expansion cards.

The Redstone Card from AE can be used to allow our export busses to be controlled by a redstone signal. They go into the slots on the right in the GUI. Then a button on the left appears, that allows us to specify in what way the bus is supposed to react to a redstone signal.

Extra Cells Fluid Storage Busses can be used on GT tanks and allow the network to see and use the fluid in the tank. It is recommended to use the whitelist feature by clicking a fluid container onto one of the squares in the GUI. This prevents the network from inserting any unwanted fluid into the tank in the case that it is empty.

Setup

Start by building a LCR with only one output hatch. This goes on the front into the top row. We will need 1 LCR for every 3 recipes we want to automate. If you want more speed, you can share walls, but you can only support 2 recipes per LCR. It is recommended to put the cupronickel coils towards the sides to have more space for hatches on the back. If you need a circuit for the recipe, that will go into the controller. All recipes you want to automate with one LCR will use the same configuration circuit.

For every recipe, we need to identify a unique input resource, that is not needed by the other recipes in the same LCR. This will get input through an Input Hatch on the back of the top layer, 2 blocks behind the appropriate Output Hatch. It is recommended to use a fluid as the trigger resource, as the internal sizes of fluid hatches is much smaller than that of item busses. It is also recommended to use LV hatches for the same reason. Larger hatches will lead to a delayed shutoff of the processing, since the ingredients already input will still be processed.

Also set up a Fluid Export Bus on this Input Hatch, insert your shiny Redstone Card and turn the Redstone mode to Active with signal.

For all other ingredients we set up Input Hatches or Busses somewhere on the back side of the LCR, but not in the top row. These can be kept filled constantly using AE (Fluid) Export Busses.

If you have set this up for one recipe, activate the LCR for one recipe and then lock the output hatch to the product by shift rightclicking it with a screwdriver. You will probably input the trigger resource manually for this one run.

Now you can place a Super Tank on top of the Output Hatch. You can also directly connect a Fluid Storage Bus to the top of the tank. Don't forget to whitelist the appropriate fluid in the bus to prevent AE from inserting other fluids. Lucky you already got that one cell of product, eh?

Onto the back of the Super Tank goes a Fluid Detector Cover in normal mode, so no need to screwdrive it or anything. Between the cover and our Export Bus with Redstone Card goes the magic Dense Redcrystal. Deactivate the 2 connections to the sides, so it is only connected to the cover and the AE Export Bus. Then set the the signal threshold on the Redcrystal. A threshold of 15 will mean, that the system will stop production if there is any of the fluid in storage. The lower the number, the more will be kept in stock. Don't set the number too low though, we need some head space in the tank, since the LCR will still process ingredients already in the Input Hatch after the shut off.

Now rejoice, for you are done. At least with the first recipe that is. Have fun expanding this to a full line of LCRs.

Conclusion

While this method excels in simplicity, you will notice you start to need many many reactors. Oil alone will put you at more than a handful, adding PBI/circuits/Pt proc increases the count by a lot. Extra cells also has its downsides when using import/export/storage busses, which can also be avoided.

Pros:

very simple to setup

Avoids <2tick recipes better than single LCRs

If needed, LCRs will run 24/7

Easily expandable

Cons:

LCR counts can get very high with this method

Your overall machine on% will be very low for most recipes

Relies on fluid AE

SFM based recipe consolidation

One alternative to the constant fill method, is to use Steve's factory manager. Through its precise movement system, you're able to move whole increments of recipes. The upsides of this method, are that they let you condense essentially infinite recipes into a single LCR. The circuit integration will have to be the same on them, but that will still save you many LCRs. On top of this, as all recipes run in the same LCR, if you do it right, it'll be able to run 100% of the time. In single machines per couple processes, with some taking different times, unless you void outputs, many machines will be off, waiting on the slowest part of the chain to run.

I will explain each step in detail, however here is a visual representation of what you want to do: https://youtu.be/WhrYZsUyEw4

Basics of SFM LCRing

For the most part, sfm based LCRs are very simple. They rely on the same idea of crafting when buffers are low, however they used this as a method of triggering a 'craft' command. This command is a set of conditions, inputs and outputs. The basic structure follows as such

>LCR check

>Output(s) check

>Input(s) check

>Pull inputs

>Push inputs

>Pull/push outputs (optional)

I'm going to skip explaining the LCR check step until last, simply do to the complexity. However in order, this is what those commands are meant to do.

Input/Output check

These are the first two commands after the LCR is deemed fit to craft. The output check is a fluid condition that checks for your desired buffered amount of fluid. On true, do nothing, on false, continue onto the next condition. This will then activate when your buffer is low, starting the crafting. Input check is preformed on the same set of tanks, but will check if you have everything you need to run the recipe. This time, a true value will proceed, while a false will end the chain. Check for all fluids/items, at the right quantities. I find it easy to set all fluid storages to a variable, so checking them is easier.

Push/pulls

This is simply one input/output for fluids, and one for items, depending on what the recipe will do. Pull from your storage area, and push into the LCR hatches. Simply chain these together to end the crafting steps.

Outputs

How you handle your outputs is up to you. I personally find that eio conduits on the output hatches, that feed many drums/tanks works well. You can use whatever you want here, it's not just limited to sfm. However, if you wish, you could add commands to your sfm to always pull fluids from outputs and push into certain tanks. The issue is you will need to define the specific tanks each output. I find using eio filtering is less bulky with larger setups.

LCR checker

This is by far the most complex part of sfm automation on LCRs. The idea is that you never want to be crafting 2 recipes at the same time, as fluids can mix between them. To accomplish this goal, you have many options. You are essentially just trying to turn the concept of "Is it safe to put items into this LCR" into a true/false condition. You can certainly use OC here, however if you're using OC, you're probably better off completely avoiding sfm.

One method is the hatch fill method. As long as a hatch is filled, there is still fluids in it, but the second they all empty, you're safe to put whatever you want inside. This seems to be the fastest method, as it relies on the initial event that itself allows more items to enter the LCR. Sadly there is no sfm command to check if a tank has any fluid, so we need to work around that. Putting fluid detectors on hatches, and item detectors on busses, can give fill level as a redstone signal. Through splitting the signal between on/off when the hatches/busses gain even 1 item or 1L of fluid, you can use this as somewhat of a "ready to craft" mechanic. When they all signal empty, you're all good to input another recipe, however when they signal full, you will want to disable additional recipes being added.

If you use the fluid detector method, you can simply link that redstone output to sfm. With a receiver, you can use true/false to enable and disable all crafts. Depending on what your high/low signals mean, youll end up with one value signaling a clear LCR, and the other signaling a full one.

There is another option for sfm fluid detection, however it's somewhat painful. You can use a fluid condition that lists *every* fluid that is input into that LCR. If you require it to have none, this can be used as a fill detector. The downside here is that if you have a lot of recipes, this can easily get tedious to do. For that reason alone, I recommend using another fluid detector method. However, the upside is that if you leave out the fluids the specific recipe uses, it will only halt input of different recipes. However if the LCRs are full, but full with the same recipe, it will allow you to still push to it. This reduces the main slowdown on this method, being the slowness of SFM updating.

Conclusion

SFM is a decent option for combining recipes in a single LCR. It works very well with fewer recipes, however it can be forced to work on larger recipe counts. One tip I will give, it's easy to setup a base group that you can copy when you need new recipes. Simply changing the values on some fluids is much easier than making all the commands over again. Also, setting your hatches/busses to variables can be useful when adding new recipes. No need to go digging through the 16+ hatches for the 4 you need every time. However, this gets rough with multiple LCRs, due to the fairly low variable limit.

Pros:

Fairly straight forward

Easy to add new recipes

Fairly fast recipe switching

Able to combine all recipes of a similar circuit integration into a single LCR

Can avoid fluid AE if flasks are used for AE in/out

Cons:

Recipe swapping can take >1s when you ideally want 1-2t

Sometimes recipes will get stuck from SFM not completing a full command before the redstone disables it (could just be that I did it poorly, but I've experienced this with sfm in a few ways)

SFM alone can only specify fluids up to 999000L, meaning super tanks and such need extra infra

Can be laggy if done weirdly, or simply many 500+ command managers exist

Flask based recipe consolidation

Without venturing into OC, this is the best method for LCR automation I have found. The idea is to use AE and volumetric flasks together, to turn recipes with fluids into recipes that are AE compatible. While this doesn't seem to have any drastic benefits, it's quite useful. This combined with the speed of the item transfer, and the seemingly flawless functionality, makes flask based LCR automation a top tier option. You will be using flasks, items and empty flasks to accomplish the same goal as SFM. While it might try to function similarly, it's far superior.

Intro to flask chem

Much like SFM, you will be preforming actions based on similar criteria. Some of these actions will be done for you by AE, but some you will need to externalize into the game world. The same basic idea holds. You will check if your LCR is empty, if you have the inputs they will be pushed from AE, it will craft your recipe, and then once empty will restart with another recipe. Some of the ways the steps are done is different, some the same, but you will see many similarities. This is primarily because the flask method was made to build upon the sfm method, while fixing many of its glaring issues. It will use volumetric flasks to quantify fluids into discrete chunks with known values. Then will use AE for item input, and some GT for filtering.

Once again, if you wish to read about, I will explain it in detail. However, I have also made a tutorial video showing what to do: https://youtu.be/CGPWCnDKxZU

Challenge

There's a handful of obstacles we need to find ways around. Without sfm's specific fluid movement, we're forced to quantize recipes another way. Volumetric flasks will be our method of choice, for a few reasons. They provide not only a 32000L quantization, but let us move discrete values of fluids ranging from 1-32000L. With these being treated as items rather than fluids, AE is able to input all the needed ingredients like any normal recipe.

Once again knowing when the LCR is empty will be an issue, however it's tackled the exact same way as with SFM. Using fluid/item detectors we can turn the state of the LCR into a redstone output. By inverting the fluid detectors, and leaving the item detectors normal, we get a signal of 1+ if there's any items/fluids in the inputs, and 0 when it's all empty.

Sometimes recipes can have outputs that need different cells, or need certain stacks in certain hatches. This is done through using drawers to accept all similar item stacks. So if we put a flask of one size, then some flasks of another size, they will end up in a hatch with all the same sizes. This allows us to use output flasks of different sizes to dictate which hatch they will enter.

AE doesn't by default have the same mechanic of stock keeping that SFM/LCR spam will have. It's based on demand based crafting, as opposed to continuous production. However, we are able to use crafting cards and interfaces to equate the same principle with any fluid/item. Simply put the card into the interface, set the item type, then pull it to another buffer. It will pull/craft until that buffer is full, then stop.

Not all recipes output in the same quantities, so we either need all of their batch outputs to reach a common flask volume, or need a way to include the flasks with the recipe. Here I've chosen to place them in the recipes. With the larger pattern terminal, you're more limited on outputs than inputs, so sacrificing some slots to output cells isn't the worst thing. You can have a packaging setup that will use flasks based on what fluid is present, or which recipe is ran, but that gets a lot more complex.

First steps

Much like with SFM, our initial step is going to be defining when the LCR is ready for an input. Similarly, I've found the best method to be the item/fluid(inverted) detectors, as they clearly define when inputs can and cannot mix. While we aren't using sfm, we'll have to employ some redstone mechanics to translate this idea to the rest of the item handling. Setting up redstone on the input detectors, then running it through a not gate feeding a pulse former is a good start. This will give a singular pulse every time the machine is cleared of inputs. We can use this in conjunction with detecting when the machine gets inputs to toggle all the behaviors. Allow input until it recievs inputs, then block future inputs until the LCR becomes empty.

AE Input Chest

The next thing you'll need to do is setup an input chest from AE. This will receive all your flasks and items, and be the start of the crafting process. I recommend using a GT chest buffer simply due to their ability to have shutters attached. There's periods in which you will not want item input, and the shutter module is a very useful tool. Attaching the shutter to the face that touches your AE interface, and setting it to "open when work is enabled/disabled" allows for a redstone signal to close off this inventory. Attaching a conveyor to another side of this inventory will allow it to push into a GT pipe. Set this conveyor to enable with a redstone signal as well. Put an item detector somewhere you will be able to pull the signal from. You will also need a machine controller to enable redstone control on the block. This allows for a chest that will receive one recipe's worth of items, and to move them needs to disable input of more items. To fully achieve this you will also need to set your AE interface to blocking mode.

Item movement

You have a LOT of options open for how you move items. I've found AE interfaces and storage busses to be quick and reliable, with good ordering of similar items. The downside is AE doesn't have a good way to enable/disable transfer, so I've been pushing into the interfaces with GT chest buffers. This way I can toggle the conveyor with a signal.

From the AE input, you'll need to send the items to the right LCR. Ideally you'll use some system to push to the first empty LCR. From there, the first step is to pull all the empty flasks from the recipe items if you're using this method. The way I've been doing this is by using a GT item filter. Simply put an empty flask of the right size in the filter, and set this as the first direction. The sad part about filters is that they can only handle stacks/t equal to the amount in the filter. So if you're capturing 4 stacks of flasks worth of fluids, you'll need 4 flasks in the filter.

The alternative route that fails the item check for empty flasks will need to be once again connected to an item filter esque option. Sfm can work here, by putting a flask in the filter, then setting NBT independent detection. You can also use GT filters with NBT disabled, as well as other options. This will separate all the flasks with fluids from the items left.

The remaining items should be routed into your input bus. These will only be items at this point, as all the flasks have been siphoned off.

Small tip, the amount of items in the item filter will determine how many can pass through the filter at once. If you have a recipe with 4 input flasks needed, and only filter 2 in the item filter, it will mess up and send the other 2 into the input bus instead.

I personally recommend using drawers to hold items before they end up in the LCR. This allows you to use the emptyness of those to bring another recipe in from AE. This cuts that time out from the loss when switching recipes. They also work as good filters as they only hold one type of item, and you're not gonna be putting the same item in 2 spots.

Handling outputs

The final step of the crafting process is the outputs. We can simply shove an interface on the output bus. The fluids on the other hand, are a lot more complex. There's a handful of ways to go about this, but I'd encourage you to find your own, as all of mine haven't worked too well.

One idea is to bundle empty flasks with the AE patterns. This method works well for anything that has only 1 fluid output, but struggles with more than that. Filtering the flasks to end up in the right spot is difficult due to how filtering flasks works. The upside of this method, is that you only need 1 tank per output hatch. Downside is that it adds work to the recipe creation.

Another option is to filter fluids from the outputs. Using something like sfm, possibly eio, GT fluid filters, etc, you can pull all the fluids from the hatches, shove them into tanks, and use AE to fill those with the right flask size. This has the downsides of requiring one tank per fluid output, which can really add up eventually. You can consolidate better with sfm, but those fluid lists can get very long, and struggle with stuff like BW fluids.

In general, it seems like bundling the output with the recipe, as well as filtering the outputs into dedicated tanks, have their downsides. I'd recommend experimenting with possibly OC, or better sfm to make the output handling better.

Redstone logic

Now that almost everything is setup, you will need to attach the final redstone logic to the build. This is basically telling it when to accept AE recipes, as well as signaling the empty LCR. Essential just connect all the detectors you have to RS latches, and cycle between 2 modes. Ready for items, and not ready for items. Use this to enable/disable the inputs wherever you want

Creating Patterns

As this relies on AE, we will need to create AE recipe patterns for this. For the most part you will simply put your input fluid flasks, input items, and empty flasks for the output, into the pattern (if you are using this method), and tell it that this will craft filled output flasks. The few things to keep in mind, the ordering of your items will relate to the order of the hatches they end up in. While not crucial for inputs, for outputs this is necessary to put the right flasks in the right spots. Make sure you prioritize your outputs so you can make sure that the right flasks go to the right spots. Don't want your flasks going into a hatch that won't output anything.

Stock Keeping

Unlike the other methods, this doesn't have a native stock keeping aspect to it. While many will know how to do this with AE, I figured I'd explain it just in case. To buffer many items, set them in an interface, and put a crafting card in it. From there, pull them into a tank or drawer or whatever. You can store fluids as fluids or as items. Both have their pros and cons.

Conclusion

While superior in function to alternative methods, it's not always the best option to use. The setup can be a little complex, and it will struggle with some recipes due to reaching the lowest tick limit. The speed is relatively good, but some recipes will still cause your higher tier LCRs to shut down between recipe swaps.

Pros: Fast item movement, under a second, possibly under 10 ticks if you setup it up for this. I've been able to reach 6-8 or so in my experiments, but ideally you want <3t

Easy to add new recipes simply using AE patterns

Many many recipes in the same LCR

Meshes well with flask based fluid xfer with AE for other uses

Cons: Somewhat bulky to setup for a few reactors

SFM can be faster at times to transfer fluids, depending on setup

SFM can add new recipes faster

Looses to sfm in batch size limits (999B for each fluids in sfm vs. AE flasks which will always have less than 999B for all fluids combined)

Fast recipes will still have the LCR turn off between recipes. I haven't been able to transfer fluids withing the 2tick recipe limit

Final tips

There's a few additional things I'd thought I'd throw in here. Some tips, and other ways to optimize setups that aren't unique to any method.

Running every circuit int

One thing that can impact the utility of chem automation, is the circuit integrations. Originally you could only swap circuits through swapping entire busses. However, with the addition of the GT++ super busses, we can now pull from these inventories. Due to this, you can input the circuit integration with the recipe, filter it out into the bus for the circuit, then empty that bus when the recipe finished. This allows you to combine every recipe into the same LCR, baring the possibility of needing more output hatches. This works with the sfm option, as well as flasks and normal movement.

Outputting fluids

Sometimes when you're doing recipes with high fluid output, you might have some issues. If you're outputting fluid simply by placing a tank next to the hatch, you might notice that other hatches are filling, even though you always have room in the tank. This is due to the hatches not pushing their fluids every tick. It seems to be every 4-5 ticks, so you need hatches that can hold a few outputs if you're running low time recipes. Usually LuV will work for everything, but avoid low tier stuff.

Speed

Much of the stuff surrounding multi automation like this, relies on very good speed. Things like the logic between detection and movement, as well as all the other item/fluid moving within the setup, will need good speed as well. Ideally you want to always be moving the entire recipe, not just a stack at a time. Things like high tier GT conveyors help a lot here, as a UHV conveyor will always be able to move any whole AE recipe in a single tick.

When it comes to the logic side of things, while OC and SFM are good for signaling states, they have their speed downsides. OC needs 1t per inventory, and sfm has its trigger delays. This has pushed me to use more vanilla redstone, and try for some sneaky logic that won't loose time. For example you can use PR motors to move redstone in/out of block, to allow or disallow signal transfer. This becomes what can be used as an and gate, or a latch, which won't loose any time when transferring a signal. Usually you won't be able to accomplish these more complex tasks in as little or no time, when you use more abstracted methods of signaling.

One generally frowned upon practice, is to force sfm to update by ticks instead of seconds. This can be done in a handful of ways, but I'll leave them out for the sake of servers. You never need to do this, and I don't recommend it, but it definitely can have it's place. By the time you'd be able to effectively use this mechanic without hindering the server, I'm sure that the methods will be clear to you.

Fun fact

This method of recipe consolidation works for almost every multiblock. It won't be able to swap machines in PAs, and doesn't really keep order like the assline needs, but for PAs, non ore proc ++ multis, etc, it will preform fairly well. Generally anything with recipes that are individually longer than 6t or so will have the best preformance. Depending how long your swap time is, you can achieve 100% up time on other machines much more often than with the LCR.