Hi, I recently discovered the contour operation possibilities in the Pocket operation. I like the fact that it can produce 3d contours that follow the outline of the object being machined, this suits my purpose well. However, the resulting g-code produces quite alarming vibration in my machine. I have the feedrate for xy and Z set to 1800mm/min. However, observing the machine it can be seen to vary quite considerably in speed, mostly however proceeding at a rate far lower than 1800mm/min. Another file of this model generated by a different software, that has a similar cut pattern doesn’t produce this vibration and variation in feedrate. I’ve tried varying the different parameters such as refine, precision and smooth, but without success. The one thing I do notice is that the kirimoto file has very fine steps between moves - and is a much larger file. I don’t wish to attach the workspace file here, but I’ve emailed it to you.
I was going to suggest smoothing with the de-selection of the outer two rings, which complicate the paths and smoothing. It’s an imperfect thing being a finely faceted surface that is continuously variable. But certainly, also, an algorithm that I can continue to reifne. I think the jerkiness is something that could be addressable as firmware jerk/accel tweaks.
Hi Stewart, I tried the settings you suggested, Smooth = 5 and Refine = 10. But it didn’t make any change. One thing I’ve noticed in the g-code is that there are alternating lines of XY moves and then XYZ moves. All of the XY moves are hardly different than the proceeding XYZ Move, indeed the moves are much smaller than the resolution of my stepper motors (0.003mm/step). Could this be causing the stuttering? The distance between all the G1 moves is extremely small. On the image I uploaded it looks like there are 5 Z instructions before my stepper can even take one step.
How are the moves calculated? Is it a move for every vertex? or is it a raster laid over the geometry? If it is a raster would it be possible to reduce the fineness of the raster? I tried playing with the Precision but the resulting cut doesn’t follow the model at all well, for instance with 0.5mm Precision with Render->Solid selected, the resulting milling lines can be seen disappearing into the model.
Many thanks again for your incredible work and any help will be gratefully received!
I didn’t double-check, so only if I got this right on the first try: your example looks like about 24 lines of gcode to move 2mm. Feeding 1800mm/min would need about 100kbps from the sender and that’s practically equal to a common serial speed.
If you reduced feed by half, does it run more smoothly?
It looks like this example consists of alternating horizontal & vertical moves and dropping the X&Y components from the XYZ lines would reduce the data rate without changing the tool path.
Does the controller see this as a zillion 90deg corners? Stripping the XY-only lines would eliminate false corners but probably wouldn’t be safe in all cases.
Sorry - that was more than I thought I was going to write.
Hi @pmc, Thanks for your observations. Yes, in this case the xy moves are all superfluous, the difference from the proceeding move being way less than one step on my machine. But even removing those, there are still far too many moves. I tried your suggestion of feeding at half the rate, but it didn’t make any difference.
In any case, I think the problem lies with the mass of data being produced for such a small amount of distance.