Closed hchahine closed 7 years ago
@hchahine : I suppose the question should be: Is 50ms resolution not enough? Dwell is usually not intended for precision timing. It's often used to provide a spindle enough time to get up to speed or to clear out swarf.
So 50ms IS the programmed resolution as intended by the coder and not a bug?
I'm ok with that - just didn't expect it to be that large given most documentation hints at 1ms granularity which appears to not be the case. What's the limitation here, if if may ask? Or the constraining factor behind 50ms?
I can find a workaround for what I was trying to do given I know about this now.
P.S. 50ms is plenty for a CNC with a mechanical spindle whereas a laser is a much faster responding device as you know. Just food for thought for future dev.
@hchahine : Grbl does not have a spare timer to run dwells, so timing can vary. I really doubt its strictly 50ms increments. If you make dwells longer, you'll probably see the timing diverge. The only option on the Uno is commandeering the watchdog timer to do what you want.
What is the min resolution in the G4 dwell command? is it supposed to be 1ms (e.g. G4 P0.001) or better or ?
I'm using GRBL v1.1e on a nano to control a laser cutter. Almost standard build with the exception of laser mode enabled. I was trying to debug another issue when I noticed that the G4 command appears to only resolve in increments of 50ms. Is this correct?
E.g. P0.001, P0.010, P0.035, P0.050 = 50ms actual dwell time P0.060, P0.075, P0.100 = 100ms actual dwell time
P1.001, P1.035, P1.045 = 1050ms actual dwell time.
How I got to conclusion was I ran the simple test code below and observed D11 on a scope, only changing the the dwell time between various tests and capturing the pulse duration .
G0 X0 Y0 M3 S0 G1 X1 Y1 F3000 M3 S255 ( Note $30=255 so laser at max here, not PWMing) G4 P0.001 M5
Am I missing something or is this intended behaviour?