I have setup my lowrider for Zero Probe to be the corner of my table.
I have setup G56 location of my work piece.
When I set WCS to 3 in fusion it never updates the gcode to relocate to G56 after probing.
Has anyone else tried this?
Is the post processor capable of accepting the WCS setting from fusion?
I am at a loss….
Has development of this stopped?
I am looking into making a change to include the WCS info but not sure where it needs to go.
I did locate this grbl.cps
grbl.zip (19.9 KB)
No development hasn’t stopped but it is not actively happening as I’ve heard of no issues. That said, I’m interested in understanding issues.
If you are going to look at the pp, make sure you use the zip at the top of this thread - I’m not sure what GRBL.zip contains.
To determine if the problem you are describing is a pp issue, do the following. Create the simplest F360 project you can that has the issue then enable the debug comment level. This should show you detailed information to help you understand what the pp is receiving and doing.
If you isolate a problem, post the relevant part of the debug output that is wrong and then your expected results.
The pp is basically a formatter, it doesn’t interpret the GCode (other than the enhancements documented). Offsetting by a coordinate position I would assume would be done by F360 prior to the pp being pasted the operation to be output - though I could be wrong.
After further review:
What you’re describing points to two related gaps in the PP:
WCS support is on my radar as a future enhancement. If others are using multiple WCS offsets, please chime in — it’ll help prioritize.
Unfortunately, at this time I can’t commit to a timeline to make these changes but will add it to my list of things to do
Follow-up for those interested in Work Coordinate’s.
I set 3 locations at Terminal Mode:
Zero Table
G54 (Corner of table)
Move to location
G10 L20 P1 X0 Y0 Z0
Save the config: $CD=Config.yaml
Zero Table
G55 (Tool change location)
Moved to location
G10 L20 P2 X0 Y0 Z0
$CD=Config.yaml
Zero Table
G65 (1st Work Location)
G10 L20 P3 X0 Y0 Z0
$CD=Config.yaml
To use the locations, Set the location you want to use.
Tool Change
G55
Now issue G90 X0 Y0 Z0 (G90-Fast move)
Now if i can figure out how to change the Modes Buttons, it could be a quick way of getting around.
Is this post processor only for marlin based boards? I’m trying to use it with a Jackpot 1 board, and getting some errors. Just want to make sure I’m doing the right things, but I’m very new to CNC. Thank you!
. . .
I missed that one. Thank you!
Update
MPCNC V4.0 (Beta 1) is now available — see MPCNC v4.0 (Beta 1) is Available.
Note that V4.0B1 is experimental and has not yet been run/tested.
V3.0 (Beta 3) remains the stable release — stay on it if you need something known-good.
Carried over from the standalone “V4.0 (Beta 1)” thread, consolidating all releases into this thread.
Please read first — Very minimal testing done
V4.0 (Beta 1) has had minimal debugging and only a few sample jobs run.
The post-processors code was hardened and had new features added, with
the assistance of Claude Code (an AI coding tool). Every change was reviewed
before being accepted — but reviewing a change is very different from executing it.
JavaScript only fails when the code actually runs, and this code has not had all
possible execution paths exercised.Treat this as experimental. V3.0 (Beta 3) remains the last stable release!
Use V3.0 (Beta 3) if you need something known to work. All V4.0 (Beta 1)
feedback is very welcome; that is exactly what this beta is for.
This release continues from V3.0 (Beta 3). It is a substantial hardening
release: the post was put through two full review passes — one for general
code quality and one for Fusion 360 post-processor compliance — plus a
targeted fix pass. The result adds several capabilities and fixes a number
of latent issues (all reviewed, but only a few samples run).
What’s new since V3.0 (Beta 3):
The file has been renamed to MPCNC_v4.0_Beta1.cps to match the version.
Detailed review/change notes are in the docs/ folder of the repository.
This is BETA, un-executed code.
Review all generated GCode carefully before running it on your machine.
Use at your own risk.
Installation:
Unzip MPCNC_v4.0_Beta1.zip and install the extracted
MPCNC_v4.0_Beta1.cps using the F360 Post-Processor setup dialog. Use the
Job: CNC Firmware property to select your controller (Marlin 2.x,
GRBL 1.1, or RepRap/Duet).
If you want a known-good post, stay on V3.0 (Beta 3).
Please post successes and errors/issues to this thread. Given this build has
not been run yet, early real-world reports are especially valuable.
MPCNC_v4.0_Beta1.zip (16.6 KB)
Carried over from the standalone “V4.0 (Beta 2)” thread, consolidating all releases into this thread.
V4.0 (Beta 2) has been reviewed by a human and AI, had many gcode files produced and reviewed, but never cut anything.
The post-processor’s code was hardened and had new features added with the assistance of Claude Code (an AI coding tool). Every change was reviewed before being accepted.
Unlike Beta 1, this build has been exercised: real jobs were posted out of Fusion 360, and the resulting G-code read line by line — across GRBL, Marlin and RepRap, in both mm and inch, with over 80 different checks performed.
Two full review passes were run against it, one aimed squarely at the everyday hobbyist job. Neither found the default hobbyist single-operation job broken. (Hobbyists review property group 03 as defaults may not be appropriate)
What has not happened is anyone cutting with it. No dry runs, no test cuts, no hardware verification of any kind. The multi-fixture and tool-change workflows are the least exercised parts of the release. Treat this release as well reviewed, tested, but experimental.
V3.0 (Beta 3) remains the last stable release!
Use V3.0 (Beta 3) if you need something known to work. All V4.0 (Beta 2) feedback is very welcome; that is exactly what this beta is for.
This release continues from V4.0 (Beta 1). Where Beta 1 was a hardening pass, Beta 2 adds a real coordinate model. Beta 1 knew one zero — wherever the tool happened to be when the job started. Beta 2 can keep track of several: the machine, the spoilboard, and each part.
What’s new since V4.0 (Beta 1):
If you are upgrading from Beta 1:
This is BETA code that has never been run on a machine.
Review all generated GCode carefully before running it on your machine. Use at your own risk.
Installation:
Configuration:
Please reply to this thread if you choose to use the post processor.
Post successes and errors/issues to this thread.
Early real-world reports are especially valuable — particularly from anyone trying the multi-fixture paths or any unexpected issues with generating a simple post.
MPCNC_v4.0_Beta2.zip (46.5 KB)
Carried over from the standalone “v4.0 Beta 3” thread, consolidating all releases into this thread.
v4.0 Beta 3 of the Fusion 360 post processor for MPCNC, LowRider and similar GRBL / Marlin / RepRap machines is available
Download MPCNC_v4.0_Beta3.cps · Release page · Release notes
Overview and install · Hobby Guide · Pro Guide
1. Delete your old copy of the post first. The file is now `MPCNC_v4.0_Beta3.cps`. Fusion identifies a post by its filename, so Beta 3 installs beside Beta 2 rather than replacing it, and the two are nearly impossible to tell apart in the picker.
2. Your saved settings will not carry over. Every property key in the dialog was renamed, so a Beta 2 preset falls back to its shipped default on every setting — silently, with no warning. Walk the dialog once before you post, and look hardest at groups 4, 5 and 6, which changed in meaning as well as in name.
GRBL: the % wrapper is gone. Beta 2 wrapped GRBL files in %, which stock Grbl 1.1 has no such feature for.
The post no longer crashes on the second job of a Fusion session.
No more dragging the bit across your work on the way to an offset probe. It retracts first.
Settings no longer leak from one post into the next — a second job used to inherit the first job’s feedrate settings.
Marlin can do multi-part work offsets now. Beta 2 refused these, on the belief that Marlin had no work-offset registers. It has them, under the CNC_COORDINATE_SYSTEMS build option.
Tool changes were rebuilt. A multi-tool job is refused by default rather than posted with its tool changes quietly dropped. You choose who performs the change and who corrects Z0 for the new tool’s length.
Travel Speed X/Y and Travel Speed Z do nothing on GRBL. Its planner takes a rapid’s rate from $110–$112, not from the F word in the block. The file now tells you so instead of leaving you wondering why the machine ignored the setting.
Plus a long list of clearer warnings, and jobs are now refused before a file is written rather than posted in a state that would crash your machine.
V4.0 Beta 3 is the first release with an automated regression suite behind it: 190 cases across six property matrices, posting 42 job files through Autodesk’s own post engine and reading the emitted g-code back to check it against the toolpath Fusion asked for — all 190 passing, with every setting in the dialog exercised.
Two limits are worth knowing:
Differences in firmware behaviour were resolved by reading each firmware’s source code and change log, citing file and version, rather than by running gcode through different controllers.
Each change to the post-processor was automatically tested through a harness that utilized Autodesk’s intermediate files and their headless post processor. Testing forced a candidate post-processor to process 190 different g-code files, each automatically compared to expected results by an AI engine. Only a few dozen CAM files were manually created in Fusion and posted to generate G-code.
This is still a beta. While the author has made his best efforts to ensure it is correct, user feedback is required before the Beta tag is removed. Review your g-code before you cut.
If you find an issue, you can post it here or, better yet, directly on the Issues Page of the mpcnc_post_processor in GitHub.
v4.1 Beta 3 of the Fusion 360 post processor for MPCNC, LowRider and similar GRBL / Marlin / RepRap machines is available
Download MPCNC_v4.1_Beta3.cps · Release page · Release notes
Overview and install · Hobby Guide · Pro Guide
One thing changed, and it answers GitHub Repository - Spindle Control? ·(Issue #16): the router power, laser and each coolant channel can now name the fan or pin output used to control them. Before, the router could only be prompted for by hand or commanded with M3, the laser could only use fan 0, and coolant could only use one of two pin numbers someone chose in 2018. You now have the ability to specify the fan or pin directly.
1. Delete your old copy of the post first. The file is now named MPCNC_v4.1_Beta3.cps. Fusion identifies a post by its filename, so this installs beside existing versions of the post instead of replacing the old version.
2. Three settings return to their defaults. The router defaults to asking you to switch it on, and all four coolant codes default to GRBL’s M7 / M8 / M9. A job posts the same file it did in v4.0 Beta 3 unless you choose otherwise with one exceptions below.
Manual Spindle On/Off is now Spindle Control, with four choices:
Prompt the operator (M0) — the default, the post sends no spindle code and stops to ask you.
Spindle - M3 S{RPM}/M5 — what a disable checkbox did previously.
Fan - M106 P{n} S255/S0 — for a relay wired to a fan header.
Pin - M42 P{pin} S255/S0 — for a relay on a spare output pin.
The Fan and Pin options are the change for this release. Note: if using M3 on Marlin you must have a build compiled with the options SPINDLE_FEATURE / LASER_FEATURE.
Both Fan and Pin are on-or-off only: no speed, no direction. The RPM your job asks for goes into a comment, and the file says it was requested rather than commanded — including at every mid-job speed change, so nothing is silently ignored.
The Marlin/RepRap fan mode was firing the wrong fan. It was sending M106 with no fan number, and Marlin reads a missing fan number as fan 0. So if your laser was on any fan but 0, it was never fired, and fan 0 was driven at laser power instead. The off code was M107, which on RepRap firmware turns off the current tool’s fans rather than the one you named.
It now sends M106 P{n} S{power} and M106 P{n} S0, with the fan number from the new Laser: Pin/Fan # field. M107 is gone from the post entirely.
Coolant choices for Marlin were M42 P6 S255 and M42 P11 S255, with the pin number hardcoded into the choice. Those two numbers are RAMPS numbers — the servo header. On a Rambo, the board V1 shipped for the MPCNC, pin 6 is HEATER_2 and pin 11 is Y_MIN, and Marlin refuses M42 on both as protected pins — so the coolant never switched, and nothing in the file said so.
Each channel now names its own output, through Channel A Pin/Fan # and Channel B Pin/Fan #, and the fan form is offered beside the pin form. The GRBL defaults did not move.
Pin/Fan # appears in all three groups now, and what the number is depends on the mode and your firmware: a fan index or a board pin on Marlin, a fan number or a GpOut port on RepRapFirmware. Re-check it whenever you change either. A wrong number is not equally visible on the two — RepRapFirmware says “Fan number not found”, while Marlin just returns and says nothing, so the router never starts and the job cuts with a dead spindle.
Two conditions on the pin mode specifically, both Marlin: M42 is only compiled in where DIRECT_PIN_CONTROL is enabled, which stock Marlin ships commented out; and Marlin refuses M42 on a protected pin, which every fan pin is. So use the fan mode for a fan header and the pin mode for a spare output — the pin mode cannot reach a fan header at all.
The post now stops before writing a file if:
A fan or pin output is chosen for the router or the laser on a GRBL job. GRBL has neither command and answers error:20, which would stops the job with the tool in the cut. The coolant channels warn instead of refusing, on purpose — their labels say which firmware the code shipped for, not that no other firmware takes it.
The pin mode is chosen and Pin/Fan # is still 0. Pin 0 is nobody’s router. Fan 0 is a real fan, and is allowed.
A coolant channel is switched on with one form and off with the other, which would leave the output running for the rest of the job. If on uses a Pin, so must off.
Since v4.0-Beta3, testing has used an automated test suite. The regression suite now has 207 test cases across six property matrices that drive changes in property settings. All passed, including the 17 added for this update.
The two facts still hold true with respect to test cases:
Differences in firmware behaviour were resolved by reading each firmware’s source code and change log, rather than by running g-code through different controllers. For example, the tests did not switch any relay using different firmware to confirm that pin operations work.
The test suite drives Autodesk’s own headless post engine over both their standard intermediate test files and a series of custom files. The post processor’s dialog itself is never exercised by the regression test suite, but Fusion’s property panel is visually checked, but not for every test scenario.
This is still a beta. While the author has made his best efforts to ensure it is correct, user feedback is required before the Beta tag is removed. Review your g-code before you cut.
If you find an issue, you can post it here or, better yet, directly on the Issues Page of the mpcnc_post_processor in GitHub.
This is now the de facto thread to discuss the flyfisher604/mpcnc_post_processor used for generating GRBL, Marlin or RepRap GCode from designs done in AutoCad’s Fusion 360 that target the LowRider, MPCNC, or similar machines.
All announcements of new versions will be posted to this thread. Users are also encouraged to post any questions or comments here.
**Find general information and documentation here:
GitHub Repository and Install Information
Hobbyist Guide · Pro Guide · Property Reference GuideIf you find an issue, you can post it here or, better yet, directly on the Issues Page of the mpcnc_post_processor in GitHub.
v4.1.1 Beta 3 of the Fusion 360 post processor for MPCNC, LowRider and similar GRBL / Marlin / RepRap / FluidNC machines is available
Download MPCNC_v4.1.1_Beta3.cps · Release page · Release notes
Overview and install · Hobby Guide · Pro Guide
v4.1.1 Beta 3 is a minor enhancement that adds further support for FluidNC, by no longer rejecting M6 (toolchanges), and simplifies the properties dialog by reducing the number of fields from 65 to 57.
The post was previously telling FluidNC operators that their firmware rejects M6, which was not true. M6 actually dispatches to the tool changer declared as atc: under the spindle or the macro named by m6_macro: in config.yaml. Three separate texts said otherwise; all three now limit that warning to stock Grbl and grblHAL, which are the ones that reject it.
Tool Change Handled By gains a FluidNC — T + M6 value, and it warns about the thing that actually is a risk: a sender that strips the M6 takes away the token FluidNC acts on. And where neither atc: nor m6_macro: is declared, the firmware accepts the line, changes nothing and reports nothing — the post cannot read your config.yaml, so it says so rather than assuming. A changer needs FluidNC 3.9.0 or later.
Three warnings also previously named settings FluidNC did not have. Each now names the settings appropriately for FluidNC:
the idle timer is $1 or idle_ms under FluidNC’s stepping:. A value of 255 means stay energised on both, and it is already FluidNC’s default.
the homing pull-off is $27 or pulloff_mm under FluidNC (which is per motor rather than per axis).
where Grbl needs a rebuild with HOMING_FORCE_SET_ORIGIN, FluidNC needs an mpos_mm that accounts for the pull-off.
The hazard is the same on both firmwares. Only the remedy differs, and now the warning says what is required for FluidNC.
Six places asked two or three questions to settle one thing. Each is now one field:
| Now one field | Was |
|---|---|
| Line #s | Enable Line #s, First Line #, Line # Increment |
| Probe X Y Offset | Probe X Offset, Probe Y Offset |
| Safe Z | Safe Z, and group 3’s Safe Z to Rapid |
| Manual Position X Y | Manual Position X, Manual Position Y |
| Laser Output | Laser: Marlin/Reprap Mode, Laser: GRBL Mode |
| Channel A / B Output | Turn Channel A/B On and Turn Channel A/B Off |
No functionality was removed from the post. What went were states the dialog could express and no machine could use — X without Y, an increment for numbers no file would carry, a laser field never read for the firmware selected, and off fields that could name a different output than the on fields did.
The two X/Y fields now take two numbers and a comma — -10, -400.
1. Delete your old copy of the post first. The file is MPCNC_v4.1.1_Beta3.cps, so it installs beside v4.1 Beta 3 rather than replacing it.
2. Four properties reset to their defaults — Line #s, Probe X Y Offset, Manual Position X Y and Laser Output. The coolant channel outputs and Safe Z keep whatever you had set.
3. If you cut with a laser, set Laser Output before you post. The post warns if the selected Laser mode doesn’t match the GCode variant selected. Milling jobs are unaffected.
The coolant properties have been simplified — you say what to output based on your GCode and your machine’s capabilities, where previously you had to configure both on and off.
The off code is now derived from the on code and has no field of its own: M106 and M42 close on the same output with S0, M7 and M8 close with M9, and Use custom closes from the channel’s own Off file.
The regression suite is at 222 cases across six matrices, all passing, up from 207. Every property change had to be witnessed twice — that the new field does what the old ones did, and that the state it deleted is really gone.
The two standing limits have not moved, and one of them matters more this time:
Firmware behaviour is settled by reading each firmware’s own source and change log, citing file and version — FluidNC 3.9.6, grbl 1.1h, Marlin bugfix-2.1.x, RepRapFirmware 3.5.
The suite drives Autodesk’s headless post engine over their intermediate files and sets properties on the command line. The Fusion dialog itself is never exercised — and this release is almost entirely a change to the dialog. How these six fields read in the property panel is the one thing the automated integration test cannot check.
This is still a beta: review your g-code before you cut.
If a setting reads wrong, a folded property field does not take what you expect, or the gcode generated is not correct, you can post it here with your settings, or better yet, post the issue to the Issues Page of the mpcnc_post_processor in GitHub.