Train interruption exceeds train limit

[KFan]

I have interruption

03-11-2025, 10-50-10.png (66.25 KiB) Viewed 741 times

and I have 2 load stations, and 1 unload, all of them have limit of trains equal 1

and now here is question, why 2 trains starts interruption? I need only one at the time, because of two of them start, second of them stay at loading place and wait when i enable unload station again

03-11-2025, 10-53-22.png (62.53 KiB) Viewed 741 times

[KFan]

save file with reproduce

interrupt reproduce.zip

(2.2 MiB) Downloaded 17 times

[Premu]

Hm, you added the loading stations both in the schedule and as interrupt. I asssume that might be the problem. You shouldn't mix these two methods.

You can configure trains completely only using interrupts without any stations in the schedule. The typical setup is four interrupts for loading, unloading, refueling and as backup to drive to a depot in case no other target is available. That works very reliable.

[KFan]

Hm, you added the loading stations both in the schedule and as interrupt. I asssume that might be the problem. You shouldn't mix these two methods.

You can configure trains completely only using interrupts without any stations in the schedule. The typical setup is four interrupts for loading, unloading, refueling and as backup to drive to a depot in case no other target is available. That works very reliable.

No, I didn't add any schedule manually (except depot)

And your solution with different loading and unloading interrupt seems will not work, will be same problem

[Tertius]

It would help if you switch your game language to English for a forum screenshot. I guess you show the train schedule GUI, but I'm unable to read any letters, and the conditions are all incomprehensible for me.

[KFan]

It would help if you switch your game language to English for a forum screenshot. I guess you show the train schedule GUI, but I'm unable to read any letters, and the conditions are all incomprehensible for me.

03-11-2025, 19-00-37.png (133.53 KiB) Viewed 630 times

All stations configured in this way

03-11-2025, 19-01-05.png (155.19 KiB) Viewed 630 times

[robot256]

I see what the problem is. This system will not work if there are more load stations than unload stations.

When the first train departs, it reserves one of the two spots at the load station but does not yet reserve any spots at the unload station. The second train also departs, reserving the second spot at the load station and unaware that the first train is intending to reserve the only unload spot soon.

You can fix this by removing the second load stop or adding a second unload stop. You can also use circuits to only enable as many load stops as there are enabled unload stops.

[KFan]

I see what the problem is. This system will not work if there are more load stations than unload stations.

When the first train departs, it reserves one of the two spots at the load station but does not yet reserve any spots at the unload station. The second train also departs, reserving the second spot at the load station and unaware that the first train is intending to reserve the only unload spot soon.

You can fix this by removing the second load stop or adding a second unload stop. You can also use circuits to only enable as many load stops as there are enabled unload stops.

I guess that it is not easy to choose which of two stations should be enabled and it makes me to enumerate all stations, this is kind of problem

Is there any way to force them reserve all spots in chain?

Your description seems that even if i have 2 load and 2 unload, and one unload full and disabled - it will be bugged again

[KFan]

Looks like I should not make many depot, just use load stations as depot and make train for each resource (as many as I need), and in this case my interruption will have only unload condition

[robot256]

Yes, the only generic system that seems to be officially supported is to have one interrupt dispatching empty trains from the depot to a loading station, and a second interrupt dispatching loaded trains to the unloading station of the resource it contains.

Thinking about it again, the solution I suggested of adding another unloading station does not work in the general case. Both trains will still depart for both loading stops and then queue wait the single unloading station. You would need more complicated circuits to limit which trains leave the depot and remember which unloading stations have trains destined for them.

[robot256]

I think it will make much more sense if you use the Priority setting to increase the priority of the loading stops based on how few trains are already waiting loaded with that resource. That way you don't need one train for every loading stop necessarily, and you can ensure that the next empty train always loads a resource without any currently loaded trains.

[KFan]

Yes, the only generic system that seems to be officially supported is to have one interrupt dispatching empty trains from the depot to a loading station, and a second interrupt dispatching loaded trains to the unloading station of the resource it contains.

Thinking about it again, the solution I suggested of adding another unloading station does not work in the general case. Both trains will still depart for both loading stops and then queue wait the single unloading station. You would need more complicated circuits to limit which trains leave the depot and remember which unloading stations have trains destined for them.

But there is no sense of interrupt then

[robot256]

Yes, the only generic system that seems to be officially supported is to have one interrupt dispatching empty trains from the depot to a loading station, and a second interrupt dispatching loaded trains to the unloading station of the resource it contains.

Thinking about it again, the solution I suggested of adding another unloading station does not work in the general case. Both trains will still depart for both loading stops and then queue wait the single unloading station. You would need more complicated circuits to limit which trains leave the depot and remember which unloading stations have trains destined for them.

But there is no sense of interrupt then

The interrupt means that you don't need a separate train schedule for each resource, and don't need to manually ensure each resource has the correct number of trains. And using priorities, you can expand your train fleet and number of stops at different rates without causing issues. But I agree the use of interrupts is more limited than I'd like

[KFan]

03-12-2025, 09-28-46.png (60.39 KiB) Viewed 456 times

I am trying different way, like make train for each load station, and it work....

But the problem is I have to create new train group for each resource and manually add interruption into them, because initial station is same for each group

[robot256]

