Train Schedule Nested OR

[Rotaretilbo]

I'll preface this by saying that I did some cursory searching, and didn't see discussiong of nested OR (which surprised me), but maybe I'm not using the right terminology to look, so I apologize if this duplicates an existing suggestion.

I'm somewhat new to the game, and I've been playing around with trains. In the past, when I've run up against a UI issue, I've generally googled it and found out that, yes, the thing I wanted was already implemented, and I'd just missed the cue or tutorial that explained how. "Man, it sure would be nice if I could copy paste filter set- oh, I see, I just have to press this button and then this button, huzzah!" Etc etc. And to an extent, that has been the case with trains, such as learning that the textured surface in the GUI can be clicked and dragged to reorder train stops and conditions. However, it does not appear to be the case with nested OR.

TL;DR

I would like to suggest the ability to nest an OR() within an AND() when setting up wait conditions in train stop schedules, in order to greatly reduce the tedium of setting up complex wait conditions.

What ?

I would like for train schedules to allow for an OR() nested within an AND(). There's not really any more what to it, other than GUI considerations.

This would involve slightly widening the train schedule GUI to allow for a third switch position for the AND/OR operator. With only 2 conditions at a train stop, clicking would rotate between right AND and right OR, as is currently implemented. With 3 or more conditions, clicking would rotate between left OR, middle AND, and right OR.

Additionally, the logic to draw the AND brackets (and also governing AND in general) would need to also treat adjacent right ORs as AND.

Why ?

Now, I understand that Factorio trains currently use DNF to processes AND and OR statements in train stop logic, but I find this extremely tedious to work with. Let me give an example.

Let's say I have a train, which goes from location A, built near a number of off-site ore deposits, and picks up iron ore, copper ore, and coal. The train then goes to location B, which is a smelting and manufacturing hub, and offloads the ore. I want the train to only stay at the stations as long as is necessary to offload needed resources. However, in some cases, my mining operation is overproducing a type of ore, or the demand for a particular kind of ore (such as coal, to run steam turbines at night when solar is offline) is variable.

So what I want to do is have the train check one of two conditions for each ore. If, either, the train contains 0 of that ore, or the buffer box that the train loads that type of ore into is full, then the condition for that ore is met. It would look something like:
OR
{
    AND
    {
        OR
        {
            Item.Count(Iron Ore = 0)
            Circuit.Condition(Iron Ore >= 800)
        }
        OR
        {
            Item.Count(Copper Ore = 0)
            Circuit.Condition(Copper Ore >= 800)
        }
        OR
        {
            Item.Count(Coal = 0)
            Circuit.Condition(Coal >= 800)
        }
    }
    Inactivity(15)
    Time.Passed(120)
}

However, it is not possible to nest OR within AND. So instead, it looks like this:
OR
{
    AND
    {
        Item.Count(Iron Ore = 0)
        Item.Count(Copper Ore = 0)
        Item.Count(Coal = 0)
    }
    AND
    {
        Circuit.Condition(Iron Ore >= 800)
        Item.Count(Copper Ore = 0)
        Item.Count(Coal = 0)
    }
    {
        Item.Count(Iron Ore = 0)
        Circuit.Condition(Copper Ore >= 800)
        Item.Count(Coal = 0)
    }
    {
        Item.Count(Iron Ore = 0)
        Item.Count(Copper Ore = 0)
        Circuit.Condition(Coal >= 800)
    }
    {
        Circuit.Condition(Iron Ore >= 800)
        Circuit.Condition(Copper Ore >= 800)
        Item.Count(Coal = 0)
    }
    {
        Circuit.Condition(Iron Ore >= 800)
        Item.Count(Copper Ore = 0)
        Circuit.Condition(Coal >= 800)
    }
    {
        Item.Count(Iron Ore = 0)
        Circuit.Condition(Copper Ore >= 800)
        Circuit.Condition(Coal >= 800)
    }
    {
        Circuit.Condition(Iron Ore >= 800)
        Circuit.Condition(Copper Ore >= 800)
        Circuit.Condition(Coal >= 800)
    }
    Inactivity(15)
    Time.Passed(120)
}

And every item that is being offloaded further increases the complexity. In actuality, I have a train going from an oil hub, picking up plastic, sulfur, solid fuel, batteries, and lubricant (5 items), dropping those off at the manufacturing hub, and in turn picking up iron plates, copper plates, and coal (3 items) from the manufacturing hub to take back to the oil hub for chemical processing. To prevent the train from just always sitting until Time.Passed(120), I need 256 condition lines for the manufacturing hub (2^5 * (5+3)), and 64 condition lines for the oil hub (2^3 * (5+3)).

Now maybe I've somehow missed something. Googling around seemed to confirm that, no, you can't nest an OR within an AND, and yes, if you want to do AND(OR(A,B),OR(C,D)) you actually need to do OR(AND(A,C),AND(A,D),AND(B,C),AND(B,D)), but maybe there is a simpler way to do this. I've only scratched on the surface of the circuit network - I'm using it to check the buffer boxes the train loads, and I've used it previously to disable loading inserters at one train stop if the buffer boxes at the destination are full (before I discovered I could use item filters in the train cars, which was a lot easier), but I've not really played around with the various combinators and the like. But it definitely seems like, to do what I want to do, this is what I have to do.

So I started doing that. I have a relatively passive playstyle, and a lot of the times I'm just letting automated processes run while I talk with friends or watch Youtube or whatever on the side, and then checking to see if there are any problems (like two trains stuck or a shortage of a particular resource or bugs have attacked my perimeter) or if I have the resources to do something fun (usually research, but I'm also currently waiting on uranium processing before starting up nuclear power for the first time). My train going between the oil hub and the main hub has 66 condition lines for the oil hub train stop (+2 for an inactivity and time passed failsafe). And it was mind numbing to put together. What we ended up with was:
OR
{
    AND
    {
        Item.Count(Plastic Bar >= 1000)
        Item.Count(Sulfur >= 500)
        Item.Count(Solid Fuel >= 500)
        Item.Count(Battery >= 2000)
        Item.Count(Lubricant >= 25000)
        Item.Count(Iron Plate = 0)
        Item.Count(Copper Plate = 0)
        Item.Count(Coal = 0)
    }
    AND
    {
        Item.Count(Plastic Bar >= 1000)
        Item.Count(Sulfur >= 500)
        Item.Count(Solid Fuel >= 500)
        Item.Count(Battery >= 2000)
        Item.Count(Lubricant >= 25000)
        Circuit.Condition(Iron Plate >= 1600)
        Item.Count(Copper Plate = 0)
        Item.Count(Coal = 0)
    }
    {
        Item.Count(Plastic Bar >= 1000)
        Item.Count(Sulfur >= 500)
        Item.Count(Solid Fuel >= 500)
        Item.Count(Battery >= 2000)
        Item.Count(Lubricant >= 25000)
        Item.Count(Iron Plate = 0)
        Circuit.Condition(Copper Plate >= 1600)
        Item.Count(Coal = 0)
    }
    {
        Item.Count(Plastic Bar >= 1000)
        Item.Count(Sulfur >= 500)
        Item.Count(Solid Fuel >= 500)
        Item.Count(Battery >= 2000)
        Item.Count(Lubricant >= 25000)
        Item.Count(Iron Plate = 0)
        Item.Count(Copper Plate = 0)
        Circuit.Condition(Coal >= 800)
    }
    {
        Item.Count(Plastic Bar >= 1000)
        Item.Count(Sulfur >= 500)
        Item.Count(Solid Fuel >= 500)
        Item.Count(Battery >= 2000)
        Item.Count(Lubricant >= 25000)
        Circuit.Condition(Iron Plate >= 1600)
        Circuit.Condition(Copper Plate >= 1600)
        Item.Count(Coal = 0)
    }
    {
        Item.Count(Plastic Bar >= 1000)
        Item.Count(Sulfur >= 500)
        Item.Count(Solid Fuel >= 500)
        Item.Count(Battery >= 2000)
        Item.Count(Lubricant >= 25000)
        Circuit.Condition(Iron Plate >= 1600)
        Item.Count(Copper Plate = 0)
        Circuit.Condition(Coal >= 800)
    }
    {
        Item.Count(Plastic Bar >= 1000)
        Item.Count(Sulfur >= 500)
        Item.Count(Solid Fuel >= 500)
        Item.Count(Battery >= 2000)
        Item.Count(Lubricant >= 25000)
        Item.Count(Iron Plate = 0)
        Circuit.Condition(Copper Plate >= 1600)
        Circuit.Condition(Coal >= 800)
    }
    {
        Item.Count(Plastic Bar >= 1000)
        Item.Count(Sulfur >= 500)
        Item.Count(Solid Fuel >= 500)
        Item.Count(Battery >= 2000)
        Item.Count(Lubricant >= 25000)
        Circuit.Condition(Iron Plate >= 1600)
        Circuit.Condition(Copper Plate >= 1600)
        Circuit.Condition(Coal >= 800)
    }
    Inactivity(15)
    Time.Passed(120)
}

