A better Fusion360 - GRBL PostProcessor

If you are using Fusion360 for your designs, and carve them on a GRBL based machine, then take a look at

https://github.com/Strooom/GRBL-Post-Processor

I took the existing GRBL PostProcessor and cleaned it up to make it better.
If you have a Makita RT0700 or Dewalt 611 or similar, it also translates the spindle speeds to a dial setting.
If you make mistakes in your design, the post-processor will alert you and recommmend how to solve them.

It’s free, documented, feedback & test-results are welcome.

7 Likes

I’m working in Fusion, but using Easel as my gcode sender - would be interested in a version of this with the Easel compatibility mods.

I downloaded the f360-easel.cps.
It is also based upon the generic grbl post-processor, with similar changes to remove 5-axis, tool-compensation, etc.
At first looks I think the above post-processor should work with Easel.
I’ll compare it with my PostProcessor to see if there are additional features and try to merge them.

1 Like

Hi there I’m building a plasma cutter CNC. And new to all of this but am I understanding that you can go from fusion 360 street to G shield without going through easel and if that’s my understanding how do you do it ?

Yes,
to explain step by step this is what you do:

  1. Make a design in Fusion360 (Model environment)
  2. Convert design into CAM operations in Fusion360 (CAM environment)
  3. ‘Post’ the operations to one or more GCode files : ‘Posting’ is just another word for exporting the CAM operations to GCode files.
  4. Send the GCode files to your machine, using one or another GCode sender software, eg UGCS…

I have not used Easel before, but as far as I understand it, it tries to do all the above in 1 software. This may sound simpler, but at the same time it restricts your possibilities as the CAD and the CAM are much more limited compared to what you can do in Fusion360.

2 Likes

Thank you so much I didn’t have universal Goode sender installed. Works great. Thanks again :grinning:

I am doing the above steps 1 to 3.
However for step 4 I open up Easel and use the import g-code command. I then run the cut from Easel.
I have a Carvey and Easel takes care of the height sensor (with the smart clamp).

1 Like

Would be great to include Laser Mode in the post processor.

2 Likes

Are you still keeping up with his? Are you updating it do utilize parts from the latest GRBL releases? I’d be interested in chatting with you as I have some ideas I want to to to modify GRBL but I’m kinda new to all of this and your compiled version is almost exactly the path I wanted to take.

Hi Alexander,

I could do some small extra’s but for the time being there is nothing on my todo list yet.
I am not running GRBL V1.1 (Still on V0.9).
I am spending most of my development time in building a new CNC Controller which should be an ‘upgrade’ from GRBL.
The basics are now working (GCode interpreter, motionBuffer, real-time stepping) but of course there is still a lot of work to do (feed-hold, park, homing, limit switches, etc) I knew this was not going to take months. You can read more about it on GitHub - Strooom/Moovr: Motion Controller SW for CNC, LaserCutter, 3DPrinter

Hey,

First thank you so much for this GRBL processor ! It sorted so many of my issues !
But I noticed a little problem (may be only for me)
When I start a job, tool on 0 work, the tool is not retracted and drag on the piece on the way to start the job.

I can read in my Gcode at the begining of the job: G53 G0 Z10
Investigating your processor and I think my issue come from:
writeBlock(gFormat.format(53), gMotionModal.format(0), “Z” + xyzFormat.format(properties.machineHomeZ))

My home Z is -10 so when I start the job it drop the tools by -10…
I don’t know the language of the processor but is it possible to use the absolute value of xyzFormat.format(properties.machineHomeZ) ?
So Z + Absolute value of Z home ?

Thank you for your help

I am also having this issue (dragging). And I also have another issue where my Z axis tries to go above the limit before starting the job. It looks like it is trying to home the Z axis before starting but for some reason it wants to go above the limit set by the homing routine. This happens with soft limits off.

Anyone having this issue too?

@KikoLobo, @SiroSimo

It is the intention to move the Z-axis up (to its home Z-level) before moving X and Y to the start of the first operation.
This is done with a move in machine coordinates, using the G53

If your home Z is -10, the initial move should be G53 G0 Z-10

Note that the home coordinates can be set in the Fusion Post-Processor Dialog Box : maybe you don’t have the right settings there…

Further, make sure your controller is able to perform G53. GRBL does this.

Finally I noticed once this problem myself, and the reason was the GCode sender:
The G53 is a so-called non-modal command, this means it is only effective for the line (block) in which it is found…
This means that for a command G53 G0 Z-10, all three words have to be on the same line. For some (unknown) reason I found that some GCode senders, split this command over several lines but this will change the meaning ! The G53 will no longer be active and so the machine will move to work-coordinates Z -10 io machine coordinates Z -10.

I had this problem with the UGCS Platform 2.0
For the time being I am using UGCS 1.0.9 which does the line breaks correctly.
You can find this software here : GitHub - winder/Universal-G-Code-Sender: A cross-platform G-Code sender for GRBL, Smoothieware, TinyG and G2core.

Please read Anatomy of output of the Post Processor · Strooom/GRBL-Post-Processor Wiki · GitHub where I documented how the post-processor (should) work.

Thank you for your response.

I am investigating about the GCode sender. I am using CNCJS… And have posted an issue in their GitHub page.

This is what my issue looks like:

I didn’t find the home setting in F360. Do you mean the origin? If yes… I did set it up. Unless I am doing something wrong.

See Screenshot:

No I don’t mean the work-coordinates origin.
For your machine you can define a ‘home’ position, where the spindle returns after the job.
Your workpiece in Fusion does not define this, so I added 3 parameters in the parameter section of the Post dialog box.

See Documentation · Strooom/GRBL-Post-Processor Wiki · GitHub

It is the same MachineHomeZ that controls to wher your spindle is raised at the beginning of the job.
With GRBL this Machine Home is in negative machine coordinates, typically a few mm from each limit switch.

Is your version the same as the one that distributes Inventables thru easel?

What are the diference ? Just curious?

Depends on the version. It’s a compile time option.

Let’s assume latest version of both…

I think the issue is with CNCJS and the way it send the G53 command… After starting the program, this appeared in the terminal screen from the X-Controller:

@KikoLobo Posting this here as well:
That error is likely from a tool change (M6) command. I remove them manually when using cncjs,but you can ignore it (as long as you are comfortable with that error).
The easel post has a 15mm Z-lift after going to a starting XY. Based on your video, you don’t have room for that. Your starting Z-height is only 7.4mm down from your max Z. There really shouldn’t be a reference to G53 in your code at all. Did you look at the g-code and see a G53 somewhere? G53 refers to the absolute machine coordinates. All of your work is done in your WCS, or Work coordinate system.
Try the default grbl post as it will lift to a height set by your CAM operation in Fusion, a combination of “Clearance Height” and “Retract Height” depending on how you have those set up. Your ramping settings could cause those to change as well.
Basically, that foam is too thick for your current settings and setup.