Noob attempts train deliveries

This board is to show, discuss and archive useful combinator- and logic-creations.
Smart triggering, counters and sensors, useful circuitry, switching as an art :), computers.
Please provide if possible always a blueprint of your creation.
kball
Manual Inserter
Manual Inserter
Posts: 1
Joined: Tue May 29, 2018 10:29 pm
Contact:

Noob attempts train deliveries

Post by kball »

Edit: Just realized this should probably go in the Railway Setups forum. Mod please feel free to move it.

Hey guys!

My first time posting. I've been having a lot of fun with Factorio recently (originally played it about a year ago) and wanted to try my hand at some combinator tools. Here I built what I hope is a functional train delivery system. I'm sure this has been done many times before and much better than I have here, but I wanted to give it a shot myself as a learning experience. Hoping some of you might have feedback!

So the basic premise is, from any station, be able to request any items from a main base and have them delivered by train. The discrete steps would be:

- Submit a request
- Request sent to base
- Logistics network fills request
- Train is loaded (happens simultaneously to above)
- Train delivers filled request to destination

Below you can see the whole of it with the base station on the left and the requesting station on the right.

Image

The requesting station is pretty simple: You enter the request into the constant combinator at right. The next decider and arithmetic to the left are a pulse generator I learned from that indispensable tutorial I found on here. They send a pulse of R=1 (filtered to R=0 by the second constant combinator which outputs R=-1) to the final decider which (on R=0) takes the request from the input constant combinator and pulses it to the Big Electric Pole.
expand
In the picture of the supplying station below I've boxed out the main parts of the system and I'll cover each in detail

Blue - controls when the train is allowed to dispatch
Green - A system that controls exactly when the inserters and logistics requests are activated. Necessary, as far as I could tell, to prevent the logistics system from overfilling the request

Everything else handles the filling of the actual request
expand
First to the everything else.

The system first stores the request from the outside network. It can be reset on a signal of green != 0. This decider will act as an accumulator of items that still need to be provided by the logistics system. It's output is destined for two places - the Requester Chest to set its filters and the Filter Inserter which will remove excess items delivered by logistics bots always carrying their max load.
expand
An arithmetic combinator negates the values of the accumulator before they reach the filter inserter. So if any of the values of the accumulator go negative, due to being over supplied, this combinator will supply those values as positives to be set as filters on the filter inserter, and then removed from the train. The filter inserter's stack size is set to 1.

(Ignore the deciders intervening before the Requester Chest and Inserters for now.)
expand
Finally, the two arithmetic combinators at top read the hand contents of the inserters and send them back to the accumulator. The Stack Inserter's combinator negates its value, removing them from the total. The Filter Inserter's combinator simply passes it through, signaling that excess items have been removed. It is really only there to prevent the red wire circuit signals from being read back by the Filter Inserter.

(I was using the Steel Chest for testing. It should be an Active Provider chest to send the excess items back to the logistics network)
expand
That's it for the meat of the system. The train dispatch serves 3 functions:

- hold the train if it's empty.
- dispatch the train if the request has been filled
- reset the accumulator when the train leaves.

Because I need to know when the train leaves, I need to read the train ID. But I also need to know when the train is empty, so I use an arithmetic combinator to negate the train ID. Using that and the train contents, the left decider outputs Red=1 if the train is empty. The right decider outputs Green=1 if the accumulator has all zeros.
expand
And to tie it all together, the train's wait condition is as follows:
expand
Using those rules, the train will pull away after 10 seconds, even if the accumulator still has values, presumably because the logistics network does not have the required items.
The second set of rules also waits for one second, because the accumulator will actually go to zero before the Stack Inserter finishes loading the last item.

When the train leaves, a pulse generator testing for T=0 sends Green=1 to the accumulator to reset it.
expand
Now finally for the funky bit. And here's where my understanding starts to get fuzzy. My biggest problem in trying to build this was that I could not update the filters on the Requester Chest in response to the Inserter activity in time for the numbers to reflect what should actually be requested. The logistics network would pick up the request immediately, and it would take me a surprisingly high number of ticks (3? 4??) to get it updated. A tick for the inserter to update? A tick for the combinator to negate it, a tick to get it in the accumulator, and a tick to get back out to the chest?? And even ONE tick was too much because the logistics network would see the discrepancy between the request and contents IMMEDIATELY and the little bots would go nuts sending me items. So trying to set the filters to none after any signal from the inserter still took too long. 2 ticks I guess. Perhaps a smarter person could wire this up so it just works, but here's what I came up with:

The remaining part of the system is just a counter that goes from 1 to 5, and each of the deciders it's connected to decide when a particular action should be allowed to happen

Tick 1 - set the Requester Chest filters (immediately unset on next tick)
Tick 2 - enable the Stack Inserter (immediately disabled on next tick)
Tick 3 - set the Filter Inserter filters (immediately unset on next tick)
Tick 4 and 5 - do nothing.

And here's the rub - I'm not sure why any of that works, but it does!
expand
Welp that's it! Thanks for watching. There's still one piece missing. The receiving station should be disabled by default and only enabled when a request is pending so that the train knows where to go. I'll leave that for another day.

If anyone has any tips on how to do any of these parts better or simpler, let me know!

Oh, and a blueprint that hopefully catches everything.

Post Reply

Return to “Combinator Creations”