Everything gets simpler if you decide to allow loaded trains to wait at the loading stop until needed. Then you can use a generic interrupt with just one stop (unload [cargo item]). And the loading stations are the depots they return to.

[Tertius]

Well, the cycle starts with an empty train. Its purpose is to carry material, so put as static schedule entry the loading station. Call all loading stations with the same train layout the same name, so the train will pick some open loading station, no matter the material.
As soon as the train is loaded and wants to leave the station, it consults the interrupts,. So it's useful to match the material just loaded with an unloading station for that material. For this, the green cargo item wildcard is made. It matches the cargo in the train and substitutes the wildcard with the actual cargo. You can construct destination station names with that - mention the cargo in the station name, and in the interrupt enter the wildcard instead of the cargo item. So if the interrupt triggers, it constructs the destination station name with the proper material name, and the train will drive there.
In case all unloading stations are full, the train just stays at the loading station. Since there are no unloading stations open, there is not more demand, so it's ok if there isn't another train starting to be loaded.

At the unloading station, the train gets empty eventually. No interrupt, but the static schedule entry directs the train again to a loading station. Now, if all loading stations are full, it isn't wise to let the empty wagon stay at the unloading station. So add an interrupt for a depot. Condition "no path or destination full". This will trigger if all loading stations are full and direct the train to the depot station mentioned in the interrupt. Here the train can wait, and if some loading station opens up, the static schedule entry is followed finally.

This is what was envisioned by the devs in fff-389 and fff-395:
https://factorio.com/blog/post/fff-389
https://factorio.com/blog/post/fff-395

[torne]

Well, the cycle starts with an empty train. Its purpose is to carry material, so put as static schedule entry the loading station. Call all loading stations with the same train layout the same name, so the train will pick some open loading station, no matter the material.

...

This is what was envisioned by the devs in fff-389 and fff-395:
https://factorio.com/blog/post/fff-389
https://factorio.com/blog/post/fff-395

Many people have since discovered the issue with this approach: if you have trains just go and load whatever material is available and then wait for somewhere to unload it, you can get into a state where all the trains are full of some material that isn't in demand right now and there are no empty trains remaining to pick up a different material that is actually needed. Whether this will actually happen in practice depends how many loading/unloading stops you have for different things, what their train limits are, and how many trains you have in total, but guaranteeing that it will *never* happen (while still using this basic approach) is likely to mean adding a lot more trains than necessary, and it seems like in many cases you'll end up with just as many trains moving around/parked as if you had just dedicated trains for each different resource.

There are lots of different things people have tried to avoid this problem, but many of them create new problems - e.g. one next idea is to use circuit controls via a global wire network or radars to disable loading stops if the resource they provide is not currently needed, but by itself this doesn't do anything to prevent *many* trains from all going to get that resource at once as soon as it does become needed again, which might be more than necessary, ending up with less overall throughput than desired or just getting stuck entirely in the same way.

There are many threads on the forum going through (and arguing about) the advantages and disadvantages of different more complex approaches, and personally I've not found any of them to be both simple and reliable enough to be something I'd want to use in "vanilla" space age instead of the simple approach of just having separate trains for most resources and only using interrupts for refueling or depot parking, but that's just my personal preference.

It seems like the original poster here and several of the other people replying are talking about a more complex approach, though not necessarily the same one

[Tertius]

Many people have since discovered the issue with this approach: if you have trains just go and load whatever material is available and then wait for somewhere to unload it, you can get into a state where all the trains are full of some material that isn't in demand right now

Yes, I encountered this issue and I solved it by carefully choosing train limits, amount of trains and depot space for empty trains. Really, I solved it for me. Not a single shortage of material, and 100% reliable item delivery without any manual intervention ever.

I use a static train limit of 2 with all the loading and unloading stations and I have a waiting area for 1 train in front of each station. They can be shared, if there are multiple stations next to each other. At my base, I have 6 unloading stations directly next to each other, they share a common waiting area with 6 lanes.

Additionally, I have a depot as big as there are slots for unloading stations, so in case every loading station is full, there is guaranteed to be a space for every train in the unloading stations getting empty. Every depot lane has its own depot station with train limit 1, all the same name.
Finally, I have as many trains as slots in all the stations (except the depot stations). This means if every unloading station has a train either at the station or in the waiting area, there are still enough trains to occupy every single loading station, so there isn't any train starvation.

To help with train distribution, I have a simple circuit in every loading station that sets station priority to 1 if there are 0 trains targeting this station and keeps it at 0 if there is 1+ train reserving the station. This way every station gets 1 train first, no matter the material, and only if every station has 1 train the 2nd train gets assigned.

Honestly, works perfect. There is nothing to improve in my opinion. Train latency is at minimum due to the train limit of 2 and the waiting area. The next train just moves in if the previous one gets empty. At the loading stations, this interval is so short I don't even use buffer chests.

The only thing you need to make sure is that you're producing more than you're consuming. If you don't do that, the unloading stations more far away will starve.

Main schedule entry is loading station. Interrupts are unloading, depot and refuel. No circuits except the small one to handle loading station priority.

No circuit micromanagement for assigning trains to stations. It just works without. I read all the threads trying to build some train management circuits. In my opinion, they're all unnecessary and so complex they have so many edge cases they are doomed to fail in the long run.