LTN overrequests for certain stops, and jams production

[danbopes]

I'm a little lost right now. I cannot seem to understand how my large warehouse is filling up with steel and blocking input for plastic.

This is the setup:



The green wire is hooked to the 24 steel chests at the top, and connected down to the warehouse, as well as connected to the LTN input (I've verified that it's not crossing with the output, nor any other wires (Like the big power poles). The red wire (Output) is hooked up to the LTN output, and controls set filter for the unloaders.

My constant combinator:



I've even verified that this stop doesn't share the same name as any others (To prevent potential issues if I remove another stop with the same name, it may reroute the shipment). All of my steel loaders respect how much is requested, although even if they didn't, with 160 stacks as the requestor limit, this shouldn't be an issue. All of my steel providers have 160 stack requirement for providing as well.

I just cannot for the life of me figure out how this can get jammed! With these settings, do you see any possibility for a jam? What else should I look for?

[danbopes]

This is still happening, with some of my other stations as well. This one is another recent one:



My stop circuit conditions:



Attached is a grepped version of the ltn-log, for this specific station. If you need additional debug lines +/-, let me know and I can regrep the file.

The current input (Before I cleaned the station again):

[mmmPI]

I would place a speaker that ring when the quantity in a warehouse is higher than what it should be. Then when things ring, look at what is happening at the very moment there is excess material detected but given the screenshot, the size of the base may not be adapted for this method. It may indicate something else if the problem is occuring now but wasn't during the earlier phase, something like a change in the blueprint used ? new material having new stack quantity interfering with the amount of belts between the unload area and the warehouse ?

Those may not the best way to debug the issue tough

[danbopes]

So after talking to the folks in the space exploration discord, we found out that I was setting my request thresholds to a negative value. But the thresholds should be set to a positive threshold as that's the "missing" or requested amount. My guess is in most places Optera is taking this into account, but maybe missed it in a few minor places which lead to this bug. After setting this to a positive number, this seemed to have fixed it (Still testing though).

I wrote a script to quickly run through and fix it:

Code: Select all

/c local surface=game.player.surface
local updatedSignals = 0
for key, entity in pairs(surface.find_entities_filtered({name="constant-combinator"})) do
    local behavior = entity.get_control_behavior()
    
    if behavior ~= nil then
        for i=1,20 do
            local signal = behavior.get_signal(i)
    
            if signal ~= nil and signal.signal ~= nil then
                if (signal.signal.name == "ltn-requester-stack-threshold" or signal.signal.name == "ltn-requester-threshold") and signal.count < 0 then
                    behavior.set_signal(i, {
                        signal={
                            type=signal.signal.type,
                            name=signal.signal.name
                        },
                        count=math.abs(signal.count)
                    })
                    updatedSignals = updatedSignals + 1
                end
            end
        end
    end
end

game.player.print("Updated entities: " .. updatedSignals)

[robot256]

Normally Request Threshold is set to the size of a single train, to ensure you only schedule a train when it has space to unload. (Stack Request Threshold is even more useful for this.) It never even occurred to me to set it negative. LTN should probably treat negative numbers as 0.

[danbopes]

Normally Request Threshold is set to the size of a single train, to ensure you only schedule a train when it has space to unload.

I had assumed that, when the threshold met the amount (ie. when the output signal reached -32k), that's when it would trigger the amount. My thinking "-32k == -32k" trigger a delivery. Not "32k missing", which lead to me choosing a negative number.

[Optera]

Sounds to me like you don't feed the warehouse content to LTN input.
What's the station name of your warehouse so I can search the log?

Normally Request Threshold is set to the size of a single train, to ensure you only schedule a train when it has space to unload. (Stack Request Threshold is even more useful for this.) It never even occurred to me to set it negative. LTN should probably treat negative numbers as 0.

Allowing positive request thresholds is a legacy feature.
Internally requests are absolute values and don't differentiate between positive and negative.

[danbopes]

I do feed the warehouses, and the chests unloading both to the warehouse (Through the green signal in my screenshot).

I've given up. LTN occasionally overrequests and gets too much. IDK if it's from the time that some of the stuff is on the belt before it reloads and the signal gets readded back into the warehouse, but it's much more (In most cases > 50k over), which is well more than the belts can hold.

I've just simply added an "overload" detector to simply just empty out the warehouses into an active provider chest, which happens rarely. It's about the only thing I can do at this point to keep my sanity:

[robot256]

You could wire up all the belts and even inserters to add their contents to the LTN inventory count ("hold" mode on belts). But the best solution is probably to reduce the request threshold so there is some empty buffer space in the warehouse at all times, to accommodate the overload if it happens.

[Optera]

I do feed the warehouses, and the chests unloading both to the warehouse (Through the green signal in my screenshot).

I've given up. LTN occasionally overrequests and gets too much. IDK if it's from the time that some of the stuff is on the belt before it reloads and the signal gets readded back into the warehouse, but it's much more (In most cases > 50k over), which is well more than the belts can hold.

I've just simply added an "overload" detector to simply just empty out the warehouses into an active provider chest, which happens rarely. It's about the only thing I can do at this point to keep my sanity:

Sounds like belt latency is messing with you.
I'd hook only the unloading chests to LTN and ignore the warehouse(s).

[danbopes]

Can you explain what belt latency is?

I measured my longest belt with items on it. Even 355 x 4 belts, would be about ~ 1200 items. One full load is 160 stacks, so that would be 32000 chips. I don't see how LTN could request a full load and bring my LTN signal > 10k.



In order for these warehouses to jam, I'd need 102k chips in one warehouse. This HAS happened, although rarely, but IDK.


When I have some free time, I'll try to create a debug map, and pump the speed up to see if I can repro it in a controlled environment. IDK if Space Exploration, switching planets or moving into a different nav view while LTN is trying to balance signals or something is possibly throwing it off, but it's weird.

[Optera]

Sry for late replay, I hardly check the Forums these days.

Can you explain what belt latency is?

I measured my longest belt with items on it. Even 355 x 4 belts, would be about ~ 1200 items. One full load is 160 stacks, so that would be 32000 chips. I don't see how LTN could request a full load and bring my LTN signal > 10k.

That's what I mean by belt latency, items "stored" on belts.

When I have some free time, I'll try to create a debug map, and pump the speed up to see if I can repro it in a controlled environment. IDK if Space Exploration, switching planets or moving into a different nav view while LTN is trying to balance signals or something is possibly throwing it off, but it's weird.

I think it's a station design flaw. If you still have problems, post the entire station blueprint and I'll look over it.

LTN operates across all surfaces.
Switching planets in Space Exploration, going inside Factorissimo Warehouses, asf has no effect on it.