Closed sinfocomp closed 3 years ago
HI, What is the problem ? What is your configuration ? $I, $$ outputs ? What is the GCode which don't work as expected ???
the problem is that a cutting speed of 5,000mm/min runs fine and fast, and once i setup a fill or image mode and 5,000mm/min it does not look the same speed as a cut move, looks far far more slow configuration is $0=10 $1=255 $2=0 $3=63 $4=0 $5=1 $6=0 $10=2 $11=0.000 $12=0.002 $13=0 $20=0 $21=0 $22=0 $23=63 $24=500.000 $25=4000.000 $26=232 $27=20.000 $30=1000 $31=0 $32=1 $100=20.000 $101=20.000 $102=20.000 $103=20.000 $104=20.000 $110=5000.000 $111=5000.000 $112=5000.000 $113=5000.000 $114=5000.000 $120=950.000 $121=950.000 $122=950.000 $123=950.000 $124=950.000 $130=1800.000 $131=3000.000 $132=50.000 $133=1800.000 $134=3000.000 slow gcode attached
Hello @sinfocomp,
I don't have a laser or a fast enough CNC machine fast enough to test your GCode file, but reading it, I think your problem come from many shorts travels with direction inversion between each, it seems this does't leave the time to to reach the nominal speed given the acceleration.
The speed and acceleration in Grbl are calculated by the algorithm in the planner.c file. This algorithm is pretty good documented in the file.
I advise you to read this documentation to check this and maybe optimize your parameters.
@++;
Gauthier.
hello @fra589 Thanks for the poointer looks like the problem is the planner buffer is not large enough for all those small movement lines, while there a re many small line segments they are not changeing direction untill the next scanline, is there a way to either increase planner buffer or to disable motion planner at all while doing dot printing (like in dot matrix printers) wich is the task i want to complete thanks for the advice Ed
Hello @sinfocomp,
The planner is the center element of the movement calculation and gestion in Grbl... If you wand to disable it, you will need to write another on from scratch!
I rather suspect a sender problem which does not send the GCode commands quickly enough or which make a stop (perhaps waiting for the GRbl response) between commands...
Wich GCode sender do you use?
Perhaps you can also try to maximize the acceleration?
@++;
Gauthier.
i use both laserGRBL and Lighburn and both present the same problem
Hi @sinfocomp,
I don't have enough knowledge about laserGRBL and Lighburn to understand what happend to you...
Perhaps you should try the 2 scripts "simple_stream.py" and stream.py" (located in the
@++;
Gauthier.
Hello, i dont seem to get a correct "scanning" speed even with a x max speed of 10,000mm/min, when two subsecuent g1 commands are given in same gcode line, are these treated as separate moves each with its own aceleration parameter ? this is the only reasonable cause i can think of