How to tell if a train is in a station but not "stopped"?

[yawmawn]

I'm trying to set up a farm system on Gleba where the agriculture towers harvest if the total capacity of the trains incoming or already at the station is greater than the amount of fruit already stored at the train stop.

E.g., 2 trains on the way, total capacity = 16,000. Chests contents = 4,000. Turn on the agriculture tower control signal because we need (12,000) more fruit.

It's a simple matter of multiplying 8,000 by the train station signal C.

I thought it would be easy to also subtract the partially full train's contents from the total demand using the train station's contents signal.

E.g., only one train on the way, current contents = 4,000 and chest contents = 4,000. Turn off the agriculture tower control signal because we have enough fruit.

However, the train's contents stop being read the moment it even attempts to leave.

In order to make this work, I need to somehow generate a Yumako=8,000 signal if the train is leaving OR attempting to leave BUT NOT just arriving.

I find the train station signal C to be a bit inconsistent:

• Train entering the station but not stopped yet: C=1, "Trains On The Way = 1, T=0"
• Train stopped at the station: C=1, "Trains on the Way = 1, T≠0"
• Train attempting to leave the station but unable to move, destination full: C=1, "Trains on the Way = 1, T=0"
• Train leaving the station but back end of the train still occupying it, C=1, "Trains On The Way = 0, T=0"

There's essentially no way I can see to distinguish between an arriving train, a leaving train, and a train attempting to leave. The best I've managed is with a pair of train signals, but it still isn't perfect, and it already involves a lot of cumbersome boolean operations with T, C, Yellow, Red, etc.

I was wondering if there's something I'm missing, or if there's an explanation I'm overlooking for why the train system is set up this way, with "On The Way" not meaning literally "On The Way" and the mismatch between the C signal and the "On The Way" indicator?

Thanks in advance!

---

Full disclosure, I know this is overly fancy and I'm 95% certain it's overdesigned anyway. It has the glaring flaw that fruit in the agriculture tower's output buffer isn't being counted (yet - I might still try to implement this as well), but I was hoping to see it in action at one of my farms before confirming it's not worth the complexity.

[Tertius]

There's essentially no way I can see to distinguish between an arriving train, a leaving train, and a train attempting to leave.

Yes, that's the essence of what's (not) possible with train station circuits. You cannot directly distinguish between an (empty) train on the way to the station and a (full) train currently in the process of leaving the station but still on the stations' premises. When I realized this some time ago, I let go the idea to anticipate arriving trains to prepare and pre-fill station buffers in advance.

That was for ore, but for fruit it's a desirable approach to only harvest if there is actually a train to pick it up.

I don't transport fruit with trains, so I don't have a station example, but if I design one, I would design the farm layout in a way harvesting is so fast it's not necessary to build a buffer in advance. How fast is your harvesting currently? Is harvesting faster than moving items from the buffer chests to the train? The goal is reached if harvesting is as fast as moving items from chest to train. In this case no long term buffer is needed.

For maximum throughput it depends on your technology and your personal requirement. You're on Gleba, so you have stack inserters. But do you also have quality inserters? How many chests per wagon do your station has? 4, 6, or even 12 (the maximum)? If you max everything including quality stack inserters, it's probably not possible to harvest as fast as the fastest buffer-to-wagon setup, but may be you're already satisfied if the whole harvesting+loading process is about 10-20 seconds.

If you use robots for carrying harvested fruits, you're able to get very high throughput. Faster than belts, if the distance from every agriculture tower to the destination chests is short enough the robots don't have to take a break for recharge.

In my farm setup, I have farm sectors with 4x4=16 agricultural towers (with artificial/overgrowth soil to get best density), the towers output into an active provider chest, and there is 1 central buffer chest that requests 2400 fruit. Whenever the chest is empty, harvesting is activated, for a minimum of 10 seconds, so the towers are able to plant new seeds. If the time is shorter, the amount of harvested fruits can be better controlled, but but almost no new seeds planted so the farm will run empty. In this 10 seconds there are about 2000-2500 fruits being harvested.

