Filling the train with multiple types of items

[kangirigungi]

I'd like to fill a train with multiple types of items. What I did was to set a filter for each shot in the wagon, then put a requester chest that requests each type of item, then have a stack inserter insert it into the wagon. It didn't work out because when the train's slots for a particular item is filled and the inserter still has some items in its stack, it will just wait for additional space in the train. Eventually, I built a separate chest for each item, but it's a more complicated solution than I expected and it limits a wagon to 12 different types of items.

I guess limiting the inserters' stack size to 1 would solve the problem, but that would slow down the loading. Using 12 inserters would work, and I'd have the same loading speed as a single fully upgraded stack inserter. Is there any more efficient solutions?

[PunCrathod]

Connect the trainstop(set to output train contents) throught an arithmetic combinator that multiplies with -1. Then connect that to a constant combinator and a stack filter inserter(set override stack size on). Then set all the items you want to put into the train in the constant combinator with the desired amounts. This will make the stack filter inserter only put as many of the items as are missing from the train. Bonus points for connecting the requester chest to the system too so you don't need to set the requested items separately. It will just request what you set in the constant combinator.

[AlexMBrennan]

It would probably be easier to just make the train go to a bunch of different stations in sequence.

Connect the trainstop(set to output train contents) throught an arithmetic combinator that multiplies with -1. Then connect that to a constant combinator and a stack filter inserter(set override stack size on).

There are several problems with that idea: if you have 12 inserters per wagon then you either need to make sure that they are loading different items or you need to adjust the stack size limit because otherwise two inserters will picking up items at the same time will overload the wagon.

You might be able to get close with hardcoded thresholds (1st inserter activates when more than 0 items are requested, 2nd inserter activates when more than 28 items are requested, 3rd inserter activates when more than 42 items are requested, etc) but that will break if the 1st chest runs out of items first.

There is also the problem that the items will be loaded in a random order which is less efficient than loading items that are in the chest first. This could be fixed by masking the request (chest contents to decider > 0, output 1 multiplied by the request using the 2AB=(A+B)^2 - A^2 - B^2) method) but it will take about 8 combinators per inserter in total and this will also prevent you from setting requests dynamically.

[kangirigungi]

The problem with a stack filter inserter is that I cannot set both item type and stack size with electronic circuits, so I'd still need a separate inserter for each type of item, which is not an improvement over the previous design. I tried the method that I set the item type for a missing item, and shut it off at limit - stack size (12). This works, but then the train won't be 100% loaded and there is an edge case that can still overfill it. The circuit can only read the contents of the train when it is already in the station, otherwise it will think there is an empty train and the inserter will pick up the first kind of item and put it in the train even if it is full of that item. I even tried shutting off the inserter with a power switch when there is no train in the station, but that didn't help. I'd need a timer that enables the inserter a few ticks after the train arrives at the station.

So I'm back to square one. Using a separate chest and inserter for each item is the simplest and most efficient solution, with the only drawback that it only allows 12 types of items per wagon.

[Premu]

You can use up to 24 different items if you use two rows of chests and longhanded inserters. This gives you at least a stack size of up to 3 and doesn't force you to set it to 1.

[knighttemplar1960]

Premu's solution is the simplest but if you want it perfectly as you are looking for then this video may be of help. The section you wants starts at 15:06.
https://www.youtube.com/watch?v=AtN3ewXfZHM&t=1150s

[RiO]

Originally posted by kangirigungi:

I guess limiting the inserters' stack size to 1 would solve the problem, but that would slow down the loading. Using 12 inserters would work, and I'd have the same loading speed as a single fully upgraded stack inserter. Is there any more efficient solutions?

There's one thing you could try:

Read the train's contents and subtract it from set target amounts configured on a static combinator. Set the inserter stack size to half of that difference. This will converge to 1 for the final insert. (Why halve it instead of just setting it to the full difference? Because tick delays in the computation. Halving it should, taken into account that inserter swings take time, compensate. In theory, anyway.)

The big headache here is making sure whatever filter item you're setting for the inserter to pick, matches the hand-size difference you're computing. For that, you want a bit of machinery which computes the largest difference in the set. It's possible to create this with some clever combinator set-up; but it has some tick delays because it needs to converge. (Which is again; why you want to limit the stack size to half the difference and not the whole difference.)

You can then have each individual inserter responsible for handling a subset of the total family of items you want loaded into the wagon without being stuck at a permanent hand-size of 1.

[astrosha]

My own preference is the 12 chests, each limited to one specific item.

Space, ideally, is not an issue. Cargo Wagons are not very expensive, in terms of materials cost. If you need to bring 20 different items, a second Cargo Wagon is, IMO, the simpler thing to add to the design, as opposed to trying fancy circuitry that may or may not work as you expect.

I do just this for building style trains; 4-5 Cargo Wagons long, each one limited to 12 specific items (or less) in various, pre-planned quantities.

[RiO]

