How to read Cargo Bot/Requester Chest Contents

[FactorioAAA]

How can I "read" cargo bot contents/requester chest contents or design a system that accounts for it.

Hello, I have run into a problem whilst designing a system to automatically craft different items. The system checks to see if an item can be crafted. It does this by looking at the Logistic storage network, being read from a roboport. If the item in question can be crafted (enough ingredients exist in the network to craft the desired number of whatever item), the system then sends a signal to set the crafting targets of a group of assemblers and the requests of requester chests. However, roboports/logistic storage only keeps track of items in buffer, storage, and passive provider chests with items carried by logistic robots, or scheduled to be carried counting against the logistic storage count. This causes the system to cancel the crafting of certain items shortly after the request, due to "thinking" there isn't enough materials once the request is sent. Cancellation is caused by an assembler cell detecting that the "logistic network storage" doesn't have enough stock to craft even a single desired item. This causes a lot of unnecessary movement of items/bots as the bots don't cancel their movement if a requester chest's request is cancelled. There is a "simple" solution of simply increasing the number/quota of materials to keep in stock, so once once logistic robots start taking things, there is still "enough" in storage to not trigger cancellation. However, this increases the number of resource I have to have "on hand" at any time, especially when looking at making quality products. As well as not preventing the problem from occurring, whilst the machine works towards reaching quota. For example one cell may be making batteries and the system sees that it can craft laser turrets, but as soon as it sets a cell to start crafting them, it reads the network and notices the number of batteries in the system has gone to 0, cancelling the laser turrets from being crafted, once cancelled eventually ingredients return to storage and the system detects it can craft laser turrets, and the cycle repeats until eventually resolving.

Sorry if this is overly confusing, this is the first roadblock on this multi-month long project I am unable to think of a reasonable solution to in a reasonable amount of time.

[Tertius]

Unfortunately, it's not possible to read what is being carried by bots. Items simply vanish while a robot is carrying them.
And it's not possible to read the items that are about to be delivered to a chest.

So it's exactly how you describe it. As soon as an ingredient is reserved for pickup from a logistics chest by a bot, it vanishes. It reappears when it has been delivered to a chest.

How about this approach (untested, just an idea):

1. One circuit contraption to order ingredients
   1. read roboport to get logistics network inventory
   2. check if there are enough ingredients to craft some recipe. Filter these ingredients from the roboport list, ignore the recipe.
   3. request these ingredients by a requester chest. DON'T set the requester chest to trash unrequested items.
2. Another circuit contraption to operate assembling machine
   1. unconditionally move all items from the requester chest to an ordinary chest in front of the assembling machine.
   2. Read the content of the ordinary chest and the hand content (hold mode) of the inserter that's moving items from that chest to the assembler and read the content of the assembler (just content, not ingredients and not items currently being crafted). Chaining the 2 chests is required, because we're not able to read the content the requester chest if it is set to "set requests".
   3. check which recipe can be crafted from the ingredients we just read
   4. set the recipe in the assembler
   5. watch how the items are being moved and the assembler starts crafting

This approach checks 2 times independently from each other if there are enough ingredients for some recipe. One time it gets the corresponding ingredients, the other time it gets the corresponding recipe. You need 2 separate circuits for this, since they're independent from each other and can result in different output. Reading the inserter hand in hold mode and assembler content ensures the recipe will stick until the assembler actually starts crafting.

Over time, the requester chest will accumulate 1-3 rogue items of each type that were requested in the past. This is due to robots bringing always 4 items in a batch, even if just 1 item was requested, and we cannot trash unrequested items, since the request vanishes as soon as the item was picked up for delivery by a robot.

If the machine has a productivity bonus, you might want to add logic to ensure you don't start crafting for a single item but only for enough ones to not waste the productivity that accumulates while crafting.

[SirSmuggler]

You could probobly set up some kind of latch system where the crafting request is locked in once enough material is detected and then the state is not released untill the craft is compleated, regardless of what happens with the content of the logistic system.

[FactorioAAA]

For anyone who runs into this problem in the future. I went with the idea of using a latch system. Once a recipe is sent to requester chests another combinators starts counting to 1200 and only when the number of working machines = 0 and the count is >= 1200 (and we dont have enough resources) will the cancellation trigger.

Thank you everyone.