Automation timing unreliable?

[biopon]

We were talking about a signal multipexer on the discord and I built a ****ty proof of concept. ****ty because it's super naive, but also because it falls apart after 1 or 2 loops.

Without going into much detail, it uses 8 clocks, 4 on each side, to determine the timeslice given to the signal itself.

The clocks are comprised of a filter (lead-in time to let preceeding clocks do their thing), a buffer (the actual timeslice) and another buffer (the lead-out time to let following clocks do their thing). The final buffer goes into a NOT gate that starts the filter - and the cycle - over. The filter, buffer, buffer timings are 1, 1, 4 then 2, 1, 3 then 3, 1, 2 then 4, 1, 1. Each clock should take 6 seconds to loop and then start over, but they're very inconsistent.

The clocks are synchronized with a switch, one on each side, that I throw while the game is paused. I would use a single switch wired to both sides if it mattered, but the clock drift appears very quickly within one side, that was synchronized with ONE wire a few moments ago.

(I know a cleaner version would use just one, larger clock per side, but it's a moot improvement if timings are unreliable as the 2 sides would still have to be in sync.)

Has anyone seen this? Is there maybe a workaround?

[Neotuck]

Difficult to see what you are trying to make here without a video or gif, the automation is too complex for me

but I do know automation tend to delay when they are off screen, this is most noticeable when automating bunker doors across the whole surface 

[biopon]

It's meant to use one wire to transmit (albeit with a few seconds delay) 4 different inputs to their respective outputs. It's just a (dis)proof of concept that I and a few others were discussing that fell flat on a surprisingly trivial detail.

The idea is that clocks determine which input is considered active for the multiplexed line. To achieve this the input is AND-ed together with the corresponding clock's active signal (the middle 1-second buffer gate in each clock) and then implicitly OR-ed with the other 3 input/buffer pairs on the same side. Since only one middle buffer gate is (supposed to be) active on one side at a time, performing the reverse of this process on the other side gives you the correct signal out of the possible 4.

The middle buffer is preceded by a filter and followed by another buffer, and their values all add up to 6, which is one cycle for the contraption, and also the maximum delay a signal is experiencing on the multiplexed line.

The problem is that the 4 clocks on the left side (and possibly on the right) go out of sync with each other in about 30 seconds, essentially sending garbage on the line.

I have seen my bunker doors screw up from time to time and was vaguely aware of an issue with off-screen automation but this was on the screen the entire time. Not that it matters much as any practical use would surely put it offscreen very quickly.

 

[Gurgel]

The problem is likely that ONI automation is not time-continuous like real logic gates, but it is more like a spreadsheet update of limited depth every clock cycle. Sometimes this helps, sometimes this causes problems. 

[cblack]

Since I was messing around with this for completely different purposes (long duration clocks, not signal multiplexing), I can probably save you some time.  Most notably, filters/buffers can not be relied upon to remain in synchronization with each other, even if triggered to start via the same wire and set to the same delay.  They can easily get out of sync with one another, which makes things non-deterministic.

That said, I think there might be another way around it which will work in your circumstance, but not mine.  If you instead build your clock circuit to work the timing off of propagation delay instead of using filters/buffers I think this could work.  Propagation delay appears to be 1/10th of a second per gate (identical to the shortest possible length of a pulse), but this timing was based off of filters/buffers.  Since I already stated those are unreliable, take that with a grain of salt.

If you do make the timing circuit, I'd recommend just doing it with a bunch of NOT gates in a loop (and an OR if you need an even number), and then ANDing between the I/O of a single NOT to read off a timing pulse.  Let me know the results, though if you don't post soon I'll probably end up making one of these in my own game.

Edit: The reason I suspect this works off propagation delay, is that automation states (filter/buffer timers excluded) appear to be evaluation in a lock-step fashion in ONI.  With this sort of evaluation, the two timing circuits must remain in sync, unless they don't evaluate every circuit on every step--which I really hope isn't the case.

[biopon]

All right so I was able to isolate this into a much smaller example.

This should be easy to follow but basically the hydro sensor starts off the clocks. The NOT gates between the clocks and the sensor are just there to prevent crosstalk.

The timings on the gates are, from top to bottom: 2, 1, 3, 3, 1, 2. Both clocks should run for 6 seconds. The issue (visible on the screenshot) popped up at maybe the 3rd iteration. You can see that the bottom middle buffer gate is still active (there's barely anything left from its countdown), and the top middle buffer gate is already active (full countdown circle and lit wire between it and the buffer above). The filter below it, set to 3 seconds, should have prevented it from activating so soon.

The rather odd thing is that they seem to be in perfect sync if the timings are 5, 5, 5, and I left it alone for a few minutes like that.

Maybe the internal automation clock has problems with dividing 3 while it handles 5 fine. Either way it's whole seconds, so I don't understand.

EDIT:

On this screenshot, a few iterations later, neither middle gate is active. The lower filter and lower-middle buffer have finished their cycle (2+1 seconds) yet the upper filter is still counting down, even though it is set to 3 seconds.

[Saturnus]

From experiments when automation first came out with encoding multi-bit signals on a single automation line I found that the only way to reliably make cyclic automation work across the map where not everything can be in view at the same time is to use clock sensors as global synchronization. Note that if you set multiple clock sensors on a single line with different settings you can make the synchronization arbitrarily often.  

[biopon]

Thank you sir! I thought about using clock sensors but that;d require one sensor per bit per cycle. (Maybe 1/2 sensor if you do rising/falling edge but practically that's worse than using a full sensor.) Either way, in the example above everything is on the screen yet the filter+buffer time desyncs from the other filter. Do you have any insight into what the internal refresh rate of the automation engine is?

[RonEmpire]

timing is all based on the cpu  processing getting around to processing the automation gates.

my fishes are like stuck a lot of time waiting to get processed.    stuff on the sweeper rails waiting to get updated/processed.   you can see graphics lagging behind  sometimes  with convey rails.   stuff visibly there but  it was long processed already on the rails.

 

so  with all this in mind,  i'm not surprised  at all the automation gates with timers on them are off now and then.

 

[SharraShimada]

One cant build a time based accurate automation at this point. The automation itself has no priority over everything else, so its tied to the workload of the whole game. In late game, automation is somewhat of "guess" not of precise values. This would be manageable, if the automation would be outsourced to a unique process..But as long as this runs at the same process as everything else, we have to deal with delays.

[Saturnus]

1 hour ago, biopon said:

Thank you sir! I thought about using clock sensors but that;d require one sensor per bit per cycle. (Maybe 1/2 sensor if you do rising/falling edge but practically that's worse than using a full sensor.) Either way, in the example above everything is on the screen yet the filter+buffer time desyncs from the other filter. Do you have any insight into what the internal refresh rate of the automation engine is?

You can send a full byte with each clock so it's just a matter of how few updates per cycle you can live with. However, if you really need near real time updates requiring a lot of bytes to transfer each cycle it may be advisable to use a dedicated synchronization clock line in conjunction with the serial data line.

Alternatively, you can work with asynchronous serial data that are only transferred when any of the source bits are changed. The key here would be to have a pulse signal to indicate to the receiver that a data signal is about to be transferred. 

[Gurgel]

56 minutes ago, SharraShimada said:

One cant build a time based accurate automation at this point. The automation itself has no priority over everything else, so its tied to the workload of the whole game. In late game, automation is somewhat of "guess" not of precise values. This would be manageable, if the automation would be outsourced to a unique process..But as long as this runs at the same process as everything else, we have to deal with delays.

Damn, there go my plans of implementing a full CPU in ONI-logic! 

[ishakaru]

From a real world perspective most of our tech either:

1) holds their own clock and synches the clock occasionally (absurd complexity for this scale) .

2) holds their own clock and doesn't care to a large degree how close the clock signals are(not used for data, so doesn't apply here)

3) ties their clocks together via a hard line.