Originally posted by astrosha:

the simpler thing to add to the design, as opposed to trying fancy circuitry that may or may not work as you expect.

Definitely agree there. KISS.

[Tydo]

circuitry, lots and lots of circuitry sleight of hand.

One thing you could do, is set up virtual batches to be loaded (and blindly load from them with stack-inserters). Just have to stay a bit below wagon capacity to be 100% sure the inserters are empty when done.
It's a bit like graphics rendering. You draw a frame (fill a batch) and wait for vsync (the cargo wagon) to pick it up. Then you draw another frame, ....

There are 2 directions you can go with that:
1) complex signaling to stop loading more than x of each material. Bit like bufferless rendering and takes up less space.
or
2) set up a extra layer of batch boxes, into which you only load as much of a given material as you want in the wagon. This is a lot like #1, but you use the batch-boxes to load the wagon really fast.
Needs a bit more logic to not refill buffers while they are being emptied, but avoid the "how much have I put in the wagon so far" logic at the wagon inserters.
This is more like buffered rendering. Extra points for implementing double buffering so you are filling another (identical) batch while the other one is being emptied, to not waste capacity.

But really?
More trains, more wagons, no mixing, it is just way more complication than it is worth.

[RiO]

Originally posted by Tydo:

More trains, more wagons, no mixing, it is just way more complication than it is worth.

That's well and nice and all for bulk shipping, but if you're one of those people who wants to use builder trains ...

[kangirigungi]

Yeah, for transporting resources, I always use a single resource per wagon at least, but mostly a single resource per train. However, sometimes I need more than that. The first time I tried this kind of logistics was small outposts scattered at the edge of my occupied area, consisting of a few artillery pieces and defenses that can keep enemies out a fair distance from any pollution. I can build these from my own inventory (supported by a car, mostly for rails connecting them to the main network). Ammo and spare parts are supplied by train. In this case, efficiency is not that important. I use a single train to supply dozens of these outposts and it has a relatively simple loading mechanism (except for artillery shells, which has a separate train allocated). The only thing to take care of is to disable the stations if they have enough supplies. This way, the train takes a few rounds when a new base is built, then it spends most of the time sitting at home, only coming out occasionally when there is an attack. The same train is even able to handle hauling junk (stone and wood collected during construction) back to base. Still, I had to refine the loading algorithm a few times because I managed to lock it out of some of the resources.

However, I just started a bigger project where I build bigger outposts that are way too big to build from my own inventory, even with a car. I need several rounds from a train to supply the construction, which requires more efficiency, and this is the reason I started this thread. Thus far, the best solution is the original one, having a chest for each type of item. It's simple and efficient, and if I ever need more than 12 types of items in a wagon, then one item would have so little quantity that I could live with using long-handed more chests and inserters instead of stack inserters. I still need some circuits to disable the receiving station if it's full of supplies.

[Tydo]

Ok, now we are getting closer to your actual needs.
Not a endless feeding of many resources, with trains as the transports, as much as bulk moving of some (known quantity?) construction elements.
That changes things a little.
Unless there are special circumstances still undisclosed I think you can skip the idea of 12 boxes.
You may still be pulling from 12+ belts or lanes, but with signal attachment to the belts you can control exactly how many to let through and let them fill up the traditional 4 or 6 buffer chests via splitters and eventually get the whole thing hauled, by setting up counters that disable (block) then belts when the allowed amount is reached.
That way you can pick from any amount of belts you care to have, just have to attach signal network and some arithmetic to get the counts you want.
(a sketch would make 1000 words, but I suck at using Paint, etc)

On the receiving end you can just set up a chain of splitters to filter things out again, though it sounds like you don't really need that - that is, you should probably just load everything into a row of provider chests and let drones do their thing.

[Tydo]

thinking a bit more, I realize that I was thinking in terms on the receiver being a deadend station and only having 1 train servicing it (with no other tasks). My idea hinges on idea that the order that things arrive is not being very important, as long as the whole load gets there.

[Roadkill]

Are you trying to get specific numbers of specific item types to go into a train car?

[astrosha]

Ok .. a little bit of theorycrafting here.

There are FOUR types of train routes :
Many->Many, where more than one loading stations serve more than one unloading station;
Many->One, where more than one loading stations serve exactly one unloading station;
One->Many, where exactly one loading station serves more than one unloading station;
One->One, where exactly one loading station serves exactly one unloading station.

There are TWO types of trains :
Bulk Trains, that carry one (occasionally, add a fluid wagon for a second resource/material) or occasionally more than one type of resource/material in large quantities. Ore trains, Plate trains, Green Circuit trains, etc. Usually multiple trains serve the same route.
Building Trains, that carry a plethora of material types in limited quantities. Usually only one train serves any one specific route.

Building Trains work well enough (IMO, best) with Enable/Disable Train Stop conditions. Bulk Trains should never use those, and should instead use the Train Stop Limits.

