Factorio Forums

This is a prototype design I have been toying with to achieve something we do IRL all the time.

Imagine that we have our main base area and out somewhere in the distance we have an outpost and that these two things are connected by single track with bi-directionally running trains.

In factorio land, we handle that with a chain signal and only one train is allowed on that stretch of track at a time.

IRL, there really isn't any sort of problem with sending several trains down that line at the same time so long as they're all running in the same direction.

So, I built some circuit stuff to emulate this behavior.


The overall layout. Imagine the southern facility is the main base. The rest are some sort of nebulous outposts that do something.
Demonstration of a flat crossing. Trains on one line are currently running from outpost B to the east and then south. Trains on the other line are currently running from the south to the north. A closer look at the crossing above. Demonstration of a merge/split. Both visible trains are heading south.

Anyways, I'm pretty curious to know people's thoughts on this. As it stands, I started this for fun and it's mostly working but a little rough and there's at least one bug still in the system. In factorio terms, I don't think this is actually practical so I will might stop working on it but lemme know what you think. I'm a little on the fence. It was fun to build and watch.



Demo Blueprint attached below.

Instructions.
Get the creative mod if you don't have it.
Start a new game in sandbox mode with all the terrain and biters and stuff disabled and then enable cheats.
Plonk down a super radar 2 to generate the chunks. It may take a minute or two to finish.
Place the blueprint.
Start up the trains.
I suggest you save here.
Reconnect the deliberately broken piece of track by the depot to get them all going.

Known issue - It is possible for trains running on the Outpost C and outpost D line to deadlock due to a logic bug. I think I have an idea how to fix it, but that's a thing for another day maybe.

Edit - it seems that the other lines can very rarely jam too. I'm pretty sure this is caused by the delay induced by the combinators. I have an idea for how to fix it but won't right now. It's just a mostly working prototype.


factorioprints blueprint link

Being inspired by what you created i decided to try and make my own version. I personally hate to connect two places with wires which meant that my version of course had to be wireless. This wireless feature does come at the cost of a complicated train schedule. Another big weakness with this system is that the trains have to stop completely before entering the single lane track. I am not aware of any scenario where this would deadlock given the train schedules are set properly.


Map view of the prototype.


The train schedule required for normal functioning