With nested OR, it would instead look like this:
OR
{
    AND
    {
        Item.Count(Plastic Bar >= 1000)
        Item.Count(Sulfur >= 500)
        Item.Count(Solid Fuel >= 500)
        Item.Count(Battery >= 2000)
        Item.Count(Lubricant >= 25000)
        OR
        {
            Item.Count(Iron Plate = 0)
            Circuit.Condition(Iron Plate >= 1600)
        }
        OR
        {
            Item.Count(Copper Plate = 0)
            Circuit.Condition(Copper Plate >= 1600)
        }
        OR
        {
            Item.Count(Coal = 0)
            Circuit.Condition(Coal >= 800)
        }
    }
    Inactivity(15)
    Time.Passed(120)
}

This leads to... I don't want to call it a second request, so much as an alternative fix. If implementing nested OR is not possible (or rather, too technically complex to be deemed worth the effort), then I'd really like to extend the shift+right click/shift+left click function to be able to copy and paste wait conditions within a schedule. Using my oil hub example, there are 8 AND strings of 8 lines each, but in each of them, 5 lines, the conditions for the 5 resources being loaded at this site, are always the same. Being able to copy and paste those 5 lines 7 times, rather than having to manually add them every time, would have made the task a lot less tedious. Additionally, while there are 24 variable lines, there are only 6 unique lines, so copy pasting would potentially save a lot of time there as well. It'd certainly make the prospect of doing this for the manufacturing hub much less daunting. That isn't to say that you shouldn't consider implementing this if you do implement nested OR, but I think it would have a lot less utility in that instance.

Anyway, I hope all that makes sense and is correctly formatted, etc.

[FuryoftheStars]

Hmm, not saying it's a bad idea or shouldn't be done or anything like that, but couldn't this be solved by having the station output the train's contents and then use combinators for the deciding logic? Then your train schedule logic would look something like this:

OR
{
    Circuit.Condition(Green Signal = 1)
    Inactivity(15)
    Time.Passed(120)
}

[Rotaretilbo]

As I said, I've not explored circuit networks in much depth, so there may be an easier way therein. I wouldn't be surprised if there was a more robust way to handle all the logic with the circuit network.

That said, the circuit network seems incredibly opaque to newbies like myself, which is part of why I've largely avoided it up 'til now, so there's probably still some utility in allowing more complex train scheduling. I'm also not sure if the circuit network workaround scales (though maybe it does; if a single network can output more than one "on" signal at a time, that would allow for scaling even in complex use cases).

[mmmPI]

As I said, I've not explored circuit networks in much depth, so there may be an easier way therein. I wouldn't be surprised if there was a more robust way to handle all the logic with the circuit network.

That said, the circuit network seems incredibly opaque to newbies like myself, which is part of why I've largely avoided it up 'til now, so there's probably still some utility in allowing more complex train scheduling. I'm also not sure if the circuit network workaround scales (though maybe it does; if a single network can output more than one "on" signal at a time, that would allow for scaling even in complex use cases).

