Controlling blinky-light circuits

[MacThule]

For blinky-light circuits, I typically use a very small Activator->Not->(X)Delay->Original Activator. This tiny circuit works great for the most part, because either they're turned on and flashing, or I mash the activator a couple of times until they cease and desist.

Anyway; trying to build a security door with a red flashing light to remind people to seal the door if left open. It mostly works, but if you seal the door using the faction-accessible activator when the lights are in the 'off' state of their cycle, the circuit continues to cycle. It only turns off when you close the door while half the time (but consistently, when the lights are in 'on' state).

Is there a way to "force" a 3-block cycling circuit like that into always being stopped when a door is closed, and always cycling when the same door is open?

I've tried controlling flashers before for airlocks as well with the same result - it's difficult to pin them down to a specific state when the person using the door isn't paying any attention.

 

[DeepspaceMechanic]

I drew and labeled up the sketch below in a way so that those not familiar with sensor setups and toggle-able clocks can get it too (I didn't assume you aren't).

Obviously, the system below uses plex doors, of which circuits can't tell whether they're open or close (even if you have buttons for them, a player might ignore them, and instead tap on the door itself), unless we rely on sensors. Problem with that is that sensor blocks, in certain applications, require a constant pulsating input from a clock. But at least we can use the same clock that controls the blinking.

If you would use a rail door, you would still need a toggle-able clock for the blinking light, but the door's open/close circuitry itself would be able to tell the door's state (I recommend flip-flops for doors).

EDIT: perhaps we could have a "Check for false" there instead, and spare a Not-gate, I never tried that.



(Orange arrows below indicate the clock signal)

 

[MrGrey1]

For blinky-light circuits, I typically use a very small Activator->Not->(X)Delay->Original Activator. This tiny circuit works great for the most part, because either they're turned on and flashing, or I mash the activator a couple of times until they cease and desist.

Anyway; trying to build a security door with a red flashing light to remind people to seal the door if left open. It mostly works, but if you seal the door using the faction-accessible activator when the lights are in the 'off' state of their cycle, the circuit continues to cycle. It only turns off when you close the door while half the time (but consistently, when the lights are in 'on' state).

Is there a way to "force" a 3-block cycling circuit like that into always being stopped when a door is closed, and always cycling when the same door is open?

I've tried controlling flashers before for airlocks as well with the same result - it's difficult to pin them down to a specific state when the person using the door isn't paying any attention.

Connecting the activator to an And and then the Delay back to the And guarantees an off state... but it's an extra block.

 

[Captain Fortius]

I probably don't need to butt in here, MrGrey explained it pretty well.

Anyhow, here's almost the same. I used an "Or" Block. It didn't fail so far.


If you absolutely need to make sure the door is not left open, you can always barricade it off with area triggers that close it right back as someone leaves.

In this case you may dispose of the clock.

 

[MChain]

The door should be opened directly or via an activator/button?

In the second case you just use the button to switch the flipflop used to open the door and start the blinker clock simultaneously. The door then either closes after a set amount of seconds (better) or is closed after someone passes the area trigger/step-on/logic gate.

In the first case just surround the (definitely, plex)door with logic gate and enable the blinker clock on player passing through using the same method (basically flipflop linked to a clock), in this case the clock is linked to both the door sensor and blinker. When the sensor reads door closed, its signal disables the clock.

 

[MacThule]

If you absolutely need to make sure the door is not left open, you can always barricade it off with area triggers that close it right back as someone leaves.

'OR' block... of course. Yeah - that's a good one too. Thanks for all the input, everyone!

Yeah - I'm totally happy with my sensor doors. They're very reliable compared to in the past. But they don't distinguish friend from foe, and I have totally had people attack me in my base before (back when a couple of the servers were kinda crowded).

So I'm using sensor doors for public access & low security areas, but stuff like respawn, faction module room, etc - I want good security doors on those that will only admit faction members. I like an annoying blinky light setup to remind noobs to close the damn doors (I could put them on timers, but that can get annoying as well - particularly if there's any lag happening).
[doublepost=1550884506,1550884240][/doublepost]

The door should be opened directly or via an activator/button?

In the second case you just use the button to switch the flipflop used to open the door and start the blinker clock simultaneously. The door then either closes after a set amount of seconds (better) or is closed after someone passes the area trigger/step-on/logic gate.

In the first case just surround the (definitely, plex)door with logic gate and enable the blinker clock on player passing through using the same method (basically flipflop linked to a clock), in this case the clock is linked to both the door sensor and blinker. When the sensor reads door closed, its signal disables the clock.

Doors opened directly are troublesome for faction members, so if I'm bothering to logic a door it's pretty much always either a no-touch, sensor driven affair, or some level of access control. Good idea about the transistor/flip-flop block + gate sensor setup!

 

[Dr. Whammy]

One of the things I like to do is create an air lock system that flashes yellow lights when the inner door is open, flashes red lights when the outer door is open, then automatically closes its doors after a few seconds.

It can get pretty logic heavy when you add the flashy lights but it's pretty simple once you get the basics down.

Here's the basic setup for the automatic door.

Step 1) The Activator starts the process by sending an ON signal to the NOT, which has the doors connected to it. Result: activator lights up and doors open.

Step 2) While the above is happening, the Activator simultaneously sends a signal to a Delay, which flows to the next delay, and the next, in a chain. Add as many Delays as you like to increase the time the door stays open.

Step 3) The last delay in the above chain sends an ON signal to a button which is connected to your Activator from step 1 to complete a loop.
Since the button is momentary, it will turn the Activator off (which closes the door via the NOT from step 1), and reset all your delays.

Step 4) You can add the flashers by making your NOT, Delay, AND assembly, as per the examples provided by DeepspaceMechanic , MrGrey1 and Captain Fortius then slaving the AND to your "step 1" Activator.

The end result will be a "push button" door that flashes while open then resets after a delay that you set.

Things to keep in mind.
- As previously mentioned, you can use area triggers (or other intangible blocks to prevent players from opening the door directly.
- If you do block the door and the circuit is damaged, the door will be inoperable and you will have to 'dig' your way back into the structure.
- You may cause a malfunction if you repeatedly trigger the door while it's already open, as it messes with the delay timing.

I've included a template of my design for you all to check out, reverse engineer, etc. The rail docker is set to automatically open the door when docked by connecting the adjacent activator to the Step 1 NOT. The same can be done with the rail basic if desired by adding another Activator and connecting it to the NOT as well.

Hopefully this helps out.