I am carving a circular pocket. I have always used fusion 360 2D adaptive operation to do so along with the helix ramp type under the linking tab. Never had an issue with it but now the issue is, the machine would go to the center of the circle and then start doing its helical movements but every time the center of rotation changes so the hole is carved not where designed. Also, after the job when I hit return to zero the machine does not return to the initial zero. the zero is offset down just like the carved pocket. The video below shows the machine walking to the center of the desired pocket then slowing walking away and creating the pocket elsewhere. I zero the Z above the piece to intentionally cut air. Fusion 360 and gcode sender shows the simulation of the carving properly meaning that the helix is centered on the circular pocket and starts coming down on it.
I checked all the physical aspects as far as the machine goes and everything is perfectly fine that I can see. I got lead screws
If I keep the 2D adaptive but change the ramp type to Plunge then the circle pocket is carved where intended and more importantly the machine is able to return to its original zero when told to do so. I prefer to use helix over plunge since is less load on the tool.
What do you guys think is causing the issue?
1001.nc (841.0 KB)
Y_End_Plate_No_Nema(LEFT&RIGHT).f3d (330.5 KB)
You could be missing steps. You may need to check your calibration.
But looking at the video, I it’s possibly your generated g-code. Did you select a different post processor to what you normally use?
Thanks for your response, Kimberly.
I though that I was missing steps as well because my machine does not return to the original zero but is not something caused by machine components since other types of operations dont loose steps.
Post processor is the same as I have used before
Please post your *.nc-file so we could look at the gcode
Odd behaviour indeed, do the displayed work coordinates also show an offset when the bit have returned to the intended zero (but is physically offset aswell?
My main suspect would be the post processor also, an Arduino clone can also do “weird stuff”
In the first video there are some noises during the helix that makes me wonder.
It almost appears to me that maybe the initial helix clearing in the center is over running the belt tension and causing the axis to jump a tooth or something.
I have a lead screw system. The machine is not loosing steps physically but somehow in software.
I agree that this looks mechanical (or electrical). If your simulation looks ok, I’d start looking at what happens when you move the machine in all three axes at the same time, as it does in a helical ramp.
I attached the NC file to the original post. I will have a look at Gcode sender to see if it is showing home as home or as an offset.
I think you guys might be right and it might be an issue with the post processor. I will try an use the better post processor for GRBL on the web to replace the built in GRBL post processor in Fusion 360. It might also be my Arduino clone doing weird stuff, as you said. I will have to consider an upgrade. Having lots of reliability issues but I cant really figure if it is the Arduino or my PC. That’s another topic.
If it is mechanical how is it able to do the job intended if I choose the Plunge type?
I cant see anything wrong with the machine mechanically speaking. I will check electrical connections
Gcode looks fine.
Try moving your X,Y, & Z across your work area, simultaneously, to see if there are issues. A plunge is only Z, the pocket moves are X & Y, but the helical ramp is all three.
When I home the machine, it moves in all 3 axes simultaneously and dont see issues. I will create a quick file to move the machine around in all axis some more.
Also, Fusion 360 used to write the NC file so that the tool finish pocketing every circle before jumping to the next butnow is writing the code to jump around from circle to circle taking 1mm at the time.
It should home Z first and then X and Y together.
Can you share the Fusion file as well? I’ll take a look at your CAM settings.
What is the possibility of your lead screws being slightly loose enough to allow movement during the helical move, but tight enough to not show an issue during homing or single axis cutting?
id guess it’s losing steps due to heavy load of adaptive. the alter program does not require as much load so it’s able to stay the course. perhaps look at the adaptive and reduce the aggressiveness of the settings (lower stepover)
i’d be looking at your mechanical setup closely. either something is ‘off’ or you found your limit on these small machines. in either case it’s good to check over your machine periodically.
one way to check the machine is jogging it manually while forcibly (by hand with sound judgment) trying to hold it back. start with light pressure and increase to see if you feel or hear anything with each jog.
Perhaps try once with a small step over then a 2nd variant with 100% step over/larger end mill value, the pattern will create a wider helical motion for the plunge. If they behave the same then it is the software, if they are different yet the design is the same then it is the machine (steps) that are failing.
He loses steps on the helical ramp before the cutting starts.
Could you please provide some information of your motors, controller and GRBL parameters? Primarily $110-112 and $120-122
From the first video it appear that it won’t perform the Y-moments of the 4th helical quadrant, causing a incremental deviation. I think if he set step down to 200% he´d see a 200% increase in deviation aswell. Could be some funky harmonics causing the motor to loose sync.