Train Stop Limits VS Enable/Disable :
Both have their uses. Train Stop Limits were intended to replace Enable/Disable, by simply being better, but they both have their place in a well running Factory.

Train Stop Limits prevent more than a specified number of trains coming to or sitting at this train stop. Trains prevented from coming sit at their location until there is room. If three trains are waiting and the limit is increased by one, then one of those three will head over and the other two will stay put.

Enable/Disable does just that, it turns the station itself on or off based on circuit network conditions. Trains with a given stop on their route, with all stations of that name disabled, will SKIP that listing on their route and move on to the next one. This can be advantageous or a problem, depending on your design.

In either case, trains will head to the "closest" train stop called for by name in their routing. This can be avoided by setting the Train Stop Limit fairly low for Bulk Trains, as this would force extras to go further afield to find an available stop.

Ok, with that out of the way .. here's how I tend to do things (not getting into liquids; I do things differently for fluid trains such as Crude Oil deliveries)..

Bulk Trains :

These serve Many->Many, and can be used for Many->One, One->Many, or even One->One, though they are a bit of overkill if you are only doing that.

Loading Station : I use 6 Steel Chests per Cargo Wagon. I wire up all the chests together, and send that to an Arithmetic Combinator. I manually determine the maximum load of the overall train (e.g. 2000 ore/cargo wagon, 4 cargo wagons, total 8000 ore for the train) and set the Arithmetic Combinator accordingly : each / (maximum amount of the train), output signal L. Wire the output of the Arithmetic Combinator to the Train Stop, and set the Train Stop Limit dynamically, by the signal L. In this case, L has a maximum value of 7. Additional Decider and Arithmetic combinators can be wired in parallel between the initial Arithmetic Combinator and the Train Stop to hard cap L to something lower if desired. This allows trains to come based on the amount of material in the chests.

Unloading Station : for the same train as the above Loading Station, I again use 6 Steel Chests. The setup is almost identical to the Loading Station. Wire a constant Combinator to the Steel Chests, set to the negative of the maximum amount that the chests can hold (4 cargo wagons, 6 chests per, 2400 ore per chest, yields 57600 ore; Constant Combinator set to -57600). Change the Arithmetic Combinator to divide by the negative of the train load (-8000 in this case). Everything else is the same. This allows for trains to come deliver to the chests based on the space available within those chests.

Building Trains :

These can be One->One, One->Many or even Many->One (sort of a "reverse building" train, hauling junk away from the outposts to the central factory for repurposing). The one thing these do not do well is Many->Many. ONE of the stations (the "One" side of One->Many or Many->One) MUST ALWAYS be ENABLED. The Many side can either be Disabled, or dynamically have the Train Stop Limit set to 0. If carrying multiple items for different named stations, disabling works better. If there are only two stations on the train's schedule, then train stop limits work just as well, though are slightly more complicated than enable/disable.

One->Many : Load at the One, Unload at the Many. As stated in my previous post in this thread, I prefer the Loading Station to have up to 12 chests per Wagon, each one with one specific item (if carrying a large amount of something, say Landfill, can divide that load among multiple Chests). If I need a 13th item, then I get a second Cargo Wagon. Station is ALWAYS ON so the train ALWAYS comes back after unloading, to get a full load before heading back out. Filter the Cargo Wagon so it only carries what you want, and use the Red X to lock off unfiltered slots.

At the Unloading Station, use Stack Filter Inserters pre-set to the items being pulled (this one pulls Inserters, that one pulls Landfill, this other one pulls Concrete, etc.). Use the Red X in the chests to limit how much gets unloaded (if you only want 400 Red Ammo, then only have 2 slots in the Red Ammo chest unlocked, use the Red X to lock the rest). Wire all the chests to a Constant Combinator. Set the Constant Combinator to the negative amount of each item you want buffered. Example : you want to have 100 Repair Packs on hand, and want the train to come resupply when you fall down under 10; you'd set the Constant Combinator to -10. Do this for all the items being delivered. Wire the chests to the train Stop, setting it to enable when Anything < 0. This monitors the contents of the chests, and only enables the station (calls the train) when something falls low. By slot locking the chests, you keep other, less-used items from being overstocked (no need to load 1000 Laser Turrets when you are repairing them all and only want to have 50 on hand to replace losses).

Many->One : I use this for my Garbage Train. I cannot really find any other use for this particular setup.
Loading Stations: Storage Chests (the only ones in those bot networks) are used instead of Providers or Requestors. Wire the Storage Chests together to the Train Stop, Enable when Anything > 0. This summons the train to haul away the trash.

Unloading station : ALWAYS ON!!!! I use Active Providers to ensure the trash gets bot sorted and repurposed (pipes, miners, etc. get sent to storage or to the building train's requestors, for use elsewhere; wood gets burned, stone gets sent to smelting into stone bricks and coal gets sent to be made into plastic).

I hope that all of this helps!