grblcontroller jobs moving much slower than other gcode senders

[lordmundi]

there is a delay somewhere in the code that is slowing down my gcode sending significantly. Once a jog button is clicked, there is a noticable delay, and then the machine moves as a decent speed, so I think the machine is moving fine, it is just the commands going to and from the software seem to take a long time. Because of this, a gcode program with many lines can take many many times longer to send than other gcode senders (like Universal for example).

I was originally testing from a fast windows PC and saw the issue. After looking through the code, I was almost certain it was being caused by the delay recently put into the RS232 code after each character. But reverting to earlier versions seemed to have the same delay.

I've since moved over to running from a raspberry pi. I'm getting the exact same behavior. If I can get this delay removed, I think this program would be perfect on the raspPi. But every button click or GCODE line seems to have a delay and is slowing things down.

I've got the code where I can compile and run on the Pi, so if you have suggestions for things I can change, I would be more than happy to do so. I started looking at the code, and it looks like there are a few sleeps throughout, but I'm unsure which code is really getting hit.

Without being too familiar with it, it seems like the code should be able to be written with similar to the buffering done in the example "stream.py" script here: https://github.com/grbl/grbl/blob/master/script/stream.py

Again... let me know if I can help.

[zapmaker]

Please take a look at the latest 3.5.1 code which I posted a few weeks ago on github (for the Pi and anyone who compiles their own binary) and just posted the Windows binary on my downloads site today.

The 3.5.1 default behavior is to set the delay to 0 from the previous 10ms (see Options dialog). If after that you are still experiencing problems please let me know.

[krist10an]

I'm also having this issue: it takes approximate 1-2 seconds after pressing one of the move buttons until the machine moves. The same issue seems to be there when sending Gcode. I tested with 3.5.1 but the issue is still there.

I do not see same delay when using the simple stream from grbl:
https://github.com/grbl/grbl/blob/master/script/simple_stream.py

I am using a Seeeduino with grblshield (Shapeoko 2 bundle). Could this be related to the FTDI drivers somehow? For reference my machine is a Intel Core i5 laptop with 8 gb ram on Win 7 x64.

Thanks for the project by the way. I love having a good gcode sender which uses Qt and not Java :-)

[bjoerngiesler]

Same issue here, GrblController 3.5 and 3.5.1, on Mac and Linux.
EDIT -- the culprit seems to be the pollPosWaitForIdle() method in gcode.cpp. I will check the code a bit more tonight but the timeout is definitely happening in that method.

[zapmaker]

I'm back at working on Grbl Controller and am curious about this issue with pollPosWaitForIdle() causing slowness. If anyone has any suggestions, I'm listening. I haven't seen the issue so need some way to reproduce it - in an ideal world someone might be able to do a (screen) video demoing it or maybe a log file excerpt (or suggestions on a central file server to upload logs, etc.).

If anyone wants to do this, I've uploaded a sample to my web site which could be used as a timed reference. What I'll need to know are two things.

1. How long does it take to complete an air run (as reported by the runtime in Grbl Controller)?
2. What settings are you using, i.e. $ or $$ to dump settings? These affect runtime the most.

http://zapmaker.org/wp-content/uploads/2014/04/servo-ring.nc

On my production machine (which is running Debian 6 on a Dell Pentium III laptop with 256MB RAM) into 0.8c and an Uno 3, this job runs 8 minutes 40 seconds and was used to mill actual plastic parts that turned out fine - no noticable slowness. Here are my settings (not all matter):

$0=43.740 (x, step/mm)
$1=43.740 (y, step/mm)
$2=320.000 (z, step/mm)
$3=30 (step pulse, usec)
$4=500.000 (default feed, mm/min)
$5=500.000 (default seek, mm/min)
$6=160 (step port invert mask, int:10100000)
$7=25 (step idle delay, msec)
$8=25.000 (acceleration, mm/sec^2)
$9=0.050 (junction deviation, mm)
$10=0.100 (arc, mm/segment)
$11=25 (n-arc correction, int)
$12=3 (n-decimals, int)
$13=1 (report inches, bool)
$14=1 (auto start, bool)
$15=0 (invert step enable, bool)

On an Ubuntu 12.04LTS 64 bit computer running in VirtualBox and USB passthrough to a Mega 2560 running 4-axis special 0.84 (and different/default grbl settings), I'm seeing 7 minutes and 3 seconds.

I checked in some changes (nothing to do with this issue) and am up at version 3.6, but have not built an installer, so if you are running Linux you can build new or everyone else can use 3.5.1.

Most important, make certain that in Tools | Options character send delay is 0.

Thanks, zapmaker

[LETARTARE]

hi roman,
my experience : VISTA pro pack2 and Phenom triple core 2,30 Ghz with 4.00 Gb

I just saw a mistranslation "$v" !!

[chrisy]

I've not found file streaming to be particularly slower; but I do notice how long it takes the jog commands and for manually entered commands to execute. I've been tinkering with the sleep times in waitForOk and believe it feels more responsive than it did but have nothing scientific to base that on.

Really what I want to do is time the grbl takes to respond outside of grblcontroller to see where the bottleneck is.

My suspicion is that universal-gcode-sender and like don't do waitForOk-like stuff and does position polling in the background rather than before/after other commands, which is why it seems faster.

[zapmaker]

Thanks for the followup - I think the problem is as you suggest - I'm seeing too-frequent position requests going to grbl during the jog, somewhere on the order of one every half second.This could be having side effects in the motion.

What I'm going to do is (a) offer an options checkbox to disable this position reporting (edit: disable it during jog) and (b) change the default report to once a second (i may also add an option for the timing also)

[zapmaker]

I've made some modifications to the checked in code (currently version 3.6, prerelease) if anyone would like to run some tests (provided you can compile the code - I have not made executables/installers yet). Essentially, the new default option is to not request the position during manual/jog operations. The LCDs will go outline so you know the position is not valid. I added a button to manually refresh. I am very interested to know if this helps make the button operation snappier. Thanks.

[zapmaker]

One other thing that is worth noting - the initial delay if Grbl Controller is requesting position during a jog is I think due to it checking the idle state first. I may offer another checkbox or radio button to not do the initial position check. I need to check the nuances of why I did that first.

[chrisy]

I'll give that a go later after work. I suspect you wait for Idle just to flush out any queued commands, which does make sense, though I wonder if it has any impact on the result - since you then just queue the command you want to send anyway.

I'm also wondering about making position sensing asynchronous and in the background.

[zapmaker]

Position sensing is essentially asynchronous right now - it is just that in this special case there is the 'wait for idle' before the jog command is sent - I've now added an option to eliminate that: The position request is skipped right before the jog or manual command, which should provide a small amount of additional speed improvement without sacrificing the positional display - it is also the new default and is called "Always Request but without Idle Check".

I am also considering moving the aggressive preload" feature into the entire functionality - this would provide additional speed up for the case where you hit the jog button multiple times - instead of waiting for each button hit position to finish, it will queue them up one right after the other, allowing grbl to optimize the speed and hopefully get to the destination faster - now sure when I will put that in because it is not a trivial fix. There is a greyed out checkbox in the options in anticipation of that feature.

[rustyoz]

i have modified the code to remove the stopping while jogging. My modification disabled the wait for ok but now the settings dialogue doesn't work. ah well