I agree there would be utilities to allow more complex train scheduling and the circuit network seem opaque. It is frequently proposed to add things to the schedule with many different little variations some of them including circuit network interactions, and as you noted it may be difficult to implement, and to make sure it doesn't create problem and as such i wanted to say that given the complexity of the logic you already use in your schedule i think you would probably find your way around combinators before it is implemented if ever even though it look opaque

One first step to support what FuryOfTheStars said would be to transform this
        Item.Count(Plastic Bar >= 1000)
        Item.Count(Sulfur >= 500)
        Item.Count(Solid Fuel >= 500)
        Item.Count(Battery >= 2000)
        Item.Count(Lubricant >= 25000)
into
Circuit.Condition(Green Signal = 5)

For this you need too use "read train content" and "send to train" as it seem you are using currently. Then the straightforward approach i can think of is to use 1 decider combinator per material with their input wired to the train stop so as to read the train content, then set up as [ (if) Plastic Bar >= 1000 (then) Output 1 Green Signal] and the output wired to the train stop too, this time to send the green signal to the train.

It's a start, instead of not being able to copy paste schedule line you can with combinators.

It would require maybe too many combinators to do such simple thing. So you could refine the logic, for example using only 1 constant combinator and 1 decider combinator, You can write all the value in negative in the constant combinator, like -1000 Plastic Bar ; -500 Sulfur ; -500 Solid fuel ; -2000 Battery and so on. Then you wire this constant combinator to the train stop, and to the input of the decider combinator all with the same color of wire, this way you can set up the decider combinator as [ (if) Everything >= 0 (then) Output 1 Green Signal]. The "Everything" being one of the signal like the colors or the letters but with special properties. This checks all the material at once and output 1 green signal if all of them are above the targeted value, so the schedule would be Circuit.Condition(Green Signal = 1) instead of the 5 lines of schedule.

Maybe it can help for your base or give you ideas to try things with combinators. In such cases the scaling would be i think a question of how many combinators per train stop, which depending on the complexity of the logic and how it is implemented may or not make sense. If you can do it with 2 or 5 or 10 combinators that's not 100 or 256 , at which point it's a bit ridiculous for a number of combinator per station for practical use .

Where you would run into colliding circuit network, as you mentionned your interrogations, would be if you start connecting the buffer boxes to read their quantity. If you connect with wires 2 boxes and you read the wire signals, it will show the quantity of the 2 boxes, so if one has 5 iron and the other 3, you would read 8. I'm not sure what you call the "on" signal but if it's the green v or the dot signal, or any signal like the color or letter signal, it would be the same. This is also why you can write the negative value in a constant combinator, as it will be summed with the content of the train and the result will be used as input for the decider combinator.

Overall there are a few rules to learn, but then the possibilities are endless and it seems suited for your case since you know already how to nest your logic operations I think your explanation made sense, and was formatted correctly, but maybe i misunderstood part of it, sorry to talk away from the suggestion, but again i think for the particular use case you mention you may enjoy more spending the time fiddling with combinators rather than continuing to copy super long schedule or get stuck because of that and it may gives you second look on the matter.

[Rotaretilbo]

So the gist of my current setup is as follows:

I have 4 train stops, and 2 trains. There's an oil train, previously described, which is ferrying oil byproducts to manufacturing, and the necessary non-oil ingredients for those byproducts back, and there's a train ferrying ore from a couple places back to the manufacturing hub, after I exhausted all of the local ore there.

At a given stop, any resource being offloaded is pulled off by a filter stack inserter into a wooden box as a buffer, and then onto a conveyor by a stack inserter. This means that each buffer box at a given train station handles only one resource, and each resource at a given train stop is only ever in one buffer box.

Right now, I use the red wires for the oil train, and the green wires for the ore train. I have circuit networks reading the contents of buffer boxes, and passing that to the train, but not reading the train's content. Basically, I want to know if the train is unable to offload a given resource because the buffer box is full, as one of two conditions (the other being that the train has none of a given resource and so is finished offloading it, which the train schedule can theoretically handle) to determine if a train is "finished" offloading that resource.

