Cannot run CNC slower than 0.6mm/min

flopes

Hi
I have a laser cutter and need to run about 0.1mm/min for some micromachining operation.
I have a Duet2-Wifi on Beta 3.5.0
I have set the minimum axis speed to 0
When trying to go slower, even reducing the speed on %cutting speed, it does not go slower. I have been cheating, changing the axis scale, but I would prefere not doing that, because it messes the other production jobs.
Any suggestions?
Thanks

jay_s_uk

@flopes see the note in G0/G1
For CNC users especially: RRF has a default minimum movement speed of 0.5mm/sec. In firmware 2.03 and later this can be changed using the I ('i') parameter of the M203 command

droftarts

@flopes Also literally the first thing on this page, which you should look at: https://docs.duet3d.com/en/User_manual/Machine_configuration/Configuration_CNC

I have a Duet2-Wifi on Beta 3.5.0

Please update to the 3.5.1 release. The 3.5 beta and rc releases are no longer supported.

Ian

flopes

@jay_s_uk I set M203I0,
my limit is 0.5mm/min and not 0.5mm/s

flopes

@jay_s_uk Should I put M203i only?

droftarts

@flopes The minimum feed fate permitted by the firmware is 0.01mm/sec which is 0.6mm/min, so setting M203 I0 (or any number lower than 0.6) results in the 0.6mm/min limit. This value was chosen as, on 'normal' machines, there needs to be a minimum, and @dc42 wanted it to be low enough that nobody would need to go lower, and high enough that there was some chance you could see it moving if you waited for a reasonable period (e.g. a minute). Also, the maximum time that a move is allowed to take is about 30 minutes and currently RRF doesn't behave nicely if you try to schedule a move that will take longer than that. The idea is that you can recover from a mistyped feed rate.

Micro-machining is a rather specialised environment. In the past we have recommended scaling, notably in your previous thread: https://forum.duet3d.com/topic/31858/duet2-wifi-generating-polygons-instead-of-circles/
Without scaling, I think there will still be issues with segmentation of curves. Have you looked at using M579 https://docs.duet3d.com/User_manual/Reference/Gcodes#m579-scale-cartesian-axes to scale the Gcode? You may be able to keep everything 'normal' size, then scale everything internally on the Duet.

Also, we've just noticed a bug where any feedrate under 1.6mm/min (F1.6) when seems to cause a hang in RRF. A bug report has been raised. https://github.com/Duet3D/RepRapFirmware/issues/994

Ian

droftarts created this issue in Duet3D/RepRapFirmware

closed [Bug]: Feedrate lower than F1.6 causes no motion and RRF stuck at 'Busy' #994

o_lampe

@droftarts said in Cannot run CNC slower than 0.6mm/min:

Also, the maximum time that a move is allowed to take is about 30 minutes and currently RRF doesn't behave nicely if you try to schedule a move that will take longer than that

[Somewhat OT]
On several occasions I promoted the workaround for nonexistent "continuous rotation" where the user defined a regular axis with a length of upto 2^31 steps to be able " to rotate for days".
Now I'm not so sure, this axis will rotate longer than 30min? Do we have to combine such an axis with segmentation?

droftarts

@o_lampe said in Cannot run CNC slower than 0.6mm/min:

On several occasions I promoted the workaround for nonexistent "continuous rotation" where the user defined a regular axis with a length of upto 2^31 steps to be able " to rotate for days".
Now I'm not so sure, this axis will rotate longer than 30min? Do we have to combine such an axis with segmentation?

I'm not sure, either, but the 'maximum time that a move is allowed to take is about 30 minutes" came from @dc42, so probably need his input on that one. I guess segmentation would make it okay?

The problem here is have a default minimum speed that is sensible, to help people with 'normal' size machines, when they make a mistake and type G1 X100 F1 instead of F1000, that they don't have to wait 1 hour and 40minutes for the move to complete!

Ian

dc42

@droftarts said in Cannot run CNC slower than 0.6mm/min:

I'm not sure, either, but the 'maximum time that a move is allowed to take is about 30 minutes" came from @dc42, so probably need his input on that one. I guess segmentation would make it okay?

Correct. Implementing segmentation automatically for long-duration moves is already on my list.