⚠️ ⚠️ ⚠️ Please download NeXT from the Releases page only
Cheap and easy manual and automatic work-piece probing, toolchanges, toolsetting and more!
This is an "operations system" rather than an "operating system" in the traditional sense.
We build on top of RepRapFirmware, providing operators of the Millennium Machines Milo V1.5 with a new-machinist-friendly workflow for work-piece and tool probing, and safe, effective tool changes.
- Canned probing cycles usable directly from gcode or via Duet Web Control as named macros.
- Fallbacks to guided manual probing when touch probe and / or toolsetter is not available.
- Safety checks at every step to instill confidence in novice machinists.
- Variable Spindle Speed Control (planned; not yet in v0.6 betas).
- Compatible with Millennium Machines Milo GCode Dialect.
Please follow the installation instructions on our documentation site.
If you have not already installed a supported RRF configuration, then you should follow the instructions for the Milo.
If you are not using a Millennium Machine, you will need to create a compatible configuration yourself.
You are fully responsible for running the code contained in this library on your own machine. It has been tested on a number of different machines by different people, and is written from a safety-first perspective, but it is a fool who thinks that they can write software without bugs, and it is a (somewhat lesser) fool to use that software and not expect occasional shenanigans. These shenanigans might cost you money in the best case, and blood in the worst - and by using this software you agree that we are not liable for any losses that might occur to you or others during your use of the software.
It is up to you, and only you, to take the relevant precautions when using NeXT - run your tool paths without a workpiece installed and spindle disabled, test the probing routines with soft(er) items (e.g. a roll of tape for bore probe, a cardboard box for block or corner probes), stay away from the machine when it is moving and ALWAYS WEAR EYE PROTECTION!
Remember that this is designed for machines that can really hurt you if you're not careful. This software tries its best to protect you but nothing can stand in the way of a really determined idiot 😅
If you find any bugs or issues, please create an issue on this repository. Best-effort support is available via our Discord.
The information contained here is for advanced users who want to understand further how NeXT works, and what it is capable of. For normal usage, all the information you need is in the documentation.
- You must be using RRF
v3.6.0-rc.3or above. NeXT uses many 'meta gcode' features that do not exist in earlier versions.
Reference firmware for development: When reviewing or extending NeXT macros and docs, treat RepRapFirmware 3.6.2 as the evaluation baseline (G-code dictionary, object model, and bugfix level). See docs/RRF_REFERENCE.md.
- NeXT includes its own
daemon.gfile for repetitive tasks (VSSC is planned but not yet implemented). If you want to implement your own repetitive tasks, create auser-daemon.gfile in the/sysdirectory, which NeXT will run during its daemon loop. Do not use long-running loops insideuser-daemon.gas this will interfere with NeXT's daemon behaviour.
You need a working RRF config with all of your machine axes moving in the right direction before you start.
If you can't home your machine, make that work first - following the NeXT configuration wizard will be impossible without a machine that moves correctly.
You need to configure your Toolsetter and optionally, Touch Probe, in RRF before trying to use them in NeXT.
This involves configuring both of them as Z probes, which can be done with the M558 command.
You would add line(s) similar to these to your RRF config.g file, above where the NeXT file (nxt.g) is included.
; Configure the touch probe as Z-Probe 0 on pin "probe" - mainboard specific, DO NOT COPY AND PASTE!
; Type P5 = filtered digital
; Dive Height H5 = back-off 5mm before repeat probing
; Max Retries A10 = retry probe a maximum of 10 times
; Tolerance S0.01 = when tolerance is reached, stop probing
; Travel Speed T1200 = travel moves run at this speed to the start of the probing location
; Probe Speed F300:50 = initial probe speed runs at 300mm/min, subsequent at 50mm/min
M558 K0 P5 C"probe" H2 A10 S0.01 T1200 F300:50
; Configure the toolsetter as Z-Probe 1 on pin "xstopmax" - mainboard specific, DO NOT COPY AND PASTE!
; Type P8 = unfiltered digital
; Dive Height H10 = back-off 10mm before repeat probing
; Max Retries A10 = retry probe a maximum of 10 times
; Tolerance S0.01 = when tolerance is reached, stop probing
; Travel Speed T1200 = travel moves run at this speed to the start of the probing location
; Probe Speed F300:60 = initial probe speed runs at 300mm/min, subsequent at 60mm/min
M558 K1 P8 C"xstopmax" H10 A10 S0.01 T1200 F300:60
You will also want to remove any manual tool definitions from your configuration, as NeXT manages tools through the M4000 and M4001 custom M-codes - remove any lines in your config.g that use the M563 command, and also any lines which refer to tools which would have been created by these commands (e.g. G10 P<toolnumber>).
Some touch probes may not filter their outputs, which means they can be subject to bouncing. This is where, when the switch or detection mechanism inside the touch probe changes state, it flaps between the two states before settling into its' final position. This can cause issues in NeXT with protected moves, as we stop moving when the probe is activated or deactivated but by the time we check the probe status, it might have flipped.
The solution for this is to define the touch probe as ID Zero and the probe type as 5 (M558 K0 P5 C"probe"...), as in the above example configuration line. This enables filtering in RRF which debounces the probe input. The downside of this is that the probe may respond more slowly, but this is not necessarily a problem as the delay is likely to be accounted for in the deflection values calculated for X and Y. It is also not possible to define more than one probe as type 5, so if you already have a probe that requires type 5 that is not your touch probe then this may be an issue.
Your touch probe may not need filtering, and you can test this by moving it to a different probe ID (2, for example) and changing the type to 8 like the toolsetter definition.
Due to some issues with RRF as it currently stands, there are a small number of situations where you can shoot yourself in the foot when running NeXT macros outside of a print file. These are:
-
Clicking Cancel on a messagebox to abort a probing routine may trigger undesired behaviour when running a probe outside of a print file. This is because clicking cancel on a message box, if outside of a print, simply returns from the macro that created the box. There is no way to easily detect this from any calling macros so we could end up running moves that were unexpected. This is something that ideally will need to be fixed by the RRF devs and is documented here. When clicking cancel from within a print, the whole print is aborted from that point so this behaviour should not be an issue when executing actual CAM code produced by our post-processor.
-
Toolchanges cannot currently be cancelled, so if a touch probe is not detected during the touch probe installation routine, then the active tool number will still be set to the probing tool. This will not affect print files because an aborted toolchange aborts the print (but still sets the active tool number). We use the tool number as a guard to not execute probing routines unless the touch probe is installed, so this leaves some window of vulnerability where it could appear like a touch probe is connected when it actually wasn't detected. Again, this is likely something that should be fixed in RRF but if we absolutely have to work around it by tracking touchprobe connectivity ourselves then we can implement this.
-
If the touch probe is activated during a protected move, then due to how this is implemented in RRF it is possible that the speeds of the probe were not reset correctly. Subsequent probes will run at the same speed which might be very slow, or very fast (if the interrupted move was a travel move). You should be aware of this when restarting from a collision during a protected move. We are currently looking for options as to how to improve this behaviour, but it may involve underlying changes to RRF to allow this.
-
Memory limits on the
stm32f4chip are very restrictive - NeXT uses quite a lot of global variables for communication between macros and configuration, and is pushing the limits of this chip. You may receiveOutOfMemorycrashes (checkM122after an unexpected reboot to confirm) if you use global variables in other places in your configuration. The only way around this issue at the moment is to reduce the number and size of global variables in other locations - NeXT is already about as efficient as it can be.
To help us work out any issues, please run M7600 D1 and paste the whole output into any issue you create, or attach with any help request in Discord. This output includes the value of NeXT specific variables and also the contents of the RRF object model - specifically the limits, move, sensors, spindles, state and tool keys which are essential for debugging NeXT functionality (or lack thereof).
To install the NeXT plugin on your physical machine:
- Download the
NeXT-vX.X.X.zippackage. - In Duet Web Control, navigate to Settings → Plugins.
- Click Install Plugin and upload the ZIP. Start the plugin once installed.
- Mandatory Firmware Step: Open your
0:/sys/config.gvia the System Directory and addM98 P"nxt.g"to the end of the file. (If you are upgrading frommos, ensure you remove the oldM98 P"mos.g"and replace it withnxt.g). - Run
M999to restart the board and load the new NeXT globals. - In Configuration, select your platform (
v1.5orv1.6_v2), then Apply platform sys files so0:/sys/home*.gmatch that platform (homing requirements).
The NeXT UI is a Vue 2.7 / Vuetify 2.x plugin for Duet Web Control 3.6.2+ (dwcVersion in ui/plugin.json). Source lives in ui/.
Prerequisites: A local clone of DuetWebControl on a 3.6.2-compatible branch or tag (e.g. 3.6-dev or v3.6.2 when available) with npm install completed.
# 1. Create a directory junction (Windows) — folder name MUST match plugin.json "id"
mklink /J "<DWC_ROOT>\src\plugins\NeXT" "<THIS_REPO>\ui"
# On Linux/macOS use a symlink instead:
# ln -s <THIS_REPO>/ui <DWC_ROOT>/src/plugins/NeXT
# 2. Start the dev server from the DWC root
cd <DWC_ROOT>
npm run dev
# → http://localhost:8080/On first load: cancel the "Connect to Machine" dialog → Settings → Plugins → Start "NeXT" → it appears under Control in the sidebar.
| Tab | Features |
|---|---|
| Status | Live axis positions (machine + work coords), NeXT system health (nxtLoaded), feature flags (touch probe, tool setter, coolant) |
| Configuration | Globals snapshot, board pack / platform selection (docs/NXT_BOARD_CONFIG.md), feature config |
| Probing | 11 probing cycles (bore, boss, pocket, block, web, corner, rotation, vise corner, single surface) with parameter forms and result-to-WCS push |
| Tool Library (separate sidebar item) | Lists all RRF-configured tools with number, description, radius, status |
Webpack resolves junctions/symlinks to their real path. When ts-loader walks up the NeXT repo tree looking for tsconfig.json, it won't find one (it's in the DWC root, not here). The included ui/tsconfig.json solves this — it mirrors the DWC TypeScript config and maps @/* imports back to the DWC source tree. Don't delete it.
ui/
├── index.ts # Plugin entry point (re-exports src/index.ts)
├── plugin.json # DWC plugin manifest (id: "NeXT")
├── tsconfig.json # TS config for junction-based dev
├── package.json # Peer dependencies (three.js for 3D viewer)
└── src/
├── index.ts # Route + i18n + plugin data registration
├── NeXT.vue # Main dashboard component (3 tabs)
├── components/
│ ├── base/ # BaseComponent.vue — shared store access
│ ├── inputs/ # Input components (Phase 2.2)
│ ├── panels/ # Status, Config, Probing, Tool Mgmt panels
│ └── overrides/ # DWC component overrides (disabled by default)
├── locales/en.json # English translations
├── utils/ # Object model helpers, gcode utils
└── workers/ # Web worker for toolpath parsing
For detailed development workflow, see docs/UI_DEVELOPMENT.md.
- GCODE.md - Complete reference for all NeXT G-codes and M-codes
- docs/CALIBRATION.md - Comprehensive guide to machine calibration (steps-per-mm, backlash, probe deflection)
- docs/STOCK_PREPARATION.md - Stock preparation UI implementation approach and technical specifications
- docs/ROADMAP.md - Development roadmap and feature implementation plan
- docs/FEATURES.md - Feature requirements and implementation status
- docs/CODE.md - Coding standards and style guide for contributors
- docs/DEVELOPMENT.md - Development workflow and PR process
- docs/TESTING.md - Testing procedures and guidelines
See GCODE.md for a description of all NeXT implemented G- and M- codes.
NeXT is designed to work with a specific gcode dialect, designed for the Millennium Machines Milo. It does not support any other gcode dialects.
The following is an example gcode style that NeXT is designed to understand:
(Exported by Fusion360)
(Post Processor: Milo v1.5 by Millennium Machines, version: Unknown)
(Output Time: Thu, 05 Oct 2023 20:03:20 GMT)
(Begin preamble)
(Pass tool details to firmware)
M4000 P2 R1.5 S"3mm Flat Endmill F=1 L=12.0 CR=0.0"
M4000 P3 R3 S"6mm Flat Endmill F=1 L=20.0 CR=0.0"
(Home before start)
G28
(Movement Configuration)
G90
G21
G94
(Probe origin corner and save in WCS 3)
G6600 W3
(Switch to WCS 3)
G56
(Enable Variable Spindle Speed Control)
M7000 P2000 V100
(TC: 3mm Flat Endmill L=12)
T2
(Start spindle and wait for it to accelerate)
M3.9 S19000
(Begin operation adaptive2d: 2D Adaptive1)
(Move to starting position in Z)
G0 Z15.0
...
(Stop spindle and wait for it to decelerate)
M5.9
(End Job)
M0