logic system help: releasing train from station when "done"

This board is to show, discuss and archive useful combinator- and logic-creations.
Smart triggering, counters and sensors, useful circuitry, switching as an art :), computers.
Please provide if possible always a blueprint of your creation.
LeftyRighty
Burner Inserter
Burner Inserter
Posts: 6
Joined: Tue Oct 29, 2024 7:23 pm
Contact:

logic system help: releasing train from station when "done"

Post by LeftyRighty »

I've been trying to build (and likely over engineer) a system to bring an arbitary list of and specific numbers of items to outposts as controlled by the selected values in a constanct combinator; mostly to learn more about how the logic system works.

I'm less interested in "is this a good idea" or "there is a better way of playing the game" and more interested in "can i get the logic system to do the (silly) requirements i'm aiming for".

I've managed to put together a system that will load a train wagon with a given list of items/exact amounts as given by a constant combinator at the loading station. When the train is loaded it heads off to the drop station, which currently looks like this...
11-10-2024, 02-32-52.png
11-10-2024, 02-32-52.png (3.45 MiB) Viewed 181 times
At the drop station I've got several things currently working:
  • The drone chests are disabled to prevent the drones changing values and breaking the calcs during unloading the wagon (top red wire).
  • The local contents are compared to the required list from the constant combinator ( i ) to give the required item/amounts to move from the wagon to the chests (output of A).
  • The wagon contents is "type checked" against the required item list so it doesn't get locked up trying to move an item that is wanted but isn't actually on the train (B).
  • The items that are on the train and required (result from C: amount values from A * types from B ) are then moved one type at a time (selector combinator) for the exact amount needed (left section, inserter stack amounts with / and % functions).
The bit that isn't working:
Once all the possible requests are 0, send a signal to the train so it is "released" (red x).