This prevents me from reading train contents, with my current setup. A workaround might be to handle the buffer boxes on say the red circuit network, and maybe there's some way to pass a signal from the red circuit network to the green? With my limited knowledge, the thing that comes to mind is having a wood box with two inserters, one in and one out, and a transport belt leading from the out inserter to the in inserter, such that if the buffer boxes are all full, the in inserter inserter is active, and if the not all of the buffer boxes are full, the out inserter is active. Then, you have a unique object that you wouldn't otherwise have on any circuit network (like your obsoleted pistol) in the box initially. You'd hook the buffer boxes and the inserters to say the red circuit network, and then the train stop and the box the pistol goes in to the green circuit network, and the the train checks whether there's 1 or 0 pistols in the green circuit network, and a green combinator can read if the train is full. Or really, you'd need to have one of these pistol-in-a-box setups for each resource being offloaded, and so you'd need several unique objects (light armor, a burner mining drill, etc), but that could allow for at least some of the logic to be offloaded, which would cut down on condition lines in the train schedule. But that's mostly my idle ramblings, knowing very little about the circuit network. There's probably a much more elegant solution that I'm missing.

As for multiple "on" signals, basically what I meant was, can a single circuit network pass multiple unique signals so that different trains can check for different things. If you have 2 trains both loading at the same place, and they're loading different things, you'd want to be able to tell each train when they were full, and so you would need Train A to look for "on" signal A, which is given by some combinator checking against the things loaded into Train A, and Train B to look for "on" signal B, from a different combinator checking against the things loaded into Train B. The combinator signal you described sounds additive, and so probably wouldn't work at scale like this, but I glanced at the train schedule circuit condition interface, and see that there's seemingly channels A-Z and a few colors beside, so that probably does what I was thinking. Worst case, the workaround I described above could work to simulate multiple "on" signals by using various unique objects, but that wouldn't be terribly space efficient, with each such setup taking up a 3x3 area.

I'll definitely look more into circuit networks eventually. I imagine that, once I get through the initial learning phase, they'll be quite powerful, I'm just procrastinating on learning.

[FuryoftheStars]

This prevents me from reading train contents, with my current setup.

Actually, it doesn't.

[mmmPI]

maybe there's some way to pass a signal from the red circuit network to the green?

yes you can use an arithmetic combinator whose input is a red wire, and do the operation signal+0 output=> Everything and use a green wire for the output

As for multiple "on" signals, basically what I meant was, can a single circuit network pass multiple unique signals so that different trains can check for different things. If you have 2 trains both loading at the same place, and they're loading different things, you'd want to be able to tell each train when they were full, and so you would need Train A to look for "on" signal A, which is given by some combinator checking against the things loaded into Train A, and Train B to look for "on" signal B, from a different combinator checking against the things loaded into Train B.

It's not clear for me what you call " a single circuit network". In the case you describe, if you use 2 different train stops for the 2 trains i meant to describe a combinator setup that is emebedded to each of them, so you would have 2 different groups of combinators copy version of one another, 1 attached to each train stop. The combinator logic is attached not to 1 train contrary to the schedule, but rather to 1 train stop. The train receive a signal that is sent by the combinators to trigger its departure. The combinators are setup to send the signal of departure when the ressource condition are met, by connecting the boxes, and using the decider combinator to do the same logic operation as those that would have been on schedule.

I'm not sure i understood properly the system you describe.

I glanced at the train schedule circuit condition interface, and see that there's seemingly channels A-Z and a few colors beside

yeah channels that's how they are called wires are additive, all value in the same channel are added up; 1 constant outputing 5 in channel A and another constant outputing 3 in channel A, if you wire them with the same color, and try to read the value on a power pole it will show 8 in the channel A. But 2 colors of wire are isolated from each other so if you have value 12 in channel A on the green wire and value 5 on the red wire on channel A, it will not make 17 if you connect both wire to the same power pole. But if both color are used as input of the same combinator, the value are added up and the sum is the actual input value for the combinator.

