Flickering signal need explanation

[mmmPI]

freeclock.gif (5.36 MiB) Viewed 3687 times

What is going on ?

1) Why the flicker ?
2) Why only 1/2 flicker not 2/2 ?
3) Why 3/4 flicker at the end not 2/4 or 4/4 ?

this the settings

anynotnull 37.png (344.29 KiB) Viewed 3687 times

The only thing i did was to place and remove rails several times on a flickering setup, and one time after some attempts one of them became stable.
This creates weird repathing for trains when you use this settings for signals on a real railtrack.

[ATAD]

I tested this, and repeated your results of the "flicker". I used tracks on my test, so they won't be in the flashing green/yellow/red "error" state.

My guess about what's happening is that it's causing an endless loop on the circuit network; the signal sends "green: 1", which matches "anything" which causes the signal itself to become closed. When it becomes closed, it no longer broadcasts green, so it becomes "open" (for a lack of a better word...) again, then the cycle repeats with it broadcasting green again since it's no longer "closed".

You can also see this by changing the "close condition" to "Green does not equal 0" (with other defaults set), or change "read signal: green" to output signal "A" or something, and then close when "A does not equal 0" for the same effect.

[mmmPI]

My guess about what's happening is that it's causing an endless loop on the circuit network; the signal sends "green: 1", which matches "anything" which causes the signal itself to become closed. When it becomes closed, it no longer broadcasts green, so it becomes "open" (for a lack of a better word...) again, then the cycle repeats with it broadcasting green again since it's no longer "closed".

I wasn't expecting this behavior only with a rail signal and a wire, i would use an combinator to create those loop usually because i expect the signal to be transmitted discretly tick by tick when there is a logic operation, not just going through wire, i am surprised.

This still can't fully explain the example where it is stable, signal is a continous 1green, it shouldn't stay this way, it should lauch said loop, 1green means not anything is null, so the signal should close.

Maybe at some point it has gone into a different state, such as "being green because the block is empty", and not "being green because of circuit control", which is something that happens when the signal is red, that's for sure

This act as memory.

You can also see this by changing the "close condition" to "Green does not equal 0" (with other defaults set), or change "read signal: green" to output signal "A" or something, and then close when "A does not equal 0" for the same effect.

I need to try those. I was thinking about telling the railsignal to output "green" when it close, and "red" when it open, to create such loop, now this one happens easily just by ticking all the boxes

[disentius]

I suspect this has something to do with it:

2019-08-11 13_23_17-Rail signal - Factorio Wiki.png (10.81 KiB) Viewed 3650 times

https://wiki.factorio.com/Rail_signal

[mmmPI]

After further testing it does behave like the loop described, and doesn't function when the signal is turned off.

I still don't understand why the behavior happens with only a signal and a wire

The signal propagated in the wire is the signal that is emitted when the rail signal is open.

I don't know why you can also have this stable state when you play with rails near the signal. It appears that you can't make the signal stable if you place a rail. It only happens when you remove the rails that touches the signal. ( less than 50% of time, but maybe i just felt unlucky).

You can reproduce the stable state by sending a green signal with value 1 with a constant combinator.

This way when you turn it on, you have a continous green signal. When you turn it off you have a flickering signal 1 tick on/ 1 tick off.

Only a moving train can pass such signal. If you don't have initial velocity, the signal never turns yellow ( which breaks temporarily the loop). If the signal never turns yellow, it is only open during maximum 1 tick. Which is too slow for the trainpathfinding to allow a train to start moving, should he be stationned just next to the signal.

If the train is moving fast, there is chance/risk of instantaneous decrease in velocity when passing such signals.

This means if you place several too close to each other, any train will come to a stop at some point.

I have not more ideas for using this than as a weird memory cell.

[DerGraue]

The flickering is easily explained and exactly how I would think it should behave.

For that to understand you have to understand that
a) signals are transmitted instantly along the whole wire network
and b) afaik all entities need one tick to process incoming signals

So a combinator receiving a signal will output with one tick delay
An inserter receiving an enabling signal at tick 1 will only activate at tick 2

And the same goes for the train signals.

So if we look at the train signal:

Tick 1: the train signal is green, so it sends out the signal "green = 1" to the power pole
still tick 1: all entities connected to the wire receive the signal "green =1", this includes the train signal itself
(note that this works with everything, you can connect the train signal to a belt, a chest, an inserter or whatever, it just needs the wire so that it can send and receive the signal)

Tick 2: it has now processed the signal, "any != 1", it means that it disables
-> it does not send "green = 1" because it is disabled and apparently does not send a disabled signal, see the poste above
still tick 2: it does not receive any signal

-> Tick 3: since it did not receive any signals the previous tick, the train signal enables again, the same thing happens like in tick 1
-> repeat


However, I do not know why sometimes this stable state can be reached and I could reproduce that sometimes, but now always.

[disentius]

tested in edit mode.
Root cause: being able to place signal in undefined state, AND that same signal transmitting a green 1 to the circuit network.

It should be a bug report (signals should not transmit green state to circuit network when in undefined state)
Or a feature request(signals in undefined/illegal state should not transmit green state to circuit network)

Go Willie! (gratuitous reference to 80's comedy show)