Source
r/Nerf•
Counter_Clockwork

Anyone have a select-fire Vulcan?

Questions + Help

Heyo, I'm working on a MG42-esque build for a LARP I go to. However, there's a big issue - automatic blasters aren't allowed for balancing reasons. Anything electronic has to be select-fire or semi only.

I had no luck looking around, but does anyone know of a select-fire Vulcan build? Either that, or any other select-fire belt fed blaster. I know the vulcan has the manual prime, but I honestly don't care for using it all that much.

Posted Jan 18, 2020, 3:38 PM UTC

513
H3zzard•

The Nerf Ripchain is a belt-fed pump-action blaster, and there are a few older BuzzBee blasters that are similarly operated.

To my knowledge though, I'm not aware of any belt-fed blasters that use batteries that aren't also full auto - be they flywheel or with a plunger-tube. Sorry OP. Hopefully someone else has more knowhow and/or better news.

4
Counter_ClockworkOP•

No big deal, nothing a few MOSFETs and a can-do attitude can fix.

3
torukmakto4•

Never seen one.

There is most certainly a possible relay logic (maybe with a few diodes) representation of a disconnector. Of course, a more complex logic platform is a bigger hammer and can make that extremely easy, including doing it in software on a MCU.

You need to put a limit switch or other form of position sensor on some moving part as an input to any electrical or electronic fire control logic because a basic AEG like a stock Vulcan has no such control, the trigger just turns the motor on and off blindly. The timing of this switch is probably important, since it will probably directly correspond to stopping (with or without braking) the motor and you want the action to end up in a reasonable place in the cycle for loading, and the piston at rest so that the spring is not compressed.

3
OrangeKrate76•

Ya know, this post just made me realize how simple it would be to make a pump action Vulcan...that may have to make its way to my workbench at some point haha

2
Strayaforthewin•

Easy enough. Use an arduino to make your own.

1
Counter_ClockworkOP•

Any guidance on that one? I've never been great at Arduino.

1
torukmakto4•

void loop() {

[various other idle-state busywork goes here]

if(check_trigger()){

fire();

while(check_trigger()){delayMicroseconds(100);}

}

}

Assumptions for example: check_trigger() returns true if the trigger is down. fire() cycles the action exactly once and blocks while cycling is in progress. fire() is self-contained and performs cycle control. No specific post-firing motion control tasks are required, only ceasing to call fire().

This is an example of a trap-loop disconnector. If the trigger is still down after the first fire() call has returned, the while statement's condition (check_trigger()) is initially true and the delayMicroseconds call in the body is executed. The condition is then evaluated again. As long as the trigger continues to be down, the condition continues to be true and the delayMicroseconds call is repeatedly executed. The trigger must be released for at least the moment of one polling cycle to exit the trap and return to the idle loop.

The delay is mostly just a nop statement to busily accomplish nothing, but having it be a delay sets the polling rate. This logic and particular case should mechanically not require debounce/denoise strategies, but they could be present if required, as they should be for trigger down events to prevent switch bounce due to vibration/impact and EMI received by wiring from being able to fire off shots.

3
vadbox•

Uh is "trap loop disconnector" even a thing? Never heard of it. "Trapping" execution in loops, especially for single-threaded real-time applications, is simply a poor practice.

Also, I wouldn't recommend this implementation. Native delay functions (using the Arduino API) should be avoided unless you really know what you're doing. There are libraries available to achieve effective delay solutions that abstract away the complexities/cleans up code. Additionally, it's typically poor practice, especially in real-time contexts, and even moreso where a control system is implemented, to not use a state-driven lifecycle. Cramming everything into loop() is also terrible practice.

2
torukmakto4•

Uh is "trap loop disconnector" even a thing? Never heard of it.

A disconnector is a firearm component, so probably not.

"Trapping" execution in loops, especially for single-threaded real-time applications, is simply a poor practice.

Depends entirely on whether you have anything else whatsoever to be doing in the foreground. If you do not, there is no point to a state-machine.

Some blaster management applications might have idle tasks that aren't time-critical enough to warrant an interrupt but you don't want to be blocked during a state like this - like updating a display state, checking the battery voltage, counting ammo and checking for a mag switch event to reset the counter, etc. In that case you would use a state-machine.

Also, I wouldn't recommend this implementation. Native delay functions (using the Arduino API) should be avoided unless you really know what you're doing. There are libraries available to achieve effective delay solutions that abstract away the complexities/cleans up code.

We differ on that - Not that using cheesy Arduino API stuff is any good, but which direction it is proper to go in from there. There's a lot of bare metal stuff in my newer blaster manager firmwares.

Additionally, it's typically poor practice, especially in real-time contexts, and even moreso where a control system is implemented, to not use a state-driven lifecycle.

Again, depends on what the tasks and priorities are at that moment. It is a more extensible solution to use state-based multitasking but that is apparent immediately if you require it.

5
Strayaforthewin•

Have a test rig for your code first, with removable pins so you don't have to resolder anything. That way, no shell cutting until you're sure your code works.

2
horusrogue•

The Vulcan is select fire in theory. Pressing the trigger causes the gearing mech to complete one cycle. Holding it down causes you to do that in sequence multiple times.

You can probably set up a switch to ensure that holding the trigger does not actually result in an additional cycle being triggered.

1
PotatoFeeder•

Going by the rules, the full auto vulcan is fine. Reason being, its elecTRICAL, not elecTRONIC.

-6
torukmakto4•

Electromechanical

Yes, I make that comment frequently, usually in other contexts though.

1