Assembly Line Automation

Once you reach the end of IV you'll make your first assembly line. Starting out you won't need to make a lot of parts in it, however towards the end of LuV this will ramp up. Eventually it will become a hassle to input all of the fluids and items manually, bringing automation up as a solution. You have many ways to do this, with varying levels of simplicity and reward to them. SFM is an easy pick to start with, however the downsides are that adding each new recipe will take a while and never gets easier. Open computers can do this as well, however you will find a similar issue with trying to turn an AE recipe into assembly line recipes. Most methods for automation require you to setup each new recipe in a specific way, which is usually not very fun to do. Here we will go over the basics of SFM automation, as well as an alternative to SFM/OC which makes additional recipes much simpler and faster to add.

Here's a YouTube tutorial that may help: https://youtu.be/xXyrfBmeTBI

Steve's Factory Manager
https://youtu.be/k1xSPyO6Dng

SFM has many ways to tackle this automation challenge. Usually people using this method will follow a simple pattern. You can use conditions to check for a recipe, then push specific items and quantities to specific busses. This works, however it's not great for expansion, as each new recipe will need a new set of conditions and movement. Here I'm going to propose an alternative method that doesn't need any changes when adding new recipes, or even adding new assembly lines in parallel.

This method relies on two strange techniques. First is item renaming. This is the action of using a GT naming mold in a forming press, to give items a different name. This is to force the same type of item to not stack in an inventory. The other technique you need is variable loop position storage. This is to be able to put all your input busses on the same variable, and still distinguish which machine is which.

The naming is quite simple. If you need one type of item in more than one bus (for example fine wires in motors, circuits in fusion reactors, etc) you will need to rename all stacks but one. For a motor that needs 4 stacks of the same fine wire, one stack in a recipe can be normal, while another needs one unique name, another needs a different name, and so on. Generally you won't be pushing straight to the busses but rather having an intermediate inventory. This allows for more than one recipe in a pattern as theoretically you can have 16+ depending on the recipe.

The next big thing is variable loop position. This is a bit of a weird tech, but you'll find it invaluable here. SFM has variable loops, which allow you to iterate through all inventories on a variable, and do complex logic on each one. Here we are going to use loops to find the first open assembly line, then another loop to push to all the busses on that specific assembly line. This might seem a little complex as it's so abstract, but the logic is more or less very simple. If you move a single item every loop, the quantity of items in the destination inventory will be equal to the amount of times you've done the loop. Here we will use that idea to iterate through the first busses of each parallel machine, find the first open one, then use that position to move all the items into the right busses.

Setting this up is fairly straightforward if you grasp the concept above. Essentially all you need is a variable for your AE input chests, another variable which holds the first input bus (and drawer if you want to allow large recipe inputs) of each assembly line, and a final variable which will contain every input bus and output bus (or input drawers and output inventory). The only building constraint is you will need your sfm cables to run in series through your machines.

Open Computers
https://github.com/botn365/assembling-line-automation-OC/tree/parrallel_processing

- WiP-

GregTech
An under utilized option for assembly line automation is GT itself. GT pipes exhibit a pulling system that is capable of translating an ordered set of item stacks in one inventory, into a similarly ordered set of inventories holding singular stacks of items. Pipes will pull the first stack from an inventory, and push it into the first open inventory they see. This can be used with pipes that limit stack size to 1/s or below, to order the inventories in the same order as the items in the initial inventory. Essentially you start with items A, B, and C in that order in inventory 0, and end up with items A in inventory 1, items B in inventory 2, and items C in inventory 3. As AE will input items in the same order as a pattern, this can be used to order any recipe in the assembly line order it needs. Simply hooking up a large throughput pipe backbone onto 1stack/s or lower branching pipes, will be able to order any items you give it.

Fluids do pose a bit of a change to this, as simply putting them before or after items results in some spacing issues. An easy solution is to provide a GT filter with volumetric flasks, set to ignore NBT before a restrictive pipe that leads to the item outputs. This will pull any fluid separately, while not impacting item ordering. Fluids can then be stored in a separate ordering of chests, which will lead to the input hatches.

When it comes to removing items from inventories and pushing them into assembly lines, you have many options. Pure GT will again work here, and allow for an infinite quantity of assembly lines in parallel. Simply provide an "in use" signal from your full assembly lines, and use shutters to block inputs. If inventory 1 is connect to assembly line 1 bus 1, assembly line 2 bus 1, etc, it'll move your items to the first free assembly line. Doing the same with fluids will result in a perfectly working automated array of assembly lines.

One small issue is sometimes non full stacks of similar items can end up combined. For example, 4 stacks of single quantum circuits for the fusion controller can end up with 4 circuits in a single bus. A very simple solution to this is to use the naming mold to give stacks different names. Doing so removes their ability to stack with each other, and forces separated items.

You will probably want to do some redstone logic on the AE input and sorting to avoid mixing recipes, but how you do this mostly comes up to choice. A shutter on the top of your AE input chest is a big help to avoid mixing recipes.