Here is the blueprint for anyone who need it
(I didn't even bother to check how you did yours design since i am too lazy to understand other peoples code factories)

Edit: It seems that this design can deadlock in more ways than just one. One of the ways that it deadlocks seems to be a fundamental flaw which means that I am scrapping this concept.

Hovedgade wrote: ↑Tue Sep 13, 2022 10:23 pm Being inspired by what you created i decided to try and make my own version.

Hey cool. I look forward to taking a look at it. I have been mulling over a couple of possible solutions that rely on stations too but I decided I want to avoid that for a simple reason - you can't really do that with more generic type train schedules. You know, the flexible 1 to many and many to many types of schedules that you can do with station limits. Still cool though.


I will say that I couldn't resist tinkering and have worked out a much improved version of the circuit logic. It's way more practical to implement than the first prototype and more reliable too.

There is still an issue with it though and I think it's actually being caused by a previously undetected game bug involving rail signals connected to a circuit network. I'm still trying to track it down to be 100% sure though.


In any case, I'll probably post version 2 tomorrow.

First I was: Why do you have a stacker at the exit? You need the stacker at the entry to queue up multiple trains for transit. Then I saw that you use the train counts to block the other way.

Using the train count on the exit stops is a nice trick. But why do you need a stacker there? A single exit stop with unlimited train limit will output the number of trains targeting it. Isn't that enough?

I also have some thoughts for improvements:

1. Add a stacker (with an entry signal on each lane) on the entry point so multiple trains can wait to enter the segment. This also makes it less of an issue that the train has to stop. On a busy line a bunch of trains will sit in the stacker and wouldn't have been able to drive through anyway.
2. Only one exit signal (on each side) with the train limit controlled by a counter. Every time a train passes decrement the counter. This then blocks more trains from going in that direction and allows trains going the other way. Reset the counter once the trains in the other direction are moving. This is to prevent one direction from remaining active all the time.

A problem with this idea is the fork. Trains going down one way of the fork won't block trains on the other way of the fork. Can't do that wireless like this. You would have to add extra train stops at forks to keep track of trains on each segment. Or make all forks dual track with their own entry and exit points.

On a side node: If you keep your exit stacker you don't need any signals at all. Simply set a train limit of 1 at all signals. Trains will only move out of a train stop when the way to the next stop is clear. If you combine this with an entry stacker you have to stagger the signals for entry carefully so trains don't collide on entry. Don't let them leave all at once.

mrvn wrote: ↑Wed Sep 14, 2022 11:07 am First I was: Why do you have a stacker at the exit?

There isn't always a guarantee that all the trains can fit further down the 2 way track and my lazy solution was to make a stacker such that each train had to reserve a parking space. Your ideas of improvement are pretty good so perhaps i will make a improved version in the future but I don't plan to spend much time on this.
(I don't understand the problem regarding the fork but i suspect that my english is lacking.)
While showering today i also thought about a way that my design could deadlock but i believe i already have a solution for such deadlocks.

Hovedgade wrote: ↑Wed Sep 14, 2022 1:54 pm

mrvn wrote: ↑Wed Sep 14, 2022 11:07 am First I was: Why do you have a stacker at the exit?

There isn't always a guarantee that all the trains can fit further down the 2 way track and my lazy solution was to make a stacker such that each train had to reserve a parking space. Your ideas of improvement are pretty good so perhaps i will make a improved version in the future but I don't plan to spend much time on this.
(I don't understand the problem regarding the fork but i suspect that my english is lacking.)
While showering today i also thought about a way that my design could deadlock but i believe i already have a solution for such deadlocks.

With the design you have I believe a train can arrive at each entry station at the same tick. Then both trains will enter the one way and meet in the middle and you are deadlocked. You can't process the train count signal in 0 ticks I think, takes 1 tick for the signal to propagate.

You could make clocks with 4 belts and a fish at both ends. Trains can only leave when the fish is on one belt tile. You have to run the clocks synchronized and out-of-phase but you can use the train count signal to get that started right. Just means the first train has to go one way or you have to manually send it down the line to get the clock started after blueprinting.

mrvn wrote: ↑Wed Sep 14, 2022 11:07 am Only one exit signal (on each side) with the train limit controlled by a counter. Every time a train passes decrement the counter. This then blocks more trains from going in that direction and allows trains going the other way. Reset the counter once the trains in the other direction are moving. This is to prevent one direction from remaining active all the time.

This is basically exactly the way my improved version works.

There's an odd and an even direction.


Train pulls up to signal 1/2 to flag a waiting train in the system.

If mode a/b is not set or is compatible, let the train pass signal 3/4 and add a train to the memory flagged as 5/6 and lock the system into mode a/b.

When the train passes signal 7/8/9/0 remove train from memory.

If the track is clear unset mode a/b.

Loop.


Edit - anyways, it's still a little rough, but I have it working well now. 288 minutes with no deadlocks. Will post the updated version when I have a chance.

You can test unlikely cases:

Load it into the editor mode so you can control time. Place trains and send them to the entry stops to wait there. When they arrive set them to manual and program them with your schedule.

Now stop the time, set both trains to automatic and then single step a few ticks to see if both trains will enter the one-way. You can repeat that at other stops or with other states in your circuit logic.

The ability to single step is great for debugging circuit networks as you can watch each combinator change it's output step by step.

Here's prototype version 2!

The biggest change is that it no longer relies on having every signal on the rail wired up and set correctly like V1 did. That was just too dang bulky. It took the biggest advantage of single rail systems (flexibility) and threw it straight in the trash. Now, only the entrance and exit signals need to be wired up. This system is actually much closer to the original attempt than the released V1 is. The main obstacle to this approach was figuring out the quirks of the way the rail signals operate on the circuit network when you combine the system with actual moving trains.

For fun, I rigged up a comparative test between this circuit logic and the normal chain signal method of signaling this system. The two systems are identical aside from the required signal and circuit changes.
Note that this screenshot was taken with 5 (game) hours of uptime. My system runs 2 to 3 times faster than the normal method of doing this and I know it can go faster. The standard system has periodic backups and is truly bottlenecked by the rail. My system is bottlenecked by a need for more trains.

Edit - I have since pushed these numbers upwards to 3.25, 3.66, 3.58, and 3.5 trains/min for outposts a, b, c, and d respectively simply by adding trains. Simply using something a little more capable than the quick and dirty passing block a threw down to head from hq to outpost A could increase the numbers for stations A and be even more. The trains heading to station A simply need someplace to queue that *isn't* on the main line. Also, watching the junction between outposts c and d is fun when there are more trains. The traffic merge when there's a bunch of them heading home is particularly neat.


Anyways, here's the demo, in save form this time for ease of use.
In order to start things running -
When you load there should be a constant combinator sending signal X near the center of the screen. Turn it off and the trains will start.

Optionally, once things have stabilized and things are running smoothly (3-5 minutes), toggle that same combinator on and back off again to reset the memory of the benchmarking system.

The benchmarking readouts are just above the unloading stations.

mrvn wrote: ↑Wed Sep 14, 2022 3:48 pm You can test unlikely cases:

At least with my test setup, the unlikely cases where less unlikely and where more or less certain.

In prototype v 1 at the top, two trains entering from opposite sides on the same tick or perhaps within a couple of ticks of each other *will* cause deadlocks. I ended up solving that in prototype 2 with a timer based rotating clearance system. Basically - A 60 tick timer was used. Direction A can reserve a path on ticks 0-14 and direction B can reserve a path on ticks 30-44. Roughly anyways, didn't care to get the tick spacing perfect for the prototype. Note that a train doesn't need to be stopped to reserve a path so this system doesn't bring things to a halt or even perceptibly slow things down.

The next big one was caused by the way rail signals and trains work. If the timing of the trains was just perfectly right, the exit signal could go from red on one tick to yellow on the next tick without ever going green. That would cause the counter to be wrong.

The last one that really had me pulling my hair out was with trains wanting to go home from outpost c *and* outpost d. If a train entered the system at outpost d exactly 1 tick after a train entered the system at outpost c, they wouldn't read as seperate trains. Fairly easy to fix but was a bear to find. For a long time I thought it was the previous bug rearing it's ugly head again.

Hovedgade wrote: ↑Wed Sep 14, 2022 1:54 pm (I don't understand the problem regarding the fork but i suspect that my english is lacking.)

I think he's meaning a rail setup like in following trains D.jpg up above.

mrvn wrote: ↑Wed Sep 14, 2022 2:17 pm With the design you have I believe a train can arrive at each entry station at the same tick. Then both trains will enter the one way and meet in the middle and you are deadlocked.

I can confirm that this is the case with your design as posted. Try this -
Delete one section of track in the middle.
Place a train on each end of the setup.
Set the western train to go to west entry.
Set the eastern train to go to east entry.
Wait a moment for them to get to their stations and go into 'no path' mode.
Replace the deleted track.

They will jam. Still cool though. Just gotta work out that bug.

More tinkering. Here's a preview of what I'm working on adding -

It seems to me to be important to consider that sometimes, one or both ends of a bi-directional rail may only have a limited number of blocks for trains. Imagine a crude oil outpost with an entrance, a loading station, and an exit. What would happen if the system sent 4 trains down there? It would jam. In that particular example, you could easily solve that problem by setting the station limit to 2 but what if that's not practical for some reason?


In this example, the limiter is passing siding with room for two trains going in each direction. So what would happen if the systems tried to send 3 trains from both the north and the south? Jam. There's no stations to limit in there either. So I have modified the system to let you place a limit on how many trains are allowed to travel in each direction at the same time. It's working, but I need to do some more stability testing on it to make sure.



I think that's pretty much the last feature the system needs to generally be considered fully functional. Is there anything that needs to be supported that I'm missing? Can't really think of anything I couldn't build with the system as it stands.

Beyond that, it just sorta needs to be looked at with an eye towards cleanup and optimization I think.

This would integrate well with my suggestion to allow each side to force a switch in direction after every N trains.

mrvn wrote: ↑Thu Sep 15, 2022 3:59 pm This would integrate well with my suggestion to allow each side to force a switch in direction after every N trains.

Now implemented. It works in a slightly non-rigid manner. Can't really see a point in forcing alternation if there's no train waiting to come from the other direction. The only use case I can see for that is limiting the number of trains allowed in that area, but that's already handled with the explicit limit settings.

Was tested working with a setting of 0-5 (inclusive). Had to rig up a special test loop to actually stress test this thing as this is really some pretty high volume traffic for a bidirectional rail.

A setting of 1 is pretty much the vanilla chain signal behavior though slightly better in that chain signals aren't particularly guaranteed to alternate trains like this.

A setting of 0 allows no trains to enter. Potentially useful as a shutdown override to let you lock a track out for maintenance.


Can't really think of anything else the system needs, TBH.

Here's prototype v 3 for tinkering and testing.

This one surpassed 12 hours of game time with no deadlocks, malfunctions, or observed deviations from expected behaviors.
Implemented user configurable limits for how many trains the system is allowed to send into an area at one time. You can configure this at the constant combinator values 9 and 0. 9 controls the number of trains the system is allowed to send down the odd direction of travel and 0 controls the number of trains the system is allowed to send down the even direction of travel. Just set to an arbitrary large number for no limit.

Implemented a user configurable option to make the system alternate the direction of travel every N trains when there is traffic queued up. Configurable at the constant combinator by changing the value of S. This system intentionally goes dormant if there is no train queued to come from the opposite direction.




Besides the major feature additions and fixes, the test rail system has some alterations.

The test layouts are running a lot more trains now. 36 of them. I think that's quite a few considering the relatively small scale of these test setups.

Going from HQ to outpost A, I added an area for trains to queue up. This really helped traffic on both layouts. The way I did it is deliberately designed to release two trains onto that stretch of track simultaneously when running my system just to demonstrate the possibility.

A passing siding was added between HQ and outpost A. The passing siding has room for two trains going in each direction and so is a practical demonstration of the user configurable limits. This siding helps traffic, but probably helps the vanilla chain signal layout much more than it helps with my own system.

A new station, outpost E, was added. It's there to simulate the idea of a simple expedient spur with very limited space for trains to demonstrate configurable limits. Under sustained production, the system has identical throughput to the vanilla chain signal method of signalling. My setup will slightly reduce latency in the event it's a station that goes between idle and demand surges. That's about it though.

Between the new stuff and these alterations, there's lots of things going on that I just find to be pretty interesting to watch. The altered hq to a route is cool but my favorite is still the hq to c and d split. I find it noteworthy that the section of track that's shared between outpost C and D is moving a sustained 13 trains per minute. With this setup, that's a throughput of 104,000 plates per minute. I think it can go a bit higher too with some more trains. The conventionally signaled equivalent is moving about 8 trains per minute or about 64,000 plates per minute and I think that's pretty much the limit.

Edit - Just out of curiosity, in a modified test, I clocked that section of rail at a sustained 15 trains/min, which is 120,000 plates per minute. For reference, a hypothetical moduled vanilla 1,000 X 7/min base should draw 75622.388 iron/min. So if you had that setup feeding you iron ore from two patches, you could hit 950 X 7 sci/min. Not saying that's particularly super advisable, just that it's interesting. Even the conventional signal setup could neatly feed a 500 X 7 base. Really, that's a testament to the sheer throughput of rail systems in factorio.


Anyways, here's the demo
Just like last time, simply turn off the x constant combinator to start the trains running.


I still want to add a maintenance lockout mode, which is trivial. Besides that, let me know if there's anything else you think it needs to be able to handle. Things are still a bit messy, but I don't want to do anything about that until I'm definitely done with adding features and bug fixes and the like.

Just a small note here -
I found a small and difficult to spot bug in the logic used to force direction switching when things are queued up. This logic bug will sometimes let more than the configured number of trains through before switching direction under certain specific conditions. Doesn't override the limit on the amount of trains the system is able to send down a side at one time though.

Pretty sure it can't cause a deadlock, but the fix is implemented and will appear in the next version.