Confusion about requester station design

Adds new train stops forming a highly configurable logistic network.

Moderator: Optera

Post Reply
alienwombat
Burner Inserter
Burner Inserter
Posts: 15
Joined: Sun Dec 10, 2017 9:03 pm
Contact:

Confusion about requester station design

Post by alienwombat »

I'm slightly confused about the requester design shown here.

I think i understand what it's supposed to do, but let's make sure i really get it: The LTN output gives the expected train content after unloading. This is subtracted from the current train content and sent to the filter inserters. So they only unload until the current content matches the expected content. Please correct me if i got that wrong.

Now my real question is why this is required. Is it only a for safety to prevent contamination, if something goes wrong during the loading? Or is there any "normal" scenario where the train would not fully unload at the requester station?

User avatar
Optera
Smart Inserter
Smart Inserter
Posts: 2915
Joined: Sat Jun 11, 2016 6:41 am
Contact:

Re: Confusion about requester station design

Post by Optera »

You are right, requester wouldn't necessarily require being smart. It's just nicer this way.

There's also an design to prevent the read inventory signal triggering one inserter cycle: viewtopic.php?f=214&t=56270#p331603
Thanks for reminding me to add this version to the guide.

alienwombat
Burner Inserter
Burner Inserter
Posts: 15
Joined: Sun Dec 10, 2017 9:03 pm
Contact:

Re: Confusion about requester station design

Post by alienwombat »

Glad to hear i understood that right. I think i will skip that smart part in my stations, since i'm currently playing with bobs mods which has 5 different locomotives and cargo wagons, making that circuit to fix the delay a bit too large for my liking.

One more question that popped up thinking about this: how, when and where is the "expected train content after unloading" signal generated? Does the requester LTN stop know whats supposed to be on the train and output what it didn't expect? Or does the provider LTN stop check for contamination when the train leaves?

User avatar
Optera
Smart Inserter
Smart Inserter
Posts: 2915
Joined: Sat Jun 11, 2016 6:41 am
Contact:

Re: Confusion about requester station design

Post by Optera »

Expected inventory is everything in a trains inventory not set to = 0 in the train schedule.

alienwombat
Burner Inserter
Burner Inserter
Posts: 15
Joined: Sun Dec 10, 2017 9:03 pm
Contact:

Re: Confusion about requester station design

Post by alienwombat »

That' actually a quite nice solution! I was wondering how the slight overloading that's usually expected was handled.

One more question about smart unloading with the 5 different trains and wagons in bobs mods: If i want to use the design you linked to fix the delay problem on the LTN output, i have to combine all the different "encoded position of bobs locomotive xyz" into a single signal. That is a bit clunky. Can i just use the "locomotive detected" signal from inventory sensor instead? I.e. is the "locomotive detected" signal always slower than the "expected cargo" signal from the LTN output?

User avatar
Optera
Smart Inserter
Smart Inserter
Posts: 2915
Joined: Sat Jun 11, 2016 6:41 am
Contact:

Re: Confusion about requester station design

Post by Optera »

IS and LTN run at different cycles, one IS may polled before while the next is polled after LTN.

Merging signals only costs 1 arithmetic combinator for 2 additional signals. Enc. Pos. Locomotive 1 + Enc. Pos. Locomotive 2 = Enc. Pos. Locomotive

mrvn
Smart Inserter
Smart Inserter
Posts: 5682
Joined: Mon Sep 05, 2016 9:10 am
Contact:

Re: Confusion about requester station design

Post by mrvn »

If the station only allows one kind of train setup (e.g. LCC or LCCCCL) and doesn't overlap with any other station then you don't need to programm the inserters for unloading at all.

If you have trains with locomotives at different positions then you need some smarts so you don't unload the fuel from the locomotive. Imho it's easier to make all trains of the same length the same and to make two headed trains always palindrom.

If you have overlapping stations then again you need some smarts to prevent unloading the wrong thing. But you can simply use the train present signal, no combinator required.

User avatar
steinio
Smart Inserter
Smart Inserter
Posts: 2632
Joined: Sat Mar 12, 2016 4:19 pm
Contact:

Re: Confusion about requester station design

Post by steinio »

Unloading fuel from locomotives with inserters is not possible any more.
Image

Transport Belt Repair Man

View unread Posts

alienwombat
Burner Inserter
Burner Inserter
Posts: 15
Joined: Sun Dec 10, 2017 9:03 pm
Contact:

Re: Confusion about requester station design

Post by alienwombat »

I think i have (hopefully) found a quite compact solution for using the "output delay fix" circuitry, even if there are tons of modded trains. It should also be forward compatible if more train trains are added:

This is the standard circuit:
4890656.png
4890656.png (215.03 KiB) Viewed 4520 times
The left decider "waits" until it sees the encoded locomotive signal, and then passes it's inputs to the inserters.

This is what i propose:
4890919.png
4890919.png (217.79 KiB) Viewed 4520 times
The extra decider in the middle is set to: Anything /= 0 -> 1 green (square) signal.
The left decider now "waits" until green (square) signal /= 0.
I think it does the same thing as the standard circuit: the inserters won't get any signal until the LTN output is valid, including the delay of the right arithmetic combinator.

I'd be happy for any feedback! I haven't tested it yet, since i don't have have a suitable test map available right now.

User avatar
Optera
Smart Inserter
Smart Inserter
Posts: 2915
Joined: Sat Jun 11, 2016 6:41 am
Contact:

Re: Confusion about requester station design

Post by Optera »

That should work. I prefer using as few combinators as possible though. Each one adds a tiny bit to entity update.


Another option would be checking the lamp color. This method has some limitations though:
- lamp color can only be read through green wire from the hidden constant combinator under the lamp
- requires signal separation either through wiring or a 3 combinator build
- lamp color probably is updated the same tick as output, but I can't guarantee it

mrvn
Smart Inserter
Smart Inserter
Posts: 5682
Joined: Mon Sep 05, 2016 9:10 am
Contact:

Re: Confusion about requester station design

Post by mrvn »

alienwombat wrote:I think i have (hopefully) found a quite compact solution for using the "output delay fix" circuitry, even if there are tons of modded trains. It should also be forward compatible if more train trains are added:

This is the standard circuit:
4890656.png
The left decider "waits" until it sees the encoded locomotive signal, and then passes it's inputs to the inserters.

This is what i propose:
4890919.png
The extra decider in the middle is set to: Anything /= 0 -> 1 green (square) signal.
The left decider now "waits" until green (square) signal /= 0.
I think it does the same thing as the standard circuit: the inserters won't get any signal until the LTN output is valid, including the delay of the right arithmetic combinator.

I'd be happy for any feedback! I haven't tested it yet, since i don't have have a suitable test map available right now.
Using my posted patch to report items to be unloaded you can multiply the yellow constant provided by -1 and use that to set filter.

Post Reply

Return to “Logistic Train Network”