[FuryoftheStars]

Here's an example for you. Uses 4 Deciders and 1 Constant Combinator. I'm not all that great with these myself, so it's possible there's a better way, but this is what I came up with.

Here's the test track I setup:

Setup (small).jpg (143.64 KiB) Viewed 5603 times

And here's the BP string for it:

0eNrNWluSozYU3Qvf0IUknq4kK8hn8pXqcmGQ3aqxhUsId5wpLyALycaykkjIYBkLkDzOJPMzjS86upz7Fnz1NvsWHxmh3Ft99UhZ08Zb/fbVa8iOFnv5Gz8fsbfyCMcHz/docZBX+7qsDzUnJ+xdfI/QCv/urcDFNyw8EcZb8cuwVt0R7BjGVFsNjavvt61wSSrMArH5htCC10wDQJd338OUE06weoju4rym7WGDmdBvwClbdsJVwAoi9TrWjVhTU7mtwAlA5Hvn7n8BXhGGSyVNpIYjTGiJmZghkQES3ZjiAm33wScVTa+o4B41NaBG1qjIDAoMoLHl08NQYWbLkIkd5ABogEi1Ry3KLwGhDWZcSAyKwbdYIYk/lq2dDciEbgkVoqD8wA03IaN75H7BusGcE7pr5I0MH+oTXrdCthcK4mot/V2ItsW+wb6nflbO3G/MahrUDIsty7qVYRsLLg51JYUFD/a46PQZYvLdRFF+Y7lguzr4LHZCdcNTgKszvIUhysMEykepGRFwhbovlFudxHXNznKVrnKvg/+gvFSpj/tZKZqV3py6rI9HkRhG8nhBnizIU00u0pImySYl+aQEhLMPA+Z5AvNEgXmmwBJVYIkrsEQWmGYLTNMFpvmC4cKOcMGz5hmD84zBJcbgEmNwiTE4zRicZgxOM4bCadE8V2ghDOe5QktcoSWu0BJXaJorNM0VGnNlzIZaYC4Vxz4hIiMOsMWZRbmZQoLQoOH18REC9RCyEFDO6v16gz+KExFNUVdaimq9ZfVh3YF4K85aUVG6nyXgURSbO0l3MYis27hfvIvSgKrC2dU1oDSo9C6MVCqiS8LKlnB1LVs21QiO7pT5Sr9T1TFZ0BUF3q90XxeVZ+IPaTanYgXlesP4QGTcF2o0bgEiM7V6iVtoWLVg6ct1ABYa5nuEu2gwYEArjC4qDKtFz2xvPaNNTAaI5hr2B/6joVGyYv8KuRayigw6bwlruJPX+oN3dE2M0PBYsE7DlfeTWFC3/Ng6QOITZmf+IVo7hX08rzu+VRASKsBUqDnEC0DTAQI708GpSAOWtoqfaZZDm2ZZaxgcuuXwpd2yFj3f1C+D1LlCACPOrVQ17abPZobJTs2LoaCCYrHbpm67B0Phuwk1d6w7Rt20dssmbHuLhZd/MU5xUX68PlSHo4eJKO38yaWsgXFZ8+/l6UPZmwndLrKNBgJP5dXw+6XVZXP98ExmHVBfYq1xGVtIpKFdItWGDftECmzyqD6nWOdR8OI02pnlGxIojFwTqDlH3coV3gvSGCkDTDHbnQXfQuttUWJTOlXHRaMGQ+TYTbvdCqdvyB9YjgHDP9PWiVuSNeufPhXC8Pvm2Cwch+3ff/713wcuSl8TqZnpGHvSD+O3PE/CHKWPR18yxh7hc1dPN06B2ig/2ymgK8SoUQCZqVFAjgOqWbNbptu0TASfVaqLbVIdeibVxf+zVIecU11shIndbGUGSUZVST3xjMV6e0UP9vJtz3aNnndLfJ+1IJRO2RXd7W/bgKXj0L9vwCI0kQuQ/Yl+fKeYm7tdx77H7XPrpiGatIvpZY/zgVZqUi9yTBdmEPisCyauLqiflZicMEKOTpi4OCFKR14XhxNeF0Wa1y0ZPLEyeOzsx8kL/ThKrI4sA6iqVf4wkdzO9X6eONWLnCfw3Khp5ubSZpD8WZfO3F1anVob3r2Gjs6cuTjzZMaMgYPvZja+G0Nn381e6LsxcnuJPX6FH5kwI5e32GNEU1cZx65fBYDUAjVx+yQChssfGsSp0ycRY0hogswcP14YP3t3jNoIp6ra/fXbkFvrL69hpt2gDvbvM5LvfRaiudAHLXGTmpHw+joHdSPc9e9tu+8D9+GlhTPYtbfp+tLrmicGPe3Yq5/00GjO+9HrQmRGFTGqClJPwjzyN1J+EcrnamCeWcXJAd/uT2EoS+O7tEr3pmKlfYbkeyeRDZUvZCBKc5gmSZwlWXa5/APs1js3