If you have 4 wagons, so your train has a capacity of 8000 fruits, you need perhaps 2 or 3 of these 4x4 sectors and harvest for 15-20 seconds. Perhaps one to the left and one to the right side of the rail, so they have minimum distance to the station. Robots carry 4 items, so you need 8000/4=2000 logistic robots to use every robot once during a harvest. This needs enough roboports for recharge. I have 4 roboports within one sector and some more outside. How many you need depends on your long term throughput. If you continuously harvest without break, you need more of course.
It's crucial to configure the roboports within the sectors to request their share of robots to have the robots already near the towers when the harvest begins, so it's faster and they don't spend their energy prematurely.

In the end, the only circuit you need is to check if there is a not full train at the station (train id <> 0), and activate harvesting just if a train is there, and may be stop harvesting shortly before the train is full, so not too many fruits get buffered and start spoiling. The agricultural towers output their fruits into an active provider chest and you request the fruits directly into requester chests at the station that feed the wagons.

There are quite some options to improve bot throughput. For a small space area, no belt setup can beat a well optimized bot setup in terms of throughput. I cannot explain everything in this post, it's an iterative thing to optimize with an actual build on a map.

If you complain that 20 seconds for train loading is too long, keep in mind that if you pre-load buffer chests, the fruits will stay in these chests probably for a longer time and spoil more than with my just-in-time approach, so they're not as fresh when they arrive as with the just-in-time approach.

That's my farm layout. If I wanted to use trains for fruit transport, I would place the station on the left where the fruit is funneled onto the belt.

08-17-2025, 11-49-30.png (3.42 MiB) Viewed 71 times

[yawmawn]

Yes, that's the essence of what's (not) possible with train station circuits. You cannot directly distinguish between an (empty) train on the way to the station and a (full) train currently in the process of leaving the station but still on the stations' premises. When I realized this some time ago, I let go the idea to anticipate arriving trains to prepare and pre-fill station buffers in advance.

Thanks for the detailed reply and thanks for confirming my suspicion! I won't reply individually to each of your ideas; I think most of them are good and I've already done many of them.


I'm planning to simplify the logic greatly and hope that any over-buffered fruit is picked up very soon by the next train anyway. Here's roughly the scale of my farm / train stations. The exact size is a bit dependent on the irregular geometry of the usable ground.

08-17-2025, 08-38-08.png (135.3 KiB) Viewed 52 times

[Tertius]

By the way, using C as indicator how many trains are about to visit the station is unreliable. Depending on your train network, it's possible a train first reserves the station but is later freeing its slot while being on the tracks and assigning itself to some other station. In this case any pre-filled buffer for that train is starting to spoil.

Using the bot network to deliver fruit is not exact anyway. Items currently being carried by bots are not visible anywhere. They don't exist while they are being carried. You could count harvested fruit by connecting all the inserters extracting the fruit and reading their hands, then reduce the counter if they're being loaded onto train. But that's fragile, because if fruit is spoiling or getting lost, it's vanishing and not being subtracted from the counter.

I see you have a long waiting area in front of your fruit loading station. You can activate harvesting if the 1st signal of that waiting area turns red to indicate a train is about to arrive. You gain 2-3 seconds. It's not known how much is needed and when to stop, but the start can be sooner.

Putting everything together, I don't think it's a good idea to anticipate trains and pre-filling any buffer. I would really concentrate on speeding up harvesting and filling the current train from the current harvest as soon as it arrives as much as possible. And to fine tune this to keep over-harvesting as little as possible.

But accounting for every single fruit will take too much circuits with all their edge cases and simply too much time, since the last fruits to arrive will take the most time. With using bots, it's probably the Pareto principle. First, you get 80% of the cargo in 20% of the time, then the rest of 20% will be slower and arrive in 80% of the time. If you manage to harvest enough so the first 80% is filling the train, and the 20% is the over-harvest that ends up afterwards in the buffer chests waiting for the next train, it's probably the fastest you can get. Perhaps add a heating tower to burn these, if there are currently 0 trains reserving the station.