I have had a bit of a frustrating time with fusion 360 creating g-code paths that drop out after about 5-10 seconds. What I have worked out is that the ‘milling direction’ settings need to be different depending whether I am cutting curves or straight lines.
If it is straight lines the direction needs to be set to right (conventional milling) and if it is curves it needs to be set to left left (climb milling) otherwise it drops out after a short period. If I do as described above they all cut fine. The problem therefore comes when I need to cut shapes with curves as well as straight lines (i know, how dare I) Oddly, changing the settings for curves doesn’t actually change the direction of cut…but it does for straight lines.
I am using the Maslow Post Processor and have also used the GRBL settings but get similar results with both.
Mark, Can you describe what you mean by paths that “drop-out”.
I recently exported Gcode form Fusion 360 (cutting curves) and sometimes when passing past the zero of the ‘y’ axis, Maslow turns around and starts cutting something entirely different in the opposite direction of the path on screen, even though the path and direction are clear on the screen. Are you experiencing the same thing?
I was already using Left milling when I had this problem unlike you, right milling does not solve the problem.
The problem I am having seems to stem from the way Ground Control is processing G2 and G3 commands. Sometimes a G2 cut will make a right handed arc, but other times it reverses direction and starts cutting an arc to the left without warning. When this happens, Ground Control throws an error stating that the sled is not keeping up with the software.
Here are some snips from my recent GCode as an example:
Does sound like the problems might be related. By ‘drop out’ I mean the cut will start, get about 3 - 5 seconds in and then drop about 5mm and ground control will give a message that the sled if not keeping up…because it has stopped.
As I say, ‘left hand’ arcs work fine and right hand straight lines also. It has previously cut shapes that are fine with both as well… PLEASE HELP!
unveiled ‘MICRO MOVES’ within the now just called so ‘Ramps’.
the position of the Ramps with micro-moves is exactly after where the software goes nuts.
Could the read ahead buffer cause a failure ahead of the sled position?
Conclusion:
The error could not be replicated in Fake Server mode.
The .nc forensic officer on duty seems to remember that series of mico-moves made the software go wild.
To narrow this down, perhaps the removal of the Ramps could give more clues.
Replicating the error on an actual machine (no bit needed, dry run) would help a big part.
I’ll run it shortly to show the result. It’s worth reminding that with the ‘milling direction’ changed from right to left, this will cut with no difficulties…i’m not sure what difference that makes to the code but still cuts in the same direction on either setting!
What version of Ground control and Maslow Firmware are you running? There was an error in v1.24 that was causing G2 code to run as G3. Which essentially means Maslow cut all arcs as left hand arcs. The update to 1.25 solved this error.
PLEASE HELP!
