Mach3 G-Code: Configuring Physical Button Repeat Guide

Configure the physical pushbutton to invoke Mach3's normal program-start action, not to execute an arbitrary M-code or G-code. At the end of the loaded program, return the machine to the required restart position with the tested G28/G30 sequence; after the program finishes, the next valid button press starts the loaded file again. This produces operator-controlled repetition rather than an uncontrolled automatic loop.

How the Repeat Cycle Works

Mach3 must satisfy three separate conditions before a repeat command is useful: the program has ended, the program pointer is ready to start from the beginning, and the machine is in a valid physical position for the first commanded move. A pushbutton only supplies the start request; it does not establish those conditions by itself.

Adding G28 and G30 at the end of the program was the working installation-specific solution. These commands cause machine movement based on positions and controller behavior already configured in Mach3. Validate their destinations on the actual machine because a return command can move through an intermediate point or use a stored reference position. The required sequence is therefore:

1. Execute the machining program normally.
2. Run the end-of-program positioning commands.
3. Finish with the program inactive and ready for a new start request.
4. Press the physical start button to run the loaded program again.

This is not the same as placing an unconditional loop inside the G-code. The operator remains responsible for confirming that the workpiece, tooling, guards, and machine position are ready for another cycle.

Separate Input Mapping from G-Code Motion

Treat the button mapping and the return motion as two independent functions. Mach3's input logic must recognize the field input and associate it with the same action used to start the program from the user interface. The G-code must place the machine in the correct state at the end of each completed part.

Do not search the M-code or G-code list for a physical-input trigger. Those codes execute functions from within the running program; the external button must be processed by Mach3's input and control-action configuration. Use the exact input identity and start-action identifier shown by the installed Mach3 configuration because no specific pin, port, or OEM identifier applies universally.

Diagnostic Sequence

1. Test the input electrically. Operate the button while observing the corresponding Mach3 input state. If the state never changes, diagnose field wiring, input supply, common reference, breakout-board assignment, and active polarity before editing G-code.
2. Check for a stable transition. A single press must not flicker between states or remain asserted after release. Correct contact bounce, electrical noise, polarity, or interface configuration using the capabilities documented for the installed hardware.
3. Test the mapped action while idle. Load a harmless test program, reset it to the beginning, and operate the button. If Mach3 sees the input but does not start, the fault is in the action mapping or in an interlock that prevents execution.
4. Run the program to completion. Confirm that control returns to an idle state and that the program can be started again from the beginning using the on-screen start control.
5. Test end positioning separately. Execute the G28/G30 portion at reduced risk, with the tool clear of the fixture. Record the final coordinates and compare them with the position required by the program's first moves.
6. Combine the functions. Run one full cycle, wait for completion, then press the physical button. Diagnose any difference between the first and second cycles as a program-state or positioning problem rather than an input problem.

Configure the Repeat Procedure

1. Back up the working Mach3 profile and the production G-code before changing either one.
2. Wire the momentary operator button to a compatible hardware input. Determine the required voltage, common connection, sourcing or sinking arrangement, and polarity from the installed interface documentation.
3. Assign the hardware channel to a Mach3 input and verify its state in the diagnostics display.
4. Map that input to the normal program-start action. Use the identifier exposed by the installed Mach3 configuration rather than substituting an unverified OEM number.
5. Edit the program end so the validated return sequence occurs before completion:

G28
G30

Preserve any existing program-end command after this sequence. The exact surrounding lines depend on the file and must retain the intended spindle, coolant, tool, and modal-state handling.

6. Load the edited file and use a dry run, simulation, or other machine-appropriate prove-out method. Keep the tool clear while confirming the path of both return commands.
7. Run the program once from the user interface, then repeat it with the physical button.
8. Confirm that each press produces one cycle and that the machine never restarts solely because the button remains held.

Verification Criteria

Accept the change only when the first cycle and every repeated cycle begin from the same intended machine state. Check more than the visible tool position: confirm the active coordinate system, offsets, distance mode, spindle state, and any other modal conditions on which the opening blocks depend. A repeat may start at the top of the file while retaining modal state left by the previous run unless the program explicitly establishes its required state.

Perform at least one complete no-cut test followed by a controlled production test. During each test, verify that G28 and G30 travel through clear space, the program finishes before another start is accepted, the program pointer returns to the expected location, and one released-and-pressed button action causes exactly one restart. Also test the response when Mach3 is stopped, reset, or blocked by an interlock; the button must not bypass those conditions.

Recurring Pitfalls

• Using return commands without proving their destinations: Stored or configured return positions may not match the fixture clearance needed by the current job.
• Assuming the button repeats automatically: The button requests a start. Program completion, pointer reset, and safe restart position are separate requirements.
• Starting from a retained modal state: Put every mode required by the program in its opening setup blocks rather than relying on the previous run.
• Mapping a maintained signal as a momentary command: A held input can create repeated or ambiguous start requests. Verify press-and-release behavior on the installed controller.
• Troubleshooting wiring with production motion enabled: Prove the input indication and action mapping with a harmless test file before allowing return motion.
• Treating cycle start as a safety function: Software input mapping does not replace guards, emergency-stop circuits, or machine safety controls.

FAQ