https://www.youtube.com/watch?v=QKW8PzoiHNw Here is a short video explaining how this works, and the basics of setup.

Applied Energistics and Redstone
For those who prefer to use AE and some redstone, here a video made by Alexdoru, explaining the basics: https://youtu.be/xXyrfBmeTBI.

FullAuto parallel fluid assline with AE2 and GT v0.4
Working demo: https://youtu.be/8q9AXvagr_8

Advantages

 * Using low tier components, to build it the biggest gate the assline itself
 * Parallel processing up to “infinite” amount of asslines (some more testing needed :D)
 * Can run from a single AE2 interface
 * Full support for fluids and split itemstack recipes

Pre-requirements

 * Forming press with Mold(Name) to prevent items to stack. (needed for some crafts eg.: T5 rocket alloy or fusion computer). Later a Processing Array (PA) is recommended to mass rename items.




 * Volumetric flasks: to insert fluids. Multiple mB values are needed: assemblers to “program” then fluid canners to fill. Note: stack size is 16, recommended to use the largest possible option. Only one stack of a single fluid type can be used.


 * Processing pattern terminal: when the regular 9slot terminal is not enough

Renaming items

 * preventing materials to merge in a recipe
 * Forming press automation
 * Name mold required. To set the name of the mold use an anvil
 * Write an AE2 pattern to make a renamed item from a regular item.
 * Use ME interface on the forming press


 * PA automation
 * after building the PA it can rename stacks of items in seconds
 * Controller needs to be set via a screwdriver to separate input buses. This will allow you to use many different rename molds.
 * input buses needs to be set via screwdriver to turn off input filter.

Writing patterns

 * Order of items is important, pay attention to stack sizes (prevent stack merging).
 * Fluids (flasks) can be placed anywhere in the recipe but the order of fluids is also important.
 * When not possible to use a single flask (when fluid requirement is so low) set the pattern to craft multiple items at once with a single flask.
 * Maximum recipe complexity: 15items and 1 fluid. When more fluids required in the crafting, the “normal item” count is decreased.
 * Its enough to make a single pattern.

Working principle
1.      Items from the pattern enters the ME interface with blocking mode enabled and the “output arrow” set to the main pipe. 2.      With the blocking mode enabled, only items for a single recipe will enter the item pipe system at a time. When there is an order waiting for an empty assline the first pipe segment will hold the items and prevents the interface to insert in a new order. We need to move the entire assline recipe as a single burst into the assline bus-connected pipes so the pipes have to handle the 16 items all at once, thus I use huge PVC pipes here. (they move 16 stacks/sec). Higher capacity pipes can also be used. Once all of items found its destination the items for the next recipe gets inserted.

3.      The items “travel” inside the main pipe, which needs to have as high routing value as possible. I am using restrictive pipes to increase the routing value to 204800 on each segment. Each output from the main pipe needs to have a unique pipe segments before the exit. (eg.: to reach the first assline I use 6 huge PVC to reach the second assline I have to use anything else than 6 to prevent collision. 7 is fine)

''Note: Item handling in GT pipes is done by calculating routing values based on the pipes routing value and the possible paths an item can take. Each item will exit at the smallest routing value (if it is not blocked)''

4.      The main pipe connects to a different pipe system via a shutter cover. In this item pipe system, the routing values has to be as low as possible. In the demo I use fluxed electrum item pipes which helped me in troubleshooting but you can use regular huge PVC pipes without the restrictive modifier (huge pipes block access by hand to the connected input buses)

5.      The assline is ready to accept new items when its first ULV input bus is empty. This is checked by an item detector cover. The signal from the cover gets picked up by a machine controller cover on the pipe and it controls a shutter to block/allow input



6.      The first output needs to be connected to a GT item filter. The voltage tier is not relevant. This way all fluids will enter this path. Configure with 4 volumetric flasks and set the NBT to be ignored. This way this filter can accept the 4 flasks at once and can output them at once while preserving the order. Here any type of pipe that has at least 4stacks/sec throughput can be used.

''Note: this limits the fluid input to max 1 stack of flasks per type. Also, to use higher capacity flasks they also needs to be configured in a similar way.''



7.      The flasks then enter in the fluid tanks where the fluid gets pumped inside the assline hatches and the empty flasks gets piped out to the output (blue pipes).



8.      The rest of the items will enter to the ULV input buses in order, the shutter will close and soon the assline starts to work. When it picks up the items the shutter will open and it will queue 1 recipe. While the shutter is closed the next shortest path is used (the 2. assline)

9.      When the processing is completed the output enters the blue pipes and gets inserted to the ME system by the main interface.

Summary
The main bottleneck of this design will be the distributing pipe system itself. GT pipes move bursts of items with a delay and more testing needed to figure out how many asslines can it feed with constant processing. A possible workaround to this problem to get rid of the main pipe (in the picture the gray PVC ones) and use separate ME interfaces at the input of each assline. (btw this is how I automated the CALs)

''Thanks for reading. On my current tech level (ZPM) i can't really test the speed, im far from utilizing 100% of my 2 asslines. Feel free to test, improve the design. - Szajkop#0522''