Automation - open door every 3rd cycle

[bzgzd]

This keeps door open 600 seconds every 3rd cycle, so 2 cycles door is closed and then one cycle open. Opening and closing is during night time. (I am using it as entrance to room with slime from Pufts.)

 

I was trying to make it with as few gates as possible, but it can be probably reduced a bit by maybe using 4th clock instead of 3x200 seconds buffer or maybe using just one clock for everything...

 

[Parusoid]

Can you add detailed description how does the signal goes?

[chemie]

Why do you want to open this door every three cycles?

[bzgzd]

2 hours ago, chemie said:

Why do you want to open this door every three cycles?

Because of complains by my strong duplicant with Rock Crusher and Buff traits.
He complained that it is disrespectful to his abilities when he is sent to do some pickup job and after collecting all slime there is just around 200kg while he can transport more than 800kg.

And that was after I already automatically collected and disinfected one day Puft production before making it available for pickup... if I would send him there for just one tiny Puft output he would probably turn on his destructive feature.

So I am now sending him there every 3rd day and all is fine...

 

5 hours ago, Parusoid said:

Can you add detailed description how does the signal goes?

I don't know how to describe it good..., main thing is that AND gates have output connected to one input together with clock and clock signals are active one by one from left to right.
But here is short video with days speed-ed up to 12x and nights are at normal fast speed (3x).
https://youtu.be/LtrUXy3Qr8Y

 

 

[Parusoid]

3 hours ago, bzgzd said:

I don't know how to describe it good..., main thing is that AND gates have output connected to one input together with clock and clock signals are active one by one from left to right.
But here is short video with days speed-ed up to 12x and nights are at normal fast speed (3x).
https://youtu.be/LtrUXy3Qr8Y

 

 

How does the clocks continue sending active signal? Shouldnt they be active only 1% of the day?

[bzgzd]

58 minutes ago, Parusoid said:

How does the clocks continue sending active signal? Shouldnt they be active only 1% of the day?

Clocks are active only 1% of time (6 seconds) but they are also connected to AND outputs, so green cable on that picture going from right clock has 4 things on it all connected together and active signal is "hold" or being send by AND output.

 

[GuyPerfect]

Thanks for the fun engineering challenge! I took a different approach, and wound up taking more space but 15 Kg of metal less than you did. Three-state systems are weird!

      

I'm using a Signal Switch here for easy testing, but it can be swapped out for Clock Sensor or any other kind of sensor just as easily.

Pulse Automation

I set this up using a technique I like to call "pulse automation". Instead of using a continuous Active signal for logical processing, I instead generate a short Active signal for the shortest duration allowed by the game engine. This is achieved by passing a continuous input line through a NOT FIlter and AND Filter as shown in the image. Whenver the input goes Active, a pulse is generated in the system. The input must go Standby and then Active again to generate another pulse.

Pulse automation opens up new options when it comes to designing logical systems. For example, the XOR Filter can act as a state switch when using pulse signals. By plugging its output back into one of its inputs and a pulse line into the other input, its output state will be toggled each time it receives an Active pulse. (Its output is continuous: it does not itself pulse.)

I used two XOR latches in this setup, which I called A and B in my head. Additional logic gates controlled the three states of the machine:

• In the default state, A is Standby and B is Standby
• In state 1, A is Active and B is Standby
• In state 2, A is Standby and B is Active
• After state 2, it returns to the default state

The pulse from the input is sent to both XOR latches, but passes through other filters first to determine when toggling is appropriate. The logic used is as follows:

• Toggle A whenever B is Standby
• Toggle B whenever either A or B is Active

Latch A's output isn't accessible the way I wired this up, so I hooked up the door to B's output instead. This means you must flip the switch on twice to open the door. The third time you flip the switch on, the door will close. Every three "ons" will open the door. If you use a Clock Sensor instead, the door will be open every three days instead, solving your initial riddle.

EDIT:
Miscounted the crafting costs of our machines. I've put the correct figure in this post.

[Parusoid]

13 hours ago, bzgzd said:

Clocks are active only 1% of time (6 seconds) but they are also connected to AND outputs, so green cable on that picture going from right clock has 4 things on it all connected together and active signal is "hold" or being send by AND output.

 

I think I need more explanation, since it does not make sense. Clock should be green 6 seconds but it is the whole time. 

[asveron]

 

21 hours ago, chemie said:

Why do you want to open this door every three cycles?

Besides the niche use of the author, this is actually EXTREMELY useful!