The issues i think i'm running into:
When the train arrives there is a very very brief flicker in the signal network, it seems to take a tick for it/the logic system to catch up with the calcs? so if i have the release check set to see if the outstanding requests to move check set to "everything is 0" for that first tick it is all still nothing and the signal is sent to the train before it realises there are actually amounts to move from the wagon. If the train only has "go to this station" in its manifest (and therefore doesn't want to leave straight away) the logic works and the release signal is only sent once all the loading is completed.
If i try to check that a train is present by getting the T signal from the train stop it seems like the requests take a little longer to get through the logic calcs than the T signal does, so there is still a window where the T is present but the requests are not present so "everything is 0" and the train is released.

I've been trying to play around with different options and i just don't seem to be able to figure this one out, anyone got any advice on how to get this to





... so the rubber ducky effect is real.

Added a T1 signal to the required items in the constant combinator so the T value from the train can get through the type check and is passed through the logic network at the same "speed" as the requirements to the release check combinator.
Added an inversion to remove the T signal from the "everything" channel being checked in the release combinator as it's not an actual request.
Added a second channel so the release signal can check the T signal from within the logic network rather than the train stop.
11-10-2024, 02-44-56.png
11-10-2024, 02-44-56.png (573.31 KiB) Viewed 181 times
11-10-2024, 02-46-42.png
11-10-2024, 02-46-42.png (124.26 KiB) Viewed 181 times
11-10-2024, 02-54-33.png
11-10-2024, 02-54-33.png (208.19 KiB) Viewed 181 times
... and around and around it goes, unloading the pipes that are missing so the drones can move them back to the pickup location :D a train's work is never done :o :lol:

still a little confused by the "it takes time to get a signal through the network" bit, if that is true and what was actually causing the headache :? is that really a thing?

feng
Inserter
Inserter
Posts: 30
Joined: Sat Jun 25, 2016 1:17 pm
Contact:

Re: logic system help: releasing train from station when "done"

Post by feng »

If i understood you correctly your problem is that the train arrives and gets sent off instantly because the circuit needs some ticks to realize it has requested items to unload.

First things first, do you use the editor for troubleshooting your circuit? Especially tick related issues are hard to identify without checking your circuits tick by tick. If not, make a temporary save and use /editor twice in console (watch out, it will disable achievements hence the temporary save).

Keep in mind that EVERY combinator needs 1 tick to process the signal (input -> output).

Without having a savefile its hard to reconstruct your issue, but as a solution to your problem... have you thought about to use a 'wait' condition (1 second) AND your signal condition at the train schedule? So the train will always wait 1 second before considering your 'ready to leave' signal.

General advice. Make a completely new game and save it as 'Sandbox', then use '/editor' and '/c game.player.force.research_all_technologies()' in console. Its better to have a separated game file when playing around with editor and working on blueprints and circuits.

Tertius
Filter Inserter
Filter Inserter
Posts: 903
Joined: Fri Mar 19, 2021 5:58 pm
Contact:

Re: logic system help: releasing train from station when "done"

Post by Tertius »

Every combinator outputs its result 1 tick after they got their input. So if you use 2 combinators in a sequence to determine the state of "unloading finished" signal, it takes 2 ticks to compute this state. Now, if the default state (without train) is "unloading finished" being active, then in the first 2 ticks after a train arrived at the station, the signal is still "unloading finished", so the train reads this, assumes unloading has finished, and leaves.
The most simple solution is to add a "inactivity 1s" to the schedule, so the train leaves if "unloading finished"=1 AND 1 second has elapsed. In this second, the signal stabilizes.

However, it's a more complex thing if seen as a whole. I guess you want to dynamically open or close the station. If you need items, you open the station (train limit=1), if all item requests are satisfied, you close the station (train limit=0 or L=0).

In this case, you need to recognize more states:
  • all requests are fulfilled:
    • set L=0
    • in case a train is at the station: train should leave
  • not all requests are fulfilled
    • set L=1
    • in case train is at the station:
      • train has finished unloading(*):
        train should leave
(*) "train has finished unloading" means "no items are being unloaded any more". It doesn't mean all requests were satisfied. In combination with "not all requests are fulfilled" means the train brought not enough items. It must leave, then load these items at the loading station, then come back.

I build an unloading station that tackles this problem. However, I don't do what you want: send the train away as soon as all requests are fulfilled, because while unloading, items might already be carried away and consumed, so it's wise to continue unloading until no items are taken away any more. Otherwise, the train needs to come here again immediately after it left. But this round trip could be avoided, if the train just stays as long as there are pending requests in the first place.

My approach works like this:
- subtract station inventory from item requests. If there are positive signals from this, items are missing and a train is called (L=1). This L could be used to send a train away, because the moment it switches to 0, all requests were satisfied and the train can leave. However, I don't do this, because the train is immediately called again as soon as an item is consumed while unloading.

- to avoid inserters stalling on items not present in the train, I compute MIN(train content, item requests) and unload this minimum. This way the inserters never try to unload more than is actually present on the train, so they never stall on nonexistent items.

My approach for an appropriate wait condition is just "inactivity 15 seconds". If there hasn't been any item unloaded for 15 seconds, I assume there is either no request any more, not even for immediate consumption, or the train is unable to satisfy all requests. In both cases the train has nothing to do here any more and can leave.

In case you want to see my solution, here:
11-10-2024, 15-40-19.png
11-10-2024, 15-40-19.png (707.95 KiB) Viewed 125 times
The trash and request logic is this: all unrequested items and all items with more than double the request are trashed. If there are trashed items, a train is called. A train is also called, if there are items less than half their corresponding request. For these, the two combinators with EACH*-2 exist.


This is the loading station, much more simple:
11-10-2024, 15-42-23.png
11-10-2024, 15-42-23.png (565.65 KiB) Viewed 125 times
Blueprint, including train to see the schedule: (the schedule+interrupts is a mess and needs improvement, but you see the waiting conditions at loading and unloading stations)
Loading station:
Unloading station:

Should both work, however I just ported the combinators from 1.1 and didn't yet test them on a real map, so may be there are usability issues.

Post Reply

Return to “Combinator Creations”