I’m having issues with toolpaths not running as they were generated in CAM. I have tried to cut 2 parts now with similar results. In Fusion’s CAM environment the toolpath shown honors the settings I’ve programmed. ie maximum stepdown is 0.5mm which results in 7 passes through the 1/8" aluminium plate. When I run the code on my machine it finishes the pocketing op just fine with the stepdown matching the simulation. However, when it comes to cutting the part out using the 2D contour it ramps down to almost the full depth for the whole operation over the first 20 or so mm of the cut. Goodbye endmill. :’(
It looks as though this is a post processor problem. I’m using the grbl post in fusion with G28 safe retracts off. However, I find it a bit odd that the other operations I’ve tried proceed correctly at the programmed stepdown/number of passes/depth but the contour path doesn’t. All this is relatively new to me so I could have done something foolish but I’m at a loss when it comes to editing post configurations and I’m not too sure where to look for things that could cause DOC problems in the post config.
Aside from turning off G28 safe retracts is there anything else I need to edit in the post to make sure somoothie gives me exactly the toolpath I see in Fusion’s CAM simulation?
If any further info should be required for effective troubleshooting I’d be happy to provide it. If anyone has an edited and fully functional post for Fusion that works flawlessly or any clues where I could be going wrong advice would be gratefully received.
Try running the gcode through a simulator. One way to test after editing the post before trying the code on actual machine. There are a few available and I sometimes use this one https://ncviewer.com
Thanks, Jim. Fusion has a built in simulator which I ran the code through and all checks out there, 7 passes shown as I programmed. Of course fusion doesn’t know what firmware I’m using though, does NC viewer have a machine configuration option the will allow me to select smoothieware’s gcode flavour? I’ll give this a try and see what the toolpath looks like in there and report my findings. Thanks for your suggestion.
Here’s what it actually cut on those perimeter cuts. Much deeper than the 0.5mm max stepdown I programmed. The deepest part of that gauge it took is 2mm, not at all what I asked for and not what’s programmed. My calibration is spot on, measured by dial micrometer so I know my steps/mm is fine. It’s seems to be smoothies interpretation of the gcode for this specific op that’s the issue. The holes for the pocketing op proceed as programmed.
The fusion simulator simulates based on the internal paths, not based on the G-code as generated by the post-processor, so it’s useless in this specific issue.
Can you try narrowing things down to one or more Gcode that repeatably doesn’t do what you expect?
Fusion’s Smoothie post-processor isn’t perfect, I’ve been improving it locally but can’t share the new version right now as it’s on-going work to support automated tool change.
Thanks, @Jim_Fong . I’ll put the post below for peoples perusal.
@Arthur_Wolf Yes I know fusions simulation is no indication that the gcode will run the same but I have put it through nc viewer after posting from fusion and the path is the same with the correct number of passes. I’ve used the grbl post in fusion, not the smoothie laser/mill one as that was giving me problems putting G28s in there. I suspect there’s an issue with how fusion’s grbl post is translating the toolpaths and smoothie just isn’t understanding it correctly. If I can identify the problem maybe I can edit the post accordingly.
I’ll post the first few lines of Gcode for the 2d contour operation below disaster strikes early on so I’m sure you’ll be able to spot what’s up pretty quickly.
You definitely don’t want to be using the grbl post. Open the smoothie
post, search for “28” and comment out ( add “//” at the beginning ) the
line that outputs the G28. Then save, and try again.
If you still got problems, then you need to narrow down the part of the
file that doesn’t behave as expected down to a few Gcodes. I know it’s a
bit of work but it’s the only way we can help.
