fra589 / grbl-Mega-5X

5/6 Axis version of Grbl, the open source, embedded, high performance g-code-parser and CNC milling controller written in optimized C that will run on an Arduino Mega2560
https://github.com/fra589/grbl-Mega-5X/wiki
Other
341 stars 159 forks source link

question #160

Closed sinfocomp closed 3 years ago

sinfocomp commented 3 years ago

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

fra589 commented 3 years ago

HI, What is the problem ? What is your configuration ? $I, $$ outputs ? What is the GCode which don't work as expected ???

sinfocomp commented 3 years ago

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

LBExport.gc.txt

fra589 commented 3 years ago

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.

sinfocomp commented 3 years ago

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

fra589 commented 3 years ago

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.

sinfocomp commented 3 years ago

i use both laserGRBL and Lighburn and both present the same problem

fra589 commented 3 years ago

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 /doc/script directory) then you can see if there is the same behavior with them.

@++;
Gauthier.