Copy blueprint

Closeup of the combinator circuit logic

Circuits.jpg (79.66 KiB) Viewed 5603 times

The basic concept is this:

• The unload station is set to "Send to train", "Read train contents", and "Read stopped train" (outputted as "T" by default). It has a green wire connecting it to the input of (what I'm calling) Decider Combinator 1, and a red wire connected to the output of Decider Combinator 4 (while I did put these on different color wires, you don't actually need to in this setup (the logic happens to work out that way here)).
  
  
  Why read the stopped train

  Because, for the purposes of reading the train's contents, no signal (ie, the train is not there) is the same exact thing as a 0 signal (the train is there, but the contents you are reading are empty) and there is a processing delay of 1 tick for every combinator or other entity the signal needs to pass through. If you just processed the train contents directly, then what happens is your "empty contents" logic will process TRUE when there's no train, then when the train does arrive, it's going to get the signal from the "empty contents" processing to leave before the circuit has a chance to update with the train's contents. By putting in some logic that uses the train's ID, you can have the "empty contents" logic return FALSE when the ID is non-existent/zero.
  Station details image

  

  Station.jpg (189.92 KiB) Viewed 5603 times

• The Constant Combinator is connected to the input of Decider Combinator 1 with a red wire (while I did put this on a different color wire, you don't actually need to) and outputs a -1 signal for each material you are concerned about at this station (for this example, iron, copper, and coal). The -1 is just to get around the idea of zero / non-existent signals being the same.
  
  Constant Combinator details image

  

  Constant Combinator.jpg (121.32 KiB) Viewed 5603 times

• Decider Combinator 1 (having inputs from the station on the green wire and Constant Combinator on the red) is just a signal gate and does our train ID signal processing. If the train ID (signal "T"; you can change this to something different if you want, you just need to make sure it matches whatever the station is outputting for the train ID) is > 0 (ie, there's something there), then it just forwards through everything to the input of Decider Combinator 2.
  
  Decider Combinator 1 details image

  

  Decider Combinator 1.jpg (114.74 KiB) Viewed 5603 times

• Decider Combinator 2 takes the input of Decider Combinator 1 and for each signal that is less than 0, it outputs that signal with a replaced value of 1 to the input of Decider Combinator 4. It should only ever be able to output the same signals as what the Constant Combinator is outputting, just with a replaced value of 1.
  
  more details

  When there is no train (signal "T" from the station is non-existent), Decider Combinator 1 will not forward on any signals (such as the Constant Combinator's). This means in this condition, there will be no inputs to this combinator, and so it will output nothing ("empty contents" logic is FALSE). This keeps our train from receiving the signal to leave just as it shows up to the station.
  
  When there is a train (signal "T" from the station > 0), Decider Combinator 1 will forward its signals. This combinator will only forward on a signal that is < 0, so only the signals coming from our Constant Combinator can make it through when the train is empty of that item ("empty contents" logic is TRUE).
  Decider Combinator 2 details image

  

  Decider Combinator 2.jpg (112.29 KiB) Viewed 5603 times

• Decider Combinator 3 takes in the inputs from the chests and only forwards on those that meet or exceed a given value (800 in this case), replacing their values with 1 as it does so. This signal goes to the input of Decider Combinator 4.
  
  Decider Combinator 3 details image

  

  Decider Combinator 3.jpg (113.59 KiB) Viewed 5603 times

• Decider Combinator 4, our last one, very simply does a for each signal greater than 0, output a green signal with a value of 1 to the station. Because the potential signals coming from Decider Combinators 2 & 3 should only ever be of the same signal types, it can only ever output a green signal count that matches the number of different inputs.
  
  Decider Combinator 4 details image

  

  Decider Combinator 4.jpg (110.27 KiB) Viewed 5603 times

• And finally, our train schedule. It can leave if it has a green signal = 3 (the number of different items this train deals with), 15 secs of inactivity (which, if you think about it, should never be met), or if 120 secs passes (which also should never be met unless you're maybe using one or two slow inserters per wagon).
  
  Train schedule image

  

  Train Schedule.jpg (57.55 KiB) Viewed 5603 times

You can use the provided BP string above and then play with the inserters that are unloading the wooden chests into the infinity chests via upgrading and downgrading to get it to change which outputs get backed up and which ones will allow the train to empty its contents.

[Rotaretilbo]

So I did eventually mess around with the circuit network. I didn't use your setup, mostly for lack of understanding at the time (I think I understand it better now). The setup I use is certainly more crude, but works vaguely as follows.

For each resource a train might load or offload, there are 3 deciders. We'll call them Decider A, Decider B, and Decider C.

Decider A sits next to the resource buffer box(es), and that's its input on an isolated green network. For a resource being loaded, it's checking if the buffer is empty, and for a resource being unloaded, it's checking if the buffer is full. It outputs TRUE/FALSE on the resource's channel over a shared red network, which travel along poles to the pole nearest the train stop.

Decider B sits near the train stop, and that's its input on a shared green network. For a resource being loaded, it's checking if the train is full, and for a resource being unloaded, it's checking if the train is empty. It outputs TRUE/FALSE on the resource's channel over the same shared red network as the Decider As.

Decider C also sits near the train stop, but it's input is the red network that all Decider As and Decider Bs share. It's checking if the relevant resource channel is >0. This effectively creates an OR gate, where if either A or B, or both, are outputing TRUE, then C will output TRUE. It outputs on a channel specific to the relevant train, I'm currently using white and black for my two trains. Decider C then outputs on a shared red network directly to the train stop.

To get around the issue where Decider B reads the train as empty when no train is present, and this causing trains to immediately receive the go signal when they arrive, I initially tried a couple decider setups that didn't work (I realize now that I could have had all Decider Bs sit behind a Decider X, which checked the train signal and passed through the train's contents only when a train was present; the setups I'd been using involved the decider checking for a present train being a separate decider chain, and this resulted in it's confirmation tick reaching the train before Decider C realized the train was not actually empty), so I ultimately ended up setting the train schedule to have 4 lines:
OR
{
    AND
    {
        Circuit.Condition(Color >= 2)
        Time.Passed(1)
    }
    Inactivity(15)
    Time.Passed(120)
}

By having the train wait 60 ticks before polling the circuit network, the deciders always have time to sort themselves out.

Anyway, thanks for the help guys. While I didn't fully understand the explanation at the time, it was still instrumental in my understanding circuit networks at all, and also helped me identify issues with my own setup that I wouldn't have otherwise recognized (and probably been very frustrated by). Still think the train schedule could use the update, but I can see why circuit stuff is the current go-to.

[FuryoftheStars]

Not sure if mmmPi mentioned anything about this earlier, but you can also use Map Editor to pause and even step 1 tick at a time so you can better analyze and follow the circuit happenings.