Logistic Network Loop Problem

[Impatient]

Hi devs, hi forum!

I have one Problem with the logistic network, that keeps bugging me:
I want to use the logistic network to distribute resources off belts to where they are needed (using a provider and a requester), but also to feed not needed resources back (eg from my inventory) into the belt system (using a requester). But this creates a belt-provider-requester-belt loop.

Example

A train is fueled by coal. An inserter and a requester chest is placed at the train stop. A provider chest is installed at the coal supply belts. The bots provide the train with coal. Fine.

Later on I am working on the coal supply belts. When finished I have 1k coal in my inventory, which I trash. The bots pick it up and put it into storage chests. And there it sits until the requester chest bit by bit pulls all the coal from the storage chests.

I think "meh, it would be better to feed it back into the coal supply belts. there it is of immediate use and does not clog up the storage space."so i place some requester chests at the coal supply belts to be able to put back a lot of items on the belts. Works great and the storage chests are all emptied of the coal.

But then the requester chests start pulling coal from the provider chest, from where it gets fed back on the same belt, it was taken of for the provider. And robots are fully occupied to do the supply runs.

I think "meh, this does not work. how can i make this work?" it can't be done! the only solution would be a requester that pulls from storage chests only."

So it seems I have no way to put the res back into the belt network, when they are also provided from the belt network without creating a loop. Am I right?

In https://www.factorio.com/blog/post/fff-203 I read about the buffer chest. But it seems, this also does not solve this problem, as it can pull from providers and requesters can pull from it.

So, how to solve this problem?

[Engimage]

There is such thing as Storage chest. This one will recieve everything you will trash from your inventory so you will not get any loop.
However the downside of this is that it can't request specific items so all kinds of items might end up being stored in the same chest.
However bots will try to put items in the same chest if ones are already stored there and will try to use new chests for the items that have not yet been stored anywhere.

Requester chests can request items from storage chests as well as passive providers so if passive provider lacks items they will be requested from storage chests. Not sure about priority (which one will be requested from first, storage or passive provider)

[rcp27]

Taking your coal example: feed a passive provider with coal. Tie the inserter to the logistics network and say operate if coal is less than 100 or whatever number. Take a constant combinator, set it to the same number but negative, -100 coal. Get a decider combinator and feed in on one colour a wire from a roboport reading the logistics network contents and the other colour feed the constant combinator. Output coal and wire that (separately) to the requester chest. Set the requester to request based on wire conditions. It will then only request however much is not in the passive provider.

[Krazykrl]

Since reqester chests pull in this order: Active Provider, Storage, Passive Provider. You can set up combinators to set your requester chest to do something like "Request all item X minus all item X in Passive Providers for item X." This would essentially set your requester chest to request all Actives and Storages ONLY.

Example:
Wire roboport to output logistic network contents.
Wire the roboport that outputs lognet contents to an arithmetic combinator, set to "Coal * 1 = Coal" (This is a filter to send ONLY a number of coal to your requester, if you omit this; you'll end up setting the chest to "Set Requests" with all contents of the lognet.)
Wire your passive provider to an arithmetic combinator, set to "Coal * -1 = Coal" (This is how much you will subtract from your lognet contents... this"filters out" the passive provider, and prevents the looping.)
Wire the outputs from both the Arithmetic Combinators to the requester chest, with the chest configured to "Set Requests". (The negative value of Coal in passives will be automatically added to the ammount read from the roboport)

[Engimage]

Since reqester chests pull in this order: Active Provider, Storage, Passive Provider.

If this is true then having a storage chest will just solve your issue just as you wish

[Krazykrl]

Since reqester chests pull in this order: Active Provider, Storage, Passive Provider.

If this is true then having a storage chest will just solve your issue just as you wish

No it won't. The only way to keep bots from looping items, is doing exactly what I explained above. If you do not limit the requester chest to ignore the number of items in the passive provider; the requester will deplete the Active/Storage, then still loop between the passive provider and requester (since the items are still available to be "pulled" from within the lognet.)

You need to setup some way to get the request count to zero, which exactly is what the combinators are for. If you don't somehow get zero request, you'll loop.

[DaveMcW]

I think "meh, it would be better to feed it back into the coal supply belts. there it is of immediate use and does not clog up the storage space."

The easiest solution is to build so much storage space that you don't have to worry about this anymore.

[Impatient]

Thanks for your davice Krazykrl. I am not good with the logic network. I will try it out though. And report back how it worked.

[Impatient]

Your solution worked beautifully!

I am using this no-loop provide & feedback all over my base already.

'Made a blueprint:

Blueprint

0eNrFmMtuozAUhl8l8mIWIxjhC7k9wEizm30VIQhuYg3YjG0yrSrefUxI0ySYYnvTTVMIfD7+zzk/h7yBomppIxnXYPsG2F5wBbZPb0CxA8+r/px+bSjYAqZpDSLA87o/qsSBKc328f5IlY6bXCl2onEjxYmVVIIuAoyX9AVsYRf50iT925rPOwxywCid7//EjCsq72/GDjfnkuljTc9RiLpgPNfilkG6XQQo10wzOkh0PnjNeFsXZrUtvKKkKEQjpDbwRihzg+D9sgYSox9pBF7NP/hHathGbi1FlRX0mJ+YWc9ctmdy3zKd1aKkmXjORENlPjCS4RZO9/2x6q+G/Z+DpJTfxsRKo1h0RfWHsNt1Xa/DQ9hoRoHRHpJhA+S8gZLJIRgjkH07H9TMfF2ya+TPTCqdjbJyYlK35sxHVs9XxP+OJl9gEMAkuq9Xo/iNOOC7uUe0umn9qZ2PsL2SEUD995KWj9/idEJofF27YIeYVmYtaaRuREXHIsP3OulltsBIYNbQ12ct/qK0pWFpS509b5zES6v7REksXRuBIu9zbolueY2OvjSSKhVrmXPVu09c0MpmQXiICt7XAbLAV/5w4gxf+8OhM3zjD0fOcJhMPXGmKgA99JwNCr1DdpcDIm944g7H3nD3EoTEG+6RyI/ermnJ2nrOldF7Om2wcSu2ZnKQBynM5+fNmNzHakgX/xt8EdiWW4V2/oMwSxt8Hdr5iVWaTSgOWicW9/67WAac7z8EQ/0omdcToVA/Shwix6Fwh0pAJNCWXFRJA9n2qgjpv+Tz9mN8ovvQKtBQHVwJrQP91CWd405UTcW0tXkuRfI4Mdq4OAl1I2wdlWGoYeB5fTEKjdXq+xj7upF9yyS0i+24dP7leio+5P9iCidGXMug/TDg3mbI8taKpl6mlqFy2ZO4CrQih8kOrwO9AjnU8sZzgkmmS4YkgRrgeQ0IDB+OiP9wRFCofxCrMsFPWDuOhI4aZN6JSRr8GCTej0GyDCyZ0UZ20fBz3Pbm98gIVLmBmHNPP3/tFr+H9+zFt8UzpeWiMF4bLbhYVEI05toTlWqAEYKWyxWCaNN1/wHclRhY

Blueprint description:
Provides a resource from a belt to the logistic network. Also feeds back this resource from the storage chests on to the belt, but not from the provider chest in this blueprint. Thus not causing a provider-requester loop.

Design usage:

• Install the Provide&Feedback at the end of your production line for this resource.
• Set the resource in the arithmetic combinators. In both combinators the input and output signal has to be set to the required resource.
• The passive provider chest in this design has to be the only provider of this resource in the whole logistic network (except you also wire up the others). If it isn't, the feedback requester chest will pull resources from the providers.
• The requester chest in this design has to be the only feedback requester chest for this resource in the logistic network. If there is more than one wired up, several feedback requester chests together, will request several times the amount of the resource present in the logistic network and thus also drain the resource providers. It should be possible to prevent this by dividing the requester chest input signal by the number of wired up requester chests.
• Other requester chests can be used to request this resource as normal.

Thanks again Krazykrl for your great and shiny simple solution. No more wasted resources clogging up my logistic networks.

[HurkWurk]

just to go over some basics for people on something i had trouble with early on. you almost never use active provider chests.

active provider chests are push chests. they want to be empty. 99% of the time, this is not what players want. they want passive provider chests.
passive provider chests just sit there and allow the logistic robots to take stuff. this is the behavior we normally expect when we want a chest to store things in that robots can get from.
storage chests are junk drawers. they are a mess and only really good for giving your robots a place to dump crap you dont know what to do with. like when you are away from your base and want to clear an area, drop a storage chest, then use a blueprint to clear everything, it all goes into the chest.

requester chests are how you provide sources for things. you set what they should store and the robots go find it and bring it. make sure you set them to store enough to account for robot travel times. otherwise your chests run dry before the robots keep up.

active provider chests have some small uses, mostly in circuit networks when you control their on/off states. for instance, people controlling the rate at which nuclear power plants use fuel. you can set network conditions to feed out fuel one at a time. (dont actually need an active provider chest for that, but it does the job)

[Bauer]

HurkWurk,
I fully agree. Active provider chests have very limited use.
I only use them for bot-based unloading stations to make sure that the inserters emptying the wagons are not blocked with full chests.

[Impatient]

active providers are useful to empty a chest full of "crap" I want out of my sight.

[MeduSalem]

Would be easier if there was a... Passive Requester Chest... one that only pulls from Passive Provider Chests.

[ili]

I use this setup
viewtopic.php?f=18&t=51904&p=303453#p303453

[Impatient]

very nice.

taht is effectively the same as Krazykrls solution I made the blueprint of. The advantage of Krazykrls solution is, that it only needs one roboport to be wired up, to get the contents of the log-net.