So I think we are having the same issues as Puppy in his bug report, or at least similar. We've been randomly getting trains going to stations with extra items in them, and just blaming it on each other misconfiguring a train stop somewhere. When we updated all our mods today we threw on Train Log to see if we could trace it. The image link below shows what train log is telling us.

Picks up water on Nauvis, goes to Elevator (UP), drops of 0. The next line is it stopping in a depot in ORBIT 18s later. The Train ID changes between Nauvis and Orbit, I'm guessing because of the Elevator creating/destroying trains across layers?

We do have each LTN depot train limit set to 1. And we have plenty of Depots available. Roughly 100 trains across the 2 surfaces, with 144 on each surface. Most of our stations requesters/providers are set to a single train going to them.

We are using modded trains (EM Suspension Train 2) from 248k. 864km/h speed limit, no fuel.

We are thinking of enabling the "Clearance" station, to see if that fixes it. Otherwise any suggestions to try?

596 stations Nauvis
285 stations Orbit

Various other planets and such. Only got an elevator on Nauvis at this point.

LTN settings (still at default)
Update Frequency(ticks): 2
Updates per tick: 1

https://i.imgur.com/YVQQXS8.png

Enabling and setting up clearance stations has by the looks of it, fixed it. Since posting the OP we've not had an issue.

Yes, train ids change because the transit through an elevator is actually a copy/delete. I don't think enabling the clearance station did anything for this problem, it's just coincidental.

The schedule is touched at only a few points:

1. LTN adds the provider and the requester when the delivery is created
2. Next, as soon as LTN is done updating its dispatcher, this mod adds the elevator stations before and after the requester (and the clearance stations, if enabled)
3. When a train transitions through an elevator LTN is instructed to add missing temporary stops because those are only allowed to exist on the same surface as the train.

It's really odd that the up transition got added but the down one wasn't because that works off of the same search through the schedule. Do you use other mods that might have removed or overridden the down transition?

When I find trains not unloading fluids I usually copied a pump condition from somewhere else and forgot to change the fluid type or the pump's wire is connected to the wrong thing or I just accidentally flipped the pump.