4)other techniques I can't think of atm.

 

It's the third option I would suggest. This in turn means running 2 lines between point A and point B. I would design around having a double pulse on the clock line "send data" "read data". 

 

All in all I would think that the logic system is too basic to do anything too crazy.

[Q the Platypus]

One of the techniques is a modification of (1).  Rather then naively sending high for 1 and low for zero you instead send  HL for 1 and LH for zero.  This means that for every bit there is an edge.  You then use the mid bit edge change to synchronize your clock.

however this is absurdly complex however it is theoretically doable with the gates provided.

[nets]

I can only hope the devs sees your circuits and decides to use them to optimize the automation. 

[ishakaru]

12 hours ago, Q the Platypus said:

Rather then naively sending high for 1 and low for zero you instead send  HL for 1 and LH for zero.

I've never encountered a system that works like that. What I've seen is that HL or LH = 1 and no change in level = 0. 

[Q the Platypus]

It is called Manchester encoding it was used in early Ethernet and RFID.

[Arnadath]

I posted my findings on automation circuits in another post. Since you are trying to make a synchronous system, i highly recommend you read it:

You cannot make a synchronous system by using any buffer or filter gates. If you need a delay in your signal, do what i do, and add a NOTNOT configuration.wherever needed

[biopon]

2 hours ago, Arnadath said:

I posted my findings on automation circuits in another post. Since you are trying to make a synchronous system, i highly recommend you read it:

You cannot make a synchronous system by using any buffer or filter gates. If you need a delay in your signal, do what i do, and add a NOTNOT configuration.wherever needed

Hey that's a very interesting post, and great advice on precise timing. Do you have any experience/insight into offscreen automation delays? Presumably this is the reason for bunker doors reacting late. (Or it may be the doors themselves while automation itself is fine.)

[Arnadath]

1 hour ago, biopon said:

Hey that's a very interesting post, and great advice on precise timing. Do you have any experience/insight into offscreen automation delays? Presumably this is the reason for bunker doors reacting late. (Or it may be the doors themselves while automation itself is fine.)

As I stated before, i would distinct the automation timing in this game to two different entities. There is a "per frame" automation timing which is used by components to determine their internal state. The logic of all gates, is determined by this mechanism. Then there is automation for "real time" events, where real time is determined by the game speed. Regarding filter and buffer gates, they use both automations. The 0.1 setting, roughly corresponds to this "1 frame" of automation, but not when the game is paused, So if you set it to 0.1 sec it will change it's state within one frame while the game is running but not when it's paused.

One more thing to point out is that some arrangements that you make, that rely on a very short pulse signal, might acctually not be short enough, or might blink twice. For some time i liked the NXOR NOT arrangement to make a short blink when it detects an edge. But since, i discovered that this method, will acctually send to blinks down my line, but i couldnt detect the second one, because it didn't coincide with my game fps. Regarding the bunker doors, they have, as all components that accept automation input, an internal buffer, and then a real time buffer to play out it's open/closing animation. And well, real time, might not be rendered as real in parts not currently on screen. ( the per frame automation logic, spans the entire map, even on parts that you haven't revealed yet).

 

I will provide some examples in detail when i get back from work, but my point is that exact timing is not "a way", but "the way" ( or at least until buffer and filter gate times, correspond to "per frame" automation)

 

 

[Arnadath]

 

 

Ok, so i got home from work, and delved straight into this mux. I came up with this:

This is the mux part. You must copy it excactly like depicted. The two switches on the two AND gates on the bottom center that seem to serve no purpose, serve a purpose and should be both turned on. You can fiddle with the 4 switches on the top left.

Assume that those 4 switches is a 4 bit packet you want to send to a demux .When you have set you packet, just toggle the state of the furthest left switch. What this machine will do, is to split the packet into 4 bits and send a logic'1' wake up signal,, for one frame, followed by a logic '1' if the bit we want to sent is 1, or a '0', if it is a zero. 

Ill be working on the demux right now, but i warn you, you must copy it down to detail if you expect the demux ill be making to work correctly

[The Plum Gate]

@Arnadath, I've read a bit of @biopon's work, and it appear that you could send a hold a signal, however briefly and however long a distance, with an SR gate somewhere near the bunker door. Although I think you may already be using this method - if I remember correctly, and I usually don't remember who posts what really well, someone was using sr gates in their automation of bunker doors and they were still having problems.

So offscreen automation behaviour seems ill defined when using buffer and filter gates.

 

[Arnadath]

13 minutes ago, The Plum Gate said:

@Arnadath, I've read a bit of @biopon's work, and it appear that you could send a hold a signal, however briefly and however long a distance, with an SR gate somewhere near the bunker door. Although I think you may already be using this method - if I remember correctly, and I usually don't remember who posts what really well, someone was using sr gates in their automation of bunker doors and they were still having problems.

So offscreen automation behaviour seems ill defined when using buffer and filter gates.

 

 

I think in general, filter and buffer gate based automation will be unreliable. I finished the demux btw. It ended up being a simple shift register and filtering the input. Thear be video, where i also showcase the step-by-step thingy i was talking about in my thread:

 

[Nitroturtle]

12 hours ago, biopon said:

Hey that's a very interesting post, and great advice on precise timing. Do you have any experience/insight into offscreen automation delays? Presumably this is the reason for bunker doors reacting late. (Or it may be the doors themselves while automation itself is fine.)

I believe the issue is with the doors themselves.  Someone elses theory (I forgot who posted it) was that the doors were given a signal and opening fine off screen.  However, if they come into view while changing state, the animation will start from the beginning at the point they come into view.  This seems consistent with what I've observed and seems likely to be what's happening.

[shanemadden]

On 2/2/2019 at 4:50 PM, Nitroturtle said:

I believe the issue is with the doors themselves.  Someone elses theory (I forgot who posted it) was that the doors were given a signal and opening fine off screen.  However, if they come into view while changing state, the animation will start from the beginning at the point they come into view.  This seems consistent with what I've observed and seems likely to be what's happening.

Agreed, that's exactly what I've observed too. Here's the post I recalled covering the behavior I'd seen: