Issue with Reading Train Contents

[evopwr]

I have Read Train Contents on, and connected to stack inserters, where I only want them to be enabled if there is <1000 items (of that item) on the train.
This works, but... There seems to be a delay as the train reaches its stop, where it hasn't yet got the contents signal, but the inserter activates, transfers 1 stack, then gets the signal, and disables.
After a period of time, eventually the train fills up, as it keeps adding 10 items (with stack research I'm currently at), every time the train pulls in.

1) How can I stop this?

2) Should this not be fixed? I found it quite counter-intuitive. Even if a 1 tick delay is required for inserters putting items in a cargo wagon, to allow time for the signal to come across.

Thanks!

[Lav]

Wire signals need some time to propagate. Even if it's just a single tick, it's enough for the inserter to start loading the train because inserter's current signal states that the train does have less than thousand items.

You need to make a more complex system for load control. Two combinators should be enough. Retrieve both train cargo and train ID. Place one combinator to output L=1 when cargo is less than required. Put another to output L=1 when train's ID (it's T signal by default) is not zero. Activate your inserter when L=2 (i.e. both combinators are active).

[evopwr]

Ah! so obvious, silly me! Thanks heaps Lav!

[SupplyDepoo]

Couldn't the logic be changed so that cargo wagons can't be interacted with for 1 tick after the train comes to a rest, so that the inserters get the needed signals in time?

I don't think the current behavior makes much sense and making this change would be unnoticed by most players. Having to add extra combinator logic for this just seems like busywork.

People who do want this weird effect could still achieve it with some extra combinators. The most common case (putting limits on inserters just like you do with mixed chests) should be simple and intuitive IMO.

[astroshak]

Well, usually you have either slot locking on the chest (which you can do with cargo wagons, and you can filter the cargo wagon slot, something you cannot do with chests) OR you have a wire connecting the chest to the inserter.

It takes 1 tick (1/60 of a second) for the signal to pass through a device. In the case of wiring a chest to an inserter, there are no intermediary devices between the chest and the inserter, so the inserter gets to go ahead immediately.

In the case of a train, the train stop appears to count as a device. So even if the inserter is wired directly to the stop, there is a slight delay before the inserter gets whatever signal the train stop is sending. Normally that would not be a problem, right?

There is no zero value for signals. It’s a “null” signal instead, or there is no signal. So the inserter sees “null” in the X < 800 channel, and starts swinging. A tick or two later, it gets the hold signal X is 802 or something higher than 800, but that won’t stop the current load, it takes effect on the next load (pending a signal change).

I have not really messed with that much; I prefer to slot lock and filter certain trains (building trains) and control its cargo that way. I’ll also slot lock and use filter inserters for the unload, so I don’t overfill a destination station.

[SupplyDepoo]

Good point, but slot locking doesn't work when each leg in the train's schedule has different cargo (to maximize efficiency you can deliver ingredients in the exact ratio and pick up the products with one train instead of two trains each running one leg empty), or when transporting barrels (the ability to mix different fluids in one cargo wagon is one of the advantages of barreling over fluid wagons).

In either case, the current train stop behavior isn't particularly helpful. I know there must be some players who are exploiting this behavior in some crazy way but I suspect it's pretty rare, and most players who are aware of it will receive the change positively. In the end, both behaviors could be achieved one way or another (as default or with combinators), and the current workaround would even continue to work without any changes necessary, but most importantly the default behavior would be more intuitive and hassle-free. I guess I should post this as a feature suggestion, but it's admittedly pretty minor.

Thanks for your reply.

[pollux688]

Wire signals need some time to propagate. Even if it's just a single tick, it's enough for the inserter to start loading the train because inserter's current signal states that the train does have less than thousand items.

You need to make a more complex system for load control. Two combinators should be enough. Retrieve both train cargo and train ID. Place one combinator to output L=1 when cargo is less than required. Put another to output L=1 when train's ID (it's T signal by default) is not zero. Activate your inserter when L=2 (i.e. both combinators are active).

Thanks for this! I have been playing a while but I had never explored the circuit network and had been struggling trying to solve a minor problem.

I've been building a "Builder train" to bring out to build new outposts and I wanted it to hold 4 nuclear plants. I ran into the issue mentioned by the OP where it would add one more plant each time the train showed up already holding the 4 I wanted there.

This worked great and was really helpful to me in learning to use the circuit network!

[FuryoftheStars]

Couldn't the logic be changed so that cargo wagons can't be interacted with for 1 tick after the train comes to a rest, so that the inserters get the needed signals in time?

I’m not sure that this would have worked because the delay in the signal isn’t guaranteed to be 1 tick. As mentioned, every device it passes through causes a 1 tick delay, so more complex setups where you have 2, 3, 4, or more hops before it reaches the inserter would still have the issue.

[mrvn]

Set "Read stopped train" and connect the train stop to a decider combinator "iron plates < 1000: output T". Connect the inserters to the decider combinator and activate when T > 0. That way they activate when the train signals are available instead being always active with no signal.

Note: If the train is ever full you might end up with inserters holding items and hovering over the track. They will then place those items into the next train regardless of any circuit condition. But at least that will only happens once and not every time.