search

Schildkroet / Candle2

GRBL control interface in Qt.
GNU General Public License v3.0
203 stars 56 forks source link

Either Candle 2 or Grbl board not response or not stable feedrate high said > 2500 #2

Closed klchin66 closed 4 years ago

klchin66 commented 5 years ago

Hi,

Did you encounter Candle not able to synchronize with the Grbl board, when feed rate is high said like 2500 or about on Windows OS? The Candle can response to the GUI button said like reset button but no feed back from the GRBL board.

The problem will occurred faster if using Override Feed rate. Said the GCode Feedrate is 1000, override rate is 150% that about 1500. On this situation during send GCode period, if try to resize the Candle's window problem happen even faster.

The "Buffer:" always at 0/0/0, like not able to push GCode lines to the GRBL board in time.

Tested same setting with UGS platform V 2.0 night builds at feedrate 5000 also no problem.

Regards, KL

Schildkroet commented 5 years ago

Hello, which version of grbl are you using? Can you post your $$ settings? Can you attach a gcode file where this behaviour occurs?

klchin66 commented 5 years ago

Hi,

I had tested with https://github.com/thomast777 - F46 verion, if not mistaken your version of Grbl-Advanced also having the same problem with stm32F407ZGt.

The attach file's feedrate I had modified to F5000 for testing. Buddha.zip This is one of them sample files.

Here my setting tested on yesterday. $1=1 $2=0 $3=1 $4=0 $5=0 $6=1 $10=1 $11=0.010 $12=0.002 $13=0 $20=0 $21=1 $22=1 $23=3 $24=100.000 $25=1000.000 $26=250 $27=5.000 $30=5000 $31=0 $32=0 $40=10000.000 $100=8000.000 $101=8000.000 $102=8000.000 $103=8000.000 $104=8000.000 $105=8000.000 $110=8000.000 $111=8000.000 $112=8000.000 $113=8000.000 $114=8000.000 $115=8000.000 $120=400.000 $121=400.000 $122=400.000 $123=400.000 $124=400.000 $125=400.000 $130=150.000 $131=150.000 $132=150.000 $133=150.000 $134=150.000 $135=150.000

Regards, KL

klchin66 commented 5 years ago

Extra info ... it happened on 115200 or 256000.

klchin66 commented 5 years ago

Confirmed setting on Grbl-Advanced also having same problem.

Here the screen capture, it happened almost on the same GCode line (tested 3times). Untitled

Here the setting I tested. $1=50 $2=0 $3=0 $4=0 $5=0 $6=0 $10=1 $11=0.010 $12=0.001 $13=0 $14=0 $20=0 $21=1 $22=1 $23=0 $24=50.000 $25=500.000 $26=250 $27=1.000 $30=3000 $31=0 $32=0 $100=890.000 $101=890.000 $102=890.000 $110=5000.000 $111=5000.000 $112=5000.000 $120=5000.000 $121=5000.000 $122=5000.000 $130=400.000 $131=300.000 $132=500.000 $140=0.010 $141=0.010 $142=0.010 ok

klchin66 commented 5 years ago

just noticed always stop at line 1375 and ERROR: Axis command conflict.

Schildkroet commented 5 years ago

I will look into this

klchin66 commented 5 years ago

Any progress ?

Schildkroet commented 5 years ago

Kind of... I did several tests on my ubuntu machine. Had no problems at all, everything ran perfectly. But you should reduce your decimal precision. 3 digits after the point are enough. It will increase performance. By now grbl spends almost all of its time parsing the gcode, since it contains too much digits.

klchin66 commented 5 years ago

Understand, It could be OS issue also.

Btw im using I7 HQ 4700 2.4Ghz 8G, NVidia 750M, Win7 Ultimate, it shld be enough process to handle the Gcode parser.

I noticed the app spends much of time handle the update the GUI, like updating the status and control button. Not sure how Qt handle the GUI, I do had bad experience with C# handle multi-threaded GUI.