Duet speed hunting...
I've recently put a 3 to 1 reduction on my polar bed motor for better acceleration and am now getting co-ordinated hunting in the stepper speed of both the bed and extruder. Was wondering if there is a max stepper frequency that I may be saturating. Im running 40deg / sec at 960 steps per degree (16 microstepps). It seems to run fine for the bed alone but starts to hunt when actually printing...
Which Duet are you using, and what is the minimum radius at which you print?
CNCModeller last edited by CNCModeller
@dc42 it says duetwifi v1.02 on the board but it's an Ethernet board. I'm having issues doing a test print at 300mm dia see video link below. I Want to be able to print down to a dia of 50mm, albeit r min is set to 0 at the moment to support calibration after a bed axis bearing and stepper drivetrain upgrade. Bed max print diameter is 600mm.
Any thoughts would be much appreciated.
What was the GCode command that you executed in that video? Can you do another video that shows the movement of the print head too?
At 50mm radius the effective steps/mm for movement tangential to the bed will be 960 * 360/(2 * pi * 50) = 1100. At 50mm/sec that's 55kHz step frequency, which should be OK.
Please post your config.g file.
@dc42 The radius carriage is static as it's just printing a 300mm dia thin wall cylinder which printed fine on the old setup.
See the first few seconds of this video to see what I'm printing. It's the same code file running on the old setup.
The only subtle change to the config file is that I'm actually using a step per degree of 961.33333 instead of 960 which is 3x320 that was used previously on the ungeared setup. Not sure if using a non integer increases the processing workload.
The 961.3333 is because I haven't got the tension quite right on the drive belt and I think it's having an effect similar to that of a harmonic drive effectively changing the 720t gear size by one tooth. It's an effect I've seen before but haven't managed to tune out yet on this drive config.
Will post gcode and config tonight if that is still useful.
@dc42 Update - Sorry its been a while have has car trouble...!
So the issue with the weird steps per degree was down to belt tension, that's resolved now.
This is my config file it's pretty simple.config.g
Unfortunately the Gcode file is 43meg so I cant upload it.
I've just generated code for the first 20mm of the part in S3D and here's just the base, the full test print is 1100mm tall. Its a spiral thin wall print.
The printer struggles on the brim radially from where the wall stiffeners are, and also on the main part wall when running above 125%. The printer will run faster but stutters quite a lot. The previous video link is still representative.
As an aside it also looks like the max deg/sec limit on the bed doesn't work when doing relative rotational moves, i.e. +120deg. Is this normal? I think the limit is working for normal operation.
Any thoughts would be much appreciated.
I've finally got back into the workshop and am still having this issue, having done much more digging and tried Cura as well as S3D for slicing I'm getting a better picture of whats going on.
The print stutters in a couple of places, one where the brim gcode is "complicated" which I kind of get but the other is during a clean ark on the print wall. More interestingly it seems that the stuttering is more prominent when the movement is at print max / min y axis rather than the x, i.e. the top and bottom walls of the print are clean but the left and right walls are marred (its a circular print with radial notches and the features appear as described if you use the rotating bed home location for orientation see below).
Top/Bottom (Max Min X)
Left Right (Max Min Y)
The Gcode is consistent all the way round the print and being a polar printer I can only assume something weird is going on in the translation of one of the print axes to polar from Cartesian.
This is what my current test print looks like in plan view:-
Any thoughts would be much appreciated. Also if RRF3 would be better for polar it'd be good to know.