So, I'm working on a device that has to be pulsed X number of times, then stop.
To do this I'm using the t=(c)(p)-c/2
c - the number of ticks within the clock
p - the number of pulses needed;
and
t - the number of ticks the clock will run.
This picture of my current setup and math example may help explain:
So for this particular example, the equation would look like this: t=(12)(10)-12/2 meaning t=114
The clock must pulse once every second for 10 seconds.
12 ticks = 1 second
1 second = 0.333333~ ticks
- so -
114 ticks = 9.5 seconds, plus 0.5 second for the clock to deactivate = 10 seconds
Sorry for the long math bout, but I figured it'd help in figuring out a condensed setup. Hopefully, anyhow.
While this is all well and good, this is large and clunky, and as the number of pulses needed increases so does the number of repeaters required. Does anyone have a way of condensing something like this?
While I may know enough to get my way around redstone, it isn't something I'm 100% great at.
One thing immediately, 20 game ticks = 10 RS ticks = 1 second [barring lag]. (not sure where the "12 ticks = 1 second" is coming from....)
If I'm understanding correctly, the first sticky piston (directly above the button) needs to stay extended AND the leftmost RS torch on the left side of the button block needs to remain off for 57 RS ticks for the clock to pulse the desired number of times.
This is currently done by having the button turn on the RS torch (the one in the column that aligns with the 'p' in the equation) then deactivating it when the signal gets around the repeater chain (on the right side).
However, anything that keeps the RS line connecting the first sticky piston AND the leftmost RS torch powered for that amount of time should also work.
If you were to move the button and add a pulse extender between the new button and the block to which the current button is attached, the design should still function properly.
Either the dropper-latch or hopper-clock pulse extenders found here would be more compact than the repeater line.
Both, however, do require comparators.
Rollback Post to RevisionRollBack
"Why does everything have to be so stoopid?" Harvey Pekar (from American Splendor)
WARNING: I have an extemely "grindy" playstyle; YMMV — if this doesn't seem fun to you, mine what you can from it & bin the rest.
One thing immediately, 20 game ticks = 10 RS ticks = 1 second [barring lag]. (not sure where the "12 ticks = 1 second" is coming from....)
If I'm understanding correctly, the first sticky piston (directly above the button) needs to stay extended AND the leftmost RS torch on the left side of the button block needs to remain off for 57 RS ticks for the clock to pulse the desired number of times.
This is currently done by having the button turn on the RS torch (the one in the column that aligns with the 'p' in the equation) then deactivating it when the signal gets around the repeater chain (on the right side).
However, anything that keeps the RS line connecting the first sticky piston AND the leftmost RS torch powered for that amount of time should also work.
If you were to move the button and add a pulse extender between the new button and the block to which the current button is attached, the design should still function properly.
Either the dropper-latch or hopper-clock pulse extenders found here would be more compact than the repeater line.
Both, however, do require comparators.
Hmm... Well, I'm not sure where the parameters (like the 12 RS ticks = 1 sec) or what the equations lead to are wrong, only because of everything functioning at intended speed, timing and the like. But, we are cutting into milliseconds of difference; I may just not be noticing it well enough. Obviously, not saying you're wrong by any means!
Thanks for the link! I decided to roll with the Hopper-Clock Pulse Extender, and after some fiddling with timing, it works out really well. I appreciate your help!
So, I'm working on a device that has to be pulsed X number of times, then stop.
To do this I'm using the t=(c)(p)-c/2
c - the number of ticks within the clock
p - the number of pulses needed;
and
t - the number of ticks the clock will run.
This picture of my current setup and math example may help explain:
So for this particular example, the equation would look like this: t=(12)(10)-12/2 meaning t=114
The clock must pulse once every second for 10 seconds.
12 ticks = 1 second
1 second = 0.333333~ ticks
- so -
114 ticks = 9.5 seconds, plus 0.5 second for the clock to deactivate = 10 seconds
Sorry for the long math bout, but I figured it'd help in figuring out a condensed setup. Hopefully, anyhow.
While this is all well and good, this is large and clunky, and as the number of pulses needed increases so does the number of repeaters required.
Does anyone have a way of condensing something like this?
While I may know enough to get my way around redstone, it isn't something I'm 100% great at.
Thanks, everyone! :3
One thing immediately, 20 game ticks = 10 RS ticks = 1 second [barring lag]. (not sure where the "12 ticks = 1 second" is coming from....)
If I'm understanding correctly, the first sticky piston (directly above the button) needs to stay extended AND the leftmost RS torch on the left side of the button block needs to remain off for 57 RS ticks for the clock to pulse the desired number of times.
This is currently done by having the button turn on the RS torch (the one in the column that aligns with the 'p' in the equation) then deactivating it when the signal gets around the repeater chain (on the right side).
However, anything that keeps the RS line connecting the first sticky piston AND the leftmost RS torch powered for that amount of time should also work.
If you were to move the button and add a pulse extender between the new button and the block to which the current button is attached, the design should still function properly.
Either the dropper-latch or hopper-clock pulse extenders found here would be more compact than the repeater line.
Both, however, do require comparators.
Hmm... Well, I'm not sure where the parameters (like the 12 RS ticks = 1 sec) or what the equations lead to are wrong, only because of everything functioning at intended speed, timing and the like. But, we are cutting into milliseconds of difference; I may just not be noticing it well enough. Obviously, not saying you're wrong by any means!
Thanks for the link! I decided to roll with the Hopper-Clock Pulse Extender, and after some fiddling with timing, it works out really well. I appreciate your help!