Train - control by interuption

[Shins]

Hello,

I have small problem with correct parametrization interruption.

My goal is to use only 1 group of trains to dynamiclly choose where trains should go. I wish pack for example 100 trains and when there is need to transport some Iron Ore from one place to another then one of trains will go to make this job. What I would like to do is that 1 train could go to any resources are necessary. My idea is also to control how many trais transport iron, how many transport copper and so on.

So I have idea, that every train station send signal to network. If station need a trains then it send -X (depends of max. parametrization what I will set for this station and how many trains are going to this station, for example if station want have 4 trains but going there 1 then it will -3). So when I will see iron ore signal < 0 then I would like to adjust train to go to the station what supply iron. And iron station will send signal with + value, then when 3 station need 1 train and 3 station send 1 train then its summary 0 and no more trains shuld be adjust to pick the ore. And here I have problem - when I have 2 waiting stations and in network appear signal with - value, then automaticlly all trains are adjusted to start. I am looking for solution how to prevent that situation.

[fatallight]

Is there any reason you've decided to do something like this instead of adjusting the train limits at the stations?

[Shins]

Yes. I have really unbalancew production. If I set only limit on the train station then its easy to fill all trains with only 1 resources. For now I have separate group for every resource, but its quite uncomfortable to use it.

But I found that if I set value like in constant its work bad, but when train station send this signal then it works fine.

12-19-2024, 15-52-13.png (32.63 KiB) Viewed 417 times

[fatallight]

I'm not sure I understand your situation enough to give you an exact answer. But setting the train limit and priority from circuits can take you pretty far. In my "bag of trains" solution, all pickup stations have the same name and all balancing is done by setting train limits, priority, and disabling stations from circuits. You could set them based on demand, production, how long it's been since the station has seen a train, etc.

One other trick I've picked up is that stations with waiting trains report the ID of that train on the red radar circuit network. Then stations that need a train post the ID of the train they want onto the green radar network. The waiting stations detect this and send a signal to the train to tell them where to go. I use this to tell full trains where to go to drop off their cargo but I suppose it could also be used to direct empty trains as well.

[mergele]

Filling all trains with only 1 type of resource only happens if you take the trains out of the loading stations while there is no open unloading station. If you just let them sit there its a nonissue.

[Shins]

Yes, thats true. If you let trains stay at station they will not fill all trains with one material. But I need solution where I can fill some trains in forward and let full trains waiting closer to possible destinations to reduce time for transport between sending demand and arriving train. Some areas in my factory are able make trains empty so fast, that I need new trains going closer as soon as possible.

[Tesse11ation]

From a high level, there's several things you can do with the new interrupt system that make trains so much more powerful than in 1.1.

Personally, the way I do it is having universal trains with the following features:
* All destinations are interrupts, and all trains are part of a universal group of either cargo wagon trains, or fluid wagon trains. There are no permanent or fixed schedules.
* The majority of the control logic is handled by provider stations, i.e. mining outposts. This includes setting the train limit dynamically based on available loads, setting the priority based on what resources are needed, and subtracting the current train count from the priority. This also includes tweaks like balancing each cargo bay and permanently disabling the station when it is out of resources.
* Provider stations all have the same name within their train group, such that any available train will go there.
* Requester stations set the priority of provider stations via radar. This ensures that if there is a high demand for iron ore, all of the iron ore providers will be serviced first.
* Empty trains are sent to a buffer area (read: train yard) to clear the requester station for more incoming full trains ready to unload.
* All trains will read their own cargo and path to the correct requester station using the wildcard signal to match the resource icon in the requester station's name. This removes having to use train IDs to track which train is carrying what load.
* If full, trains will NOT go to a buffer (yard) station and will instead sleep at the provider station. This is to prevent the yard from being filled up by trains carrying the same resource and all competing to service the same requester station, while disregarding all other resource types (I learned the hard way that I had to do this to make it work).

I'm working on finalizing my train blueprints, then I can share them with you guys. But until then, it sounds like what you want is a stacker on your requester stations so that full trains can sit in waiting to deliver their cargo. Just make sure if you do a stacker to limit the station to however large the stacker is, including the train that would be unloading.

[fatallight]

* All trains will read their own cargo and path to the correct requester station using the wildcard signal to match the resource icon in the requester station's name. This removes having to use train IDs to track which train is carrying what load.

This is good and simple for your high-throughput items. The reason I mentioned the train IDs is because I have a few stations that handle multiple item types, like my mall and artillery outposts. I also designed it pre-Vulcanus so I didn't always have space for all the requestor stations because of cliffs so I combined some lower rate ones. The train ID system lets trains go to requestor outposts with different names. But yeah it's not entirely necessary.

[Tertius]

To avoid the latency between a full train leaving the provider station (ore mine) and arriving at the requester station (base), I set the train limit of my base stations to 2 instead of 1 and build a waiting area in front of the requester station, so there can always be 2 trains: one currently being unloaded and another one either on the way to the station or in the waiting area ready to move in, as soon as the previous train is empty.

I try to build all the base requester stations in a row next to each other, so they can share a single big waiting area with multiple lanes. This needs the minimum amount of space is easier to plan from a layout perspective.

I also design all the mining outposts with a waiting area, so these stations also have a train limit of 2. One train is always being loaded and another one either waiting or on the way.

All limits are static, and the idea is to fill every station with a train either being loaded or being unloaded. So in case all provider station train slots are occupied, a depot for empty trains is required in addition, so trains becoming empty in a requester station can move into the depot and doesn't clog the station.

I added a circuit-supported small optimization for train distribution. Since every provider station has 2 slots, trains will fill both slots for the nearest stations first, so it can happen stations far away don't get trains and their ore isn't being used. So I added a circuit that manipulates the station priority. At the provder station, I read the currently reserved train slots from the station, and if it is 0 (no trains targeting this station), the priority is raised to 51. Otherwise it stays at 50. This way the 1st slot of every provider station is reserved first and a train going there, and only after all stations have at least 1 train, the 2nd slot will be available. This is easier than to dynamically raise or lower train limits according to buffer chest fill state - it's a trivial solution instead that just looks at how many trains are currently dealing with the station.

All provider stations are named the same, and all requester stations have the material in the name. All trains are the same. One static schedule entry moves the train to the provider station name. Driving to the various requester stations is done via interrupt.

All this together works very well for me. Perfect train distribution. No requester station will ever starve, as long as the mines are able to produce at least as much as there is consumed.

Example base station layout:

Screenshot 2024-11-01 200903.png (159.57 KiB) Viewed 264 times

About cliffs: I planned ahead how many stations I might need and placed this into an area big enough without cliffs. It was close, but I found an appropriate position.

[Shins]

From a high level, there's several things you can do with the new interrupt system that make trains so much more powerful than in 1.1.

Personally, the way I do it is having universal trains with the following features:
* All destinations are interrupts, and all trains are part of a universal group of either cargo wagon trains, or fluid wagon trains. There are no permanent or fixed schedules.
* The majority of the control logic is handled by provider stations, i.e. mining outposts. This includes setting the train limit dynamically based on available loads, setting the priority based on what resources are needed, and subtracting the current train count from the priority. This also includes tweaks like balancing each cargo bay and permanently disabling the station when it is out of resources.
* Provider stations all have the same name within their train group, such that any available train will go there.
* Requester stations set the priority of provider stations via radar. This ensures that if there is a high demand for iron ore, all of the iron ore providers will be serviced first.
* Empty trains are sent to a buffer area (read: train yard) to clear the requester station for more incoming full trains ready to unload.
* All trains will read their own cargo and path to the correct requester station using the wildcard signal to match the resource icon in the requester station's name. This removes having to use train IDs to track which train is carrying what load.
* If full, trains will NOT go to a buffer (yard) station and will instead sleep at the provider station. This is to prevent the yard from being filled up by trains carrying the same resource and all competing to service the same requester station, while disregarding all other resource types (I learned the hard way that I had to do this to make it work).

I'm working on finalizing my train blueprints, then I can share them with you guys. But until then, it sounds like what you want is a stacker on your requester stations so that full trains can sit in waiting to deliver their cargo. Just make sure if you do a stacker to limit the station to however large the stacker is, including the train that would be unloading.

I know, I see the power of interruption. And was trying use them by my own, because its much easier to have 1 group of trains than 20 different.

My design is a litte different, because I do not want to fill all stations with train. For sure this has a sens, maybe I will modify my conditions. For now I set extra trains manually - I mean my Requesting station request with X quantity, but ordering is steering by network system. And to request more trains than Requesting station need - so to have a buffer - its just enough sent -Y valu to the Network and then I have extra trains in loading station.

For now for sure have to work about prioritazing stations, to send trains to the most valuable stations not to random ones, but this is next step when everything will be driving and I will have a possibility to test layouts.