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.
Any help much appreciated.
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:
G1 Z-0.25 F15.
G3 X-9.8211 Y3.4733 I5.4018 J-14.3948 F20.
Makes a left handed cut
G1 X-11.3539 Y5.1208
G2 X-5.7121 Y8.5726 I11.8276 J-13.0725
Also makes a left handed cut.
It is very bizarre behavior. If anyone has any ideas on this, I’m all ears.
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!
Do you have a .nc file that will let others replicate what you are seeing?
If this can be replicated, then an issue should be opened on GitHub.
Should I just post a link to the .nc file ? or copy and paste the code ?
A link, or upload the file here. Will do some runs in fake server mode and see if I can catch something.
See attached. This drops out about 10th of the way around a circle.
three piece cut.nc (17.7 KB)
FW/GC on v1.25?
Can you post a screenshot of the position in the circle, please?
The Bahrain branch of Maslow .nc forensics has no F360 and no clue, but a unconfirmed theory.
The file runs/opens in:
- GroundControl (fake server)
GroundControl log file:
- no evidence of failure
- 6 x ‘Large-radius arc replaced by straight line to improve accuracy’
- unveiled unnecessary Z-moves
- a strange “Ramp?”
- a clean picture of the ‘Ramp’ or whatever that is
- 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?
– micro moves:
The Maslow receives instructions to move 0.602mm with a series of 10 or 11 steps, each ~ 0.094mm.
- while camotics and bcnc show no visual ‘distortion’, GC has an issue with the Ramps on display:
- screenshot of terminal and log of the position AFTER the software seems to go nuts
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!
Compare the g-code and see if it has the same mirco-moves.
If it does, I’m barking up the wrong tree.
Any how, it could be worth checking the preferences for a ‘General Tolerance’ setting and adjust that 0.1mm or so.
G1 X218.831 Z-3.993
G1 X218.74 Z-3.971
G1 X218.653 Z-3.935
G1 X218.572 Z-3.885
G1 X218.501 Z-3.824
G1 X218.44 Z-3.753
G1 X218.39 Z-3.672
G1 X218.354 Z-3.585
G1 X218.332 Z-3.494
G1 X218.325 Z-3.4
Look and the distances asked to move.
This requests on X and Z is not something that should be in a g-code for Maslow I think.
Also worth checking might be why you have dots without following digits:
G1 Z2 F800.
G1 Z1 F30.
I don’t think that this could make the software insane, but what do I know. It would just look cleaner
This is the two codes compared…
The right hand one works.
That breaks my theory.
Does it look the same ‘spiralling’ as in my GC screenshot?
One thing that stands out is the lack of y position in the code that doesn’t work…
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.
Check this thread to see if you are having the same difficulties: https://forums.maslowcnc.com/t/corrupted-firmware-groundcontrol-using-different-versions-weird-g2-g3-cuts/7527/23
I hope this helps!
That sounds like that could be exactly what my problem is!
I’ll try on Monday.