Another possibility is that the tank wasn't connected to the LTN input which results in LTN scheduling more trains than the tank can handle. So if the fluid isn't used up, the train will leave the station with a full fluid wagon after 2min (LTN's default timeout).

... but we can rule all of that out because the train arrived at the depot well before the two minutes were up.

Quick view of our LTN config: https://i.imgur.com/VdPQJr4.png

We've seen both item and fluid trains do it, but for the most part (and since enabling clearance stations) it's not happened (going on 6days now). We do have the mod 'Glutenfree waterboarding': https://mods.factorio.com/mod/glutenfree-waterboarding to keep trains in the unload stations while they have fluid in them indefinitely.

As for item trains, this is a schedule of a working train: https://i.imgur.com/mf4QR2o.png Between that and having stop timeout disabled, the train waits till its unloaded (much cleaner having trains queuing up forever, then random items throughout the train network).

I did gloss over the fact we have 'Limit Trains' set to 1 on just about all our Provider/Requesters. I'm wondering if when it copy/deletes the train it detects the station is full and cancels the schedule? With Clearance stations not having a limit (and there being a few of them), this is why I'm thinking maybe it's the reason.

And as before we do limit the Depots to 1 train, but we have far more then what we need on each surface, and that should only cause repathing (left over from TSM, before we removed it for LTN Elevators).

I'll try and get a screenshot of a fluid train schedule that's working through the Elevator.

The waterboarding mod only seems to modify the stop conditions so that should not drop any schedule entries - but I've never used that mod myself. Maybe its logic to find the requester gets messed up if the schedule-position of that station changes?

LTN does not interact with Factorio's train limit because it has its own train limit signal which existed way before Factorio introduced that feature. So a train going into "Destination full" state has no effect on a LTN delivery. I personally use LTN's signal because it's a little more flexible and never set Factorio limits on logistic stops - but I limit the depots, same as you.

"Delivery completes at requester" is disabled - as it should be - so that's not the reason, either.
The only other time LTN resets schedules is when a train arrives back at a depot.

Sorry I missed the word 'signal' for the Provider/Requesters.

Depots use Factorio station's Train Limit (Factorio 1.1) set to 1
Providers/Requesters use the circuit signal 'Limit Trains' (LTN) which for most stations is set to 1

Due to the fact it wasn't happening on every train (our stations are all blueprinted and multiple requests previously and afterwards had worked, I'm wondering if it is maybe a race condition between either deleting the original train and creating the new one (we have 1 train allowed to the station), but to copy it implies there is 2 trains with that schedule, even if you are deleting one right after.

That or during the time it's moving through the elevator, LTN assigns a new train to pick something else up?

I don't know if the Train ID increment is just a +1 for each new train, but in my initial post, the Train Log pick has a train with an ID of 416k. Train log is saying the largest Train ID is now 876k. I'll be honest with you, we have definitely not placed anywhere near that many trains. That should give a rough idea of how many trains are going through the elevator (almost a constant stream, we are considering setting up a 2nd in parallel). For it to be happening rarely with that many trains moving around, it's likely a race condition.

One other thing I didn't mention, our trains are terminal style. Loco's on either end (facing opposite directions), 4 wagons in between. From the top of my head, stylising it should be like:

<L< C C C C >L>
<L< T T T T >L>

At the core of LTN's cross-surface API is the ability to re-assign the delivery to a new train and that is what is used here when SE raises an event that it started copying a train at an elevator. So LTN can't really loose track of a delivery. It could with a train that only consists of a single locomotive because that train would stop to exist before SE's event is raised. But LTN would never pick such a train for a delivery because it has zero storage capacity.

The composition of a train is not important, as far as I can see. LTN only keeps track of train capacity at a depot in order to pick the most suitable train. When a train starts a delivery it no longer cares about that. SE doesn't care at all, an elevator just copies the train piece by piece.

Don't worry about the train ids. They change whenever the train composition changes, i.e. whenever another piece of the train passes through the elevator and is coupled to the pieces that have already passed through. LTN keeps track of Factorio coupling events on its own even without any surface transitions.

The only thing that touches the schedule during a transition is the code that adds missing temporary stops but that's purely additive. I'm still at a loss where the schedule might have lost the entry to drive back through the elevator after delivery.

One thing I noticed that will mess up train routes going through an elevator is if trains get stuck and deliveries time out before going through the elevator. The trains will still have most of the schedule but the temporary stop right in front of the receiver station will never be added. That's because at the time such a train drives through the elevator it is no longer a train doing a LTN delivery so no attempt will be made to add the temporary stop.

There's no way to avoid this situation. LTN has already abandoned the train and this mod depends on LTN to determine if it should act. If such a train can be identified manually and hasn't picked up any cargo yet, it is best to send it back to the depot rather than having it pick up cargo and delivering that to the closest station with a matching name.

I notice this whenever I'm researching. @elementalist, were your researching as well when this was happening to you?

nvm, i stopped researching and it still happens.

@elementalist, what's the clearance station that you are talking about?

The tooltip of the corresponding map setting explains what a clearance station helps to solve.

Nvm, I see what a clearance station is, will try if that helps to resolve the issue once and for all

Has anyone solved this issue? It seems to be happening still. My trains get stuck half way into the elevator and lose their stops, then about 1 minute later they get forced through and the stops come back automatically. It wouldn't be a huge issue aside from backing up several trains trying to get into the elevator. Any help would be greatly appreciated. Thank you!

As I learned from this report Factorio has a deep-rooted issue that it silenty drops events mods send each other if those events reference an entity (train, station, elevator) that no longer exists. LTN sends all the delivery-data in one big event which means if there's a single broken surface connection (i.e. elevator removed in an unforeseen way), the whole thing is dropped leaving receiving mods like this one clueless about what happened.

I'm not entirely sure that scenario pertains to the problem here but it might be worth resetting surface connections and re-connecting the elevators.

Before you do that create a backup savegame. Also, there probably shouldn't be any pending deliveries so it's best to disable LTN's dispatcher in the map settings and wait for deliveries to finish. Clearing out surface connections then requires a script command which will disable achievements:

/c remote.call("logistic-train-network", "clear_all_surface_connections")

If there is no error feedback the command worked.

After that toggling elevators back and forth should be enough to re-connect them.
Also don't forget to turn LTN's dispatcher back on.
I know, it's not an easy procedure and as I said, this is more of a long shot.