So I am trying to set a retractable sentry gun to turn on immediately when the motion sensor detects something, but wait 30s after something leaves to turn back off. So far I have these circuits: Motion Sensor: MS1, a 10S delay on that switch, and then an inverter on the 10S Delay Finally, I have a Set/Rest Latch Using this, I have the 2nd part working, where it turns off after 30s (using 10s in example screenshot for faster testing) But, it also takes 10s to turn on, even though the "set" is the motion sensor signal. How do I get the light to turn on immediately but wait 10s after leaving the motion sensor area to turn off?
Not a pro at this but... Set a signal to activate sentry and the delay signal to the turn it off. On a set reset signal you don't need the inverter.
Thanks for the suggestion. Unfortunately, lights, turrets, and other devices only have a single On/Off signal. There isn't one for ON and one for OFF. That's why I have the Set/Reset Latch. And, you do need the inverter on the delay. The delay will give a signal ON(1) after 10 seconds. The Reset portion of the latch needs an OFF(0) signal to get it to actually reset, hence the inverter. Without the inverter, it takes 10 seconds to turn on, but turns off immediately once you leave the motion sensor zone.
Another thing that would need some semplification, the circuitry system is difficult to understand right now
I agree. There isn't any type of tutorial that explains how things work. There are user made ones, but an official, in game one would help a bunch.
Sensor sends signal. Let's call it "Scan01" Add Delay Circuit for 30 seconds called "Sig001" Add Set/Reset Latch using "Scan01" and "Sig001" outputs "Sig002" Sentry Turret is set to follow "Sig002" With this, the sensor triggers the set/reset latch and enables the turret; the delay circuit activates 30 seconds later and turns off the turret. Inverter isn't necessary. An issue is that if someone stands inside the motion sensor's field for longer than the 30 second timer, the turret will remain active but close when they leave the sensor's range. A light barrier would work better for a short precise interval instead of a motion sensor, but a sensor is more accurate with a wider range and will keep the turret active as long as there's a target to shoot. If you want a light to activate immediately, have it activated by Scan01, unless you want it to activate for the same duration as the turret, in which case you'll want it to run on Sig002 like the turret. The real problem in your design is that you want the turret to close 30 seconds after the target has left, but the means of making a sensor activate the turret for as long as someone's standing in the field and turn off after another 30 second delay would require another delay timer and a different configuration.
This was exactly my setup, and it wasn't working. (Other than the inverter) And the problem isn't that the turret isn't closing 30s after the target as left. That part is working correctly. The problem is that it takes 30s for the light/turret to actually turn on, too, even though it's set to turn on with Scan01. Try it yourself. I've made it like 10 different times and I get exactly the same behavior. At this point, I think it's actually a bug.
I did try it myself. I made the circuit before I posted it here. It worked fine for me. It's the inverter that's breaking yours. It's adding a step that's causing the latch circuit that activates the turret to set last.
I beleive I understand your problem. I've noticed it too. You set a motion sensor to turn on a light and when you enter the sensor field it takes 5 - 10 seconds for the light to actually come on. It seems the delay is more likely and longer the more devices are connected to the sensor. I don't know if this is a bug of some sort or something that just needs some polishing but it is frustrating. In your case, with the delay turrets seem to have anyway in targeting combined with the delay from the sensor it almost makes the turrt useless.
Hi, I know this is an old post, but I was searching for a solution to a similar task I wanted to perform and was having the same issue as the OP describes. In the end, I managed to understand the issue and found a solution. The issue is the Delay Trigger, once it is set high, it needs to be set low again for the delay to be reset. Here is my solution: I use a pulse to set the reset trigger high then low after 1 second HangerDoor is the Sensor HDLights is the Signal used to control a light (Could be a Turret of course) The delay is 5 seconds https://imgur.com/a/vut1Tv6 hope this helps anyone else also looking for a delay off switch
Hello folks! Here's a little help with your digital logic problem. You can actually do this relatively easily with only 2 circuits, no need for an inverter or latch circuit. In boolean syntax what you can do is: Sensor OR Delay(Sensor) = output. In game "circuit" just take your sensor - could be a motion sensor, lever (switch), another circuit, any input - and put that into a delay circuit. Call it something like "DelayedSensor1". Then create a second circuit with an OR, and the inputs to that one are "Sensor1", "DelayedSensor1", output can be "OrControl". Assign the thing you want to control to "follow" "OrControl". That's it! How does it work? When the Sensor input turns on, the OR will get set (on) and will stay on as long as either Sensor1 or DelayedSensor1 are on. At the same time, the "DelayedSensor1" will stay off for x seconds delay and then switch on as well (but doesn't matter because Sensor1 is already on and already "shortcircuiting" the OR...) When Sensor1 turns off, the DelayedSensor1 will stay on for x seconds, keeping the OR output ON until the delay runs out. Once the delay runs out, it switches off... now BOTH Sensor1 and DelayedSensor1 are both off, so the output goes off. Easy Peasy!!
Sorry, this doesn't work but I see where you are going. The delay signal is set at the end of the signal, and unless you are in the trigger zone longer than the delay it won't stay on. Delays are also kind of a memory device as well they hold their state until the delay period is up. Let's keep this simple. Sensor -> light. Step in sensor, light comes on, leave sensor light stays on for 5 seconds. The issue with your OR gate solution is the first delay isn't covered. If you step in the sensor and step out, then the light will turn off because the first delay hasn't expired and DelaySensor is still 0. In 5 seconds the light will blink on for however long you were in the sensor (up to 5 seconds). I've not completely tested this, but it seems to work with some simple lights. You can recreate it by using 4 lights and a sensor. Sensor DelaySensor (set for 5 seconds) SRLatch S : Sensor R: DelaySensor Trigger = 4xOR : Sensor SRLatch DelaySensor (4th input should be set to 0, but there's a bug where that doesn't always work. Set it to Sensor as a work around) That way, the light will be on if the Sensor is set, it's before the first delay, and while the delay is running. If the sensor is still on, it'll keep running. From my tests it seems to keep the light on for about an extra second, but it seems to be consistent. (so far)
The latch thingy is buggy. Apparently it's supposed to set an output signal to ON when an input signal is ON and to keep the output ON until it's reset by a second signal when the second signal changes (or when the second signal is ON, but that would leave the question what to do when both input and reset signal are ON). It would make sense if it were working. I haven't been able to figure out what it actually does. Another problem is that you can't decide in which order circuits happen, like do you want a signal inverted before or after X, a delay to begin before or after X, etc.. And an IF circuit is missing entirely The best advice is not to use circuits at all. Otherwise you quickly end up with too many unwanted effects. I guess the lesson is not to try to simulate hardware in software ... There's reasons why I keep saying that if the rockets that were sent to the moon had computers controlling them like they nowadays would have, they'd never have made it.
I approach Empyrion's logic as a state machine. There is no order they are either set or not all at the same time. From my experience the state of the latch with both the set and reset on is indeterminate. It's not a good answer, but it is what it is. So far my delay system has been working as intended. The delay is not accurate by any means (I've found that changing the delay value changes the actual cycle time in "non-linear" ways) but so far I've found it consistent. As for the rockets and computers, the latest moon mission(s) would say different. That being said, this game isn't NASA...
When you see it as a state machine, how would you know what state it assumes without knowing what the order in which its elements you configure, which determine which state it will assume depending on its inputs, is? I'd call it a black box instead, and I'd rather be able to decide which order I want. Not being able to do that is very confusing. You can't intentionally make a cake when you have only the ingredients, the tools and the required instructions but have no idea in which order the instructions need to be performed to bring the cake about. --- Did you ever bake or cook with kids? It's fun, and it's interesting to see what they don't know yet The only thing I accomplished with the latch thing is that two doors would continously open and close interchangeably, with wasn't at all what I wanted, and IIRC that can be achieved without the latch thing. As to the rockets, they haven't sent people to the moon lately, did they? NASA and whoever goes to space does accomplish amazing things, and what makes it so amazing is that they ultimately can not do tests and yet what they do mostly works. I guess you can only really understand and appreciate that when you put stuff together (like deploying a new server) or create something new (like a new piece of software) and see first hand how you can not get around thorougly testing what you have envisioned. It usually doesn't work right away. When going to space, you can't do that kind of testing, and what you created simply has to work; otherwise, people will die, and/or the failure is a very expensive one, and a lot of resources have been wasted. In a way, it's very similar to cooking and baking. It takes quite some experience to get it right.
Sorry for the late reply, but all I can say is check out Google... I'm not going to argue known computing science methods and theories. Read this and figure it out: https://en.wikipedia.org/wiki/Finite-state_machine It is what it is. I'm using the above on my CV to open and close my lower ramp on a ~3 second delay. Works every time, no issues.
Pulse Sensor like this Sensor1 -> Delay Sensor1 -> Set Latch Delay -> reset latch Latch -> Device ON for set time on delay Now here is the tricks to know, use the ON/OFF signal logic on the sensor itself in inverted from the latch output. This took me an hour to noodle out... And might not be 100% perfect, but it does seem to work for me. May need to turn the sensor on if you flip it off by accident. Oh, this was what I did for my Teleporter. But it would work for a turret too. Bonus here is that since the sensor was turn off and back on, anyone still in the sensor field is actually ignored too, until they re-enter the field. --edit : some reason the server is now rechecking the sensor... looping while standing in the field. Hmmm --edit2: Latch1 Q-> Delay2 & Latch2 set, Latch2 Q-> Sensor (invert), Delay2 -> latch2 reset. This should add a timeout before it can turn on again... oO Reworked to stop the sensor redetection loop, this gives a 20 seconds lock out before the system is reset fully. Example is for a teleporter project, in this case the teleporter follows the "TelLatch1" signal, and the sensor follows the TelSenTog but inverted.
