Inserter swinging before checking circuit signal

[pirusama]

I've brought up this somewhere else and I've been told that it is intentional, however this generates some problems where you need to add combinators just because the inserter swings one tick before checking a signal.
https://streamable.com/28yty6

A simple setup would be an inserter checking for an arriving train signal from its station before inserting. As you can see in the video, it just swings before the signal gets to it. I wouldn't want to filter the whole wagon just because of it.
The same thing happens in chests. Although not as common, I still ran into this issue when trying a kovarex setup.

When the inserter is connected with to a network, would spending one tick checking if there's a signal after the inserter finds a storage (train) or before it grabs an item from a chest slow it down too much?

[ssilk]

Hm.
Basically, the inserter swings in the tick, when the train arrives, but the signals from the station needs one tick more. To suppress this behavior you need to change the logic: the inserter doesn’t swing by default (is locked, or filter empty), and is only unlocked, when a train signal has been somehow computed.

I admit I don’t quite understand the problem(s) — it is not possible to see what’s happening in the video, it’s too fast — and what your requested behavior should be (how should it work? It cannot lock into future!), but I can say, this reversed logic trick is valid for any of this problems. In other words: this works perfect, but you need to do it right, by not letting the inserter do, what it wants.

So there will be no special rule to wait an extra tick if the target is a wagon, because if you put an combinator into this line from train stop to the inserter you suddenly need to wait two ticks and another gamer comes and makes a suggestion to add one more tick. and it would break many already existing factories.

Moving to won’t implement…

[Pence128]

The circuit network changes first. The inserter grabs items a tick later.

You can replicate this with a chest and an inserter controlled by a constant combinator. Pause, turn off the constant combinator, then step one tick. The signal is gone from the network. Put items in the chest and step another tick. The inserter shows "disabled by control behavior" but it still grabs items.

[FuryoftheStars]

I admit I don’t quite understand the problem(s) — it is not possible to see what’s happening in the video, it’s too fast

Yeah, I had to watch it a few times to see what was going on, but it's basically this:

• First scenario with the train, the inserter is set to be enabled when the control signal is landmines < 100. The train that rolls up already has 100 mines on it, but as the signal from the station arrives 1 tick later, it still inserts 1 stack of 3 landmines into the train.
• Second scenario, the inserter is set to be enabled when the control signal is red wire < 50. The OP then places a stack of 200 into the chest, but again, because the signal arrives 1 tick later, the inserter still pulls a stack of 3 out.

I think this happens because of the way a nil signal is processed.

Edit: I believe the correct solution here is not to change the way inserters process control signals, but rather to use combinators between the train stop and the inserter and change the inserter enable logic. Change the inserter to enable on a signal (pick one, any one) = 2. Then use 2 decider combinators: one checks for signal from stopped train (default T) > 0 and outputs the inserter's enable signal = 1. The other combinator checks for the condition you want (in the case of the above video, landmines < 100) and outputs the inserter's enable signal = 1. (Oh, and use the same colored wires for the outputs so they combine.) When a train is present, and the number of landmines is < 100, the combined inserter's enable signal will = 2. (It should be noted that stack size can still cause it to overload if not = 1, or you set the combinator check condition to take stack size into account and you're ok with sometimes having up to [stack size] - 1 less landmines.)

I (personally) can't think of a good solution for the second scenario (I'm not that great with circuit networks), but I'm also failing to think of a use situation where you'd want an inserter pulling from a chest only when its contents are below a certain threshold.

[ssilk]

I think this is much simpler: Just put another combinator into the signal path to slow down the signal by one tick.

[FuryoftheStars]

I think this is much simpler: Just put another combinator into the signal path to slow down the signal by one tick.

Actually, I don’t think that will help at all. If you’ll note, while there is nothing (train not present/chest empty), the inserter is in an enabled state (for a specific check, a nil signal is seen as quantity 0 for that check). You need something that will change the inserter to disabled while there is nothing present.

[robot256]

Train stop read contents and stopped train --> Contant Landmine=-1000 --> Combinator IF T>0 then pass Landmine input count --> Inserter enable if Landmine<0

[Pence128]

Tick 1

Tick 2

Tick 3

Don't worry OP, I believe you.

[mrvn]

As said, the circuit signal needs time to propagate. That includes the control behavior of inserters. They only disable in the tick after the signal changed.

Just use the suggested solution to have the inserter disabled per default so it doesn't start working before the signal has propagated.

[Pence128]

They only disable in the tick after the signal changed.

That is in the tick after the signal changed.

[FuryoftheStars]

They only disable in the tick after the signal changed.

That is in the tick after the signal changed.

The train station signal changes, but the signal does not change at the inserter until 1 tick later. This is the way the circuit network works for everything. The actual signal is not passed to the next set of entities on the wire until the following tick. As such, the inserter is grabbing items from the chest on the same tick as the signal to it changes and has to finish its operation before it can disable. This is why we've been saying that you would need to change the logic you're operating by to have the inserter disabled by default, then only enable it once needed.

[Pence128]

The train station signal changes, but the signal does not change at the inserter until 1 tick later.

That is the signal at the inserter.

[FuryoftheStars]

Apologies, yes, the signal is “at” the inserter at tick 2, however the inserter will not process it until the following tick. This is how all entities work and I’m pretty sure it was deliberate. If all entities processed their signals on the same tick as they received them, I can see loops creating a lock up situation.

[mrvn]

The train station signal changes, but the signal does not change at the inserter until 1 tick later.

That is the signal at the inserter.

Tick 1: the train arrives, the train stop sets the output, the inserter starts swinging.
Tick 2: the inserters controller processes the signal and disables the inserter for the next swing

It's the same with combinators. Every entity adds 1 tick delay.

Think of it this way: Every entity has a little memory cell, a latch, that stores the circuit signal at the beginning of the tick. That stored value is then used to update each entity and compute the signal output and that is what you see when you mouse over. What you see is going to be the input for the next tick, not what the entity reacted to this tick.

[FuryoftheStars]

The train station signal changes, but the signal does not change at the inserter until 1 tick later.

That is the signal at the inserter.

Tick 1: the train arrives, the train stop sets the output, the inserter starts swinging.
Tick 2: the inserters controller processes the signal and disables the inserter for the next swing

Did you mean ticks 2 & 3? Tick 1 the train hasn’t fully arrived yet, or at least the station hasn’t set the signal.

[Pence128]

Apologies, yes, the signal is “at” the inserter at tick 2, however the inserter will not process it until the following tick. This is how all entities work and I’m pretty sure it was deliberate. If all entities processed their signals on the same tick as they received them, I can see loops creating a lock up situation.

Yes. It should be disabled in tick three. But it picks up items in tick three. Evidently the Inserter swings before checking [the] circuit signal.

edit: BBCode strikes again

[FuryoftheStars]

Apologies, yes, the signal is “at” the inserter at tick 2, however the inserter will not process it until the following tick. This is how all entities work and I’m pretty sure it was deliberate. If all entities processed their signals on the same tick as they received them, I can see loops creating a lock up situation.

Yes. It should be disabled in tick three. But it picks up items in tick three. Evidently the Inserter swings before checking [the] circuit signal.

Actually, the inserter has already started the process of swinging in tick 2. You just see the results of it in 3.

[Pence128]

Actually, the inserter has already started the process of swinging in tick 2. You just see the results of it in 3.

You can remove the items from the chest after tick 2, then the inserter doesn't swing. It definitely doesn't have them yet.

As far as I can tell in tick 2 the inserter decides that it's going to try to swing in tick 3, circuit network be damned. It's only really disabled for tick 4. Maybe this is to preserve the 1 pulse = 1 swing functionality that everyone depends on.

[mmmPI]

As far as I can tell in tick 2 the inserter decides that it's going to try to swing in tick 3, circuit network be damned. It's only really disabled for tick 4. Maybe this is to preserve the 1 pulse = 1 swing functionality that everyone depends on.

I think this is a closer depiction to what happens than " inserter swinging before checking signal". It would be "inserter swinging AFTER checking signal".

With the counter-intuitive addition of train logic.

In my mind it makes sense to consider a tick as a duration. Then you have the start of the tick, as an edge, and the end of the tick, those are not duration.

A train arrive during a tick. [Tick 0]

At the end of the tick the game prepare a list of the inserters that are loading/unloading on this train to activate next tick. ( this is like the total of changes occuring during the tick, it need to be computed "at the end of the tick".)

At the beginning of the next tick, those inserters are awake, and the train station start output a signal. [tick 1]

During this tick 1 the inserter has not yet received the signal from the station like the train content, but it already knows there is a train that's why it's written "waiting for source item" and not "waiting for a train" anymore. This is counter intuitive i think because the tooltip has a red dot associated with the state of the inserter, while at the same time the little lamp at the circuit connection on the inserter is green. During this step you can read the train content on the circuit network, but the inserter hasn't processed it yet. Instead the inserter still holds the previous tick value of circuit network, with 0 landmines in your example, 0<100 for the inserter.

At the end of this [tick1] the game prepare a list of the inserters that enable/disable the following tick based on the signal that was received during this tick. The inserters think it has all good reason to grab something next tick because during the whole tick it had 2 ok condition, 1)a train 2) nothing yet in the circuit network. maybe here the inserter does a mistake because it WILL grab something next tick. Despite the circuit counter order.


Now begining of [tick 2] The inserter grabs something in the chest, because there was a train incoming previous tick and no circuit counter-order yet. And gets disabled for the rest of the duration of the tick due to circuit. So it's again a bit counter-intuive because the little lamp on the inserter has become red during this tick but the inserter just grabbed something. The lamp color "lag behind". by 1 tick to the real behavior. This is because circuit value changing during a tick only apply the following tick. So the lamp is now showing red, but the inserter has grabbed something.

Next tick the inserter is disabled by circuit still the lamp is red. But in the screenshot example the inserter grabbing from a chest to a wagon only require 1 pulse of activation to generate a full swing. The item being grabbed the tick AFTER the activation was received, and the full swing being ordered will complete even if you cut power . The item was grabbed at the begining of the previous tick, so the swing will now complete.

The train logic is the counterintuive part because it's "faster" than the circuit one (imo) i think it is a special that can reasonnably induce the misunderstanding.

1tick delay.png (735.67 KiB) Viewed 5410 times

On this little test setup you can see that the inserter on the left side "shouldn't" grab anything. right ? deactivate as soon as there is a train ? but really it's deactivating as soon as there is a signal T, the inserter seing the train for a train faster than the inserter is seing the train from the signal T.

The other inserter on the right side can't see the train for a train, it only sees the signal T. This is why it lags behing by 1 tick. It is now activated ( on the screenshot), but it didn't have the time to grab concrete, it will do so only the following tick. ( Hence why i started saying the inserter swing AFTER checking signal).

The 1rst inserter on the left side has already some concrete in hand, due to seeing the train the previous tick, without receiving counter-order ( during the previous tick only at the end !). It is now deactivated by circuit, but it's too late it started the tick by grabbing something as the result of the previous tick.

In other word " the signal T condition" triggers at the same time for both inserters, causing them to react 1 tick later. But the inserter on the left side has a different behavior than the one on the right side due to being next to a rail and able to interact directly with the train.

[FuryoftheStars]

Actually, the inserter has already started the process of swinging in tick 2. You just see the results of it in 3.

You can remove the items from the chest after tick 2, then the inserter doesn't swing. It definitely doesn't have them yet.

As far as I can tell in tick 2 the inserter decides that it's going to try to swing in tick 3, circuit network be damned. It's only really disabled for tick 4. Maybe this is to preserve the 1 pulse = 1 swing functionality that everyone depends on.

Yes, I’m considering the decision to swing as part of the swinging action.

Think about it: an inserter checks every tick if it has valid conditions to swing or not. In tick 2 it has that: destination present and is in enable state. It sets itself to a valid state and the next tick it performs the actions even after the signal processes to disable. Why? Because the circuit is setup to allow this. In a scenario where the inserters are disabled by default, you can enable them for a full swing with a single pulse from a belt vs holding a signal on it for x ticks. Makes it easier so you don’t have to setup your own timer/latch in combinators for each simple operation.

Your removing the items from the chest before it can pick them up is no different than how competing inserters on the same chest/belt/whatever works.