Manually opening and closing doors to farms every X days(until they all fully grow) actually makes harvesting extremely more efficient.

For temperature control, it also reduces the amount of change. Some people point out that doors are super temp conductive, but keeping a room closed still maintains a lot more temperature than and open air system.

[Saturnus]

24 minutes ago, asveron said:

 

Besides the niche use of the author, this is actually EXTREMELY useful!

Manually opening and closing doors to farms every X days(until they all fully grow) actually makes harvesting extremely more efficient.

For temperature control, it also reduces the amount of change. Some people point out that doors are super temp conductive, but keeping a room closed still maintains a lot more temperature than and open air system.

For X days a standard binary counter would be the obvious choice. However, specifically 3 days can be done with less gates than a standard binary counter would dictate.

[bzgzd]

11 hours ago, GuyPerfect said:

Thanks for the fun engineering challenge! I took a different approach, and wound up taking more space but 15 Kg of metal less than you did. Three-state systems are weird!

      

It has same amount of gates/buffers/filters and only 1 clock instead of 3 so according to "rules" it is better.
I should count clocks also as gates or counting all material including cables is probably best.

I am only a bit afraid if those impulse systems are not based on ONI implementation detail that could change. Like if AND has on input signal and NOT that same signal... But it is useful so they might add some "impulse maker". (and also integer counter)

I will use your version as it feels more professional.

 

2 hours ago, Parusoid said:

I think I need more explanation, since it does not make sense. Clock should be green 6 seconds but it is the whole time. 

When clock is green it doesn't mean it is active. Clock is active when 2 lights are on. It is green because cable connected to it has signal.

 

[GuyPerfect]

1 hour ago, bzgzd said:

I am only a bit afraid if those impulse systems are not based on ONI implementation detail that could change.

[...]

I will use your version as it feels more professional.

Why thank you. I worked hard on it. (-:

Don't worry about the game implementation: signal pulses are here to stay. In order to prevent them, all Automation gates would have to be processed recursively each simulation tick to determine their stable state, and that opens up the possibility of endless loops.

Consider a NOT Filter pligged into itself. When its input is Standby, its output is Active and vice-versa. Except when its output becomes Active, so does its input, which in turn makes its output Standby again! It's in a constant dual state of both Active and Standby, and processing it recursively in a single time quantum is a task that can never end.

What the game does instead is process all Filters once according to their "current" state in order to determine their "next" state. I'll have to do some testing to see whether the order in which the game processes earlier Filters affects the processing of later filters, but I don't think it does... Now you've got me thinking; I'll have to check it out when I get home. Thanks for bringing it up.

[GuyPerfect]

I was able to verify the behavior of the Automation engine inside the game with this experiment:

      

I plugged two NOT Filters into each other. As expected, in their initial state, they picked one side or the other and maintained it, since its input stays the same after it passes through the other one. But by adding a pulse switch to each state, I was able to get both NOT Filters to be in the same state, as pictured.

In this situation, both filters depend on the output of the other. By observing what happens next, we can determine the order of operations. There are two possibilities:

1. If one filter gets updated before the other, regardless of which goes first, then its output will go Standby and the other filter will remain as it is. The system will stabilize.
2. If each filter is processed simultaneously, then they will both go Standby, followed by Active, and so-on, rapidly alternating between states.

In practice, scenario #2 is the one that occurs. And boy is it noisy.

To my trained eye (really), it looks like Automation ticks are processed in two passes: once to update the states of all the switches/signals and filters, and a second pass to update the statuses of all the wires. If any of the outputs that a wire is connected to are Active, then the wire itself becomes Active. Otherwise, it will be Standby.

The take-away from this is that we can confidently design Automation systems without worrying about things being processed in the wrong order. Whatever a filter looks like it will do "as of right now", it will indeed do regardless of what the other filters do. The states of all the wires are determined after the fact.

[bzgzd]

3 hours ago, GuyPerfect said:

In practice, scenario #2 is the one that occurs. And boy is it noisy.

Noise generator... or neon show on automation preview.

 

3 hours ago, GuyPerfect said:

To my trained eye (really), it looks like Automation ticks are processed in two passes: once to update the states of all the switches/signals and filters, and a second pass to update the statuses of all the wires. If any of the outputs that a wire is connected to are Active, then the wire itself becomes Active. Otherwise, it will be Standby.

Seems correct. I don't have trained eye but I used debug steps which is in debug mode "alt + =" while game is paused and your counter when door is open and switch is turned on goes like this in 5 steps: