Delay in movement

Discussion about the arduino based g-code interpreter, grbl
Post Reply
apspurgeon
Posts: 122
Joined: Mon Jun 08, 2015 9:18 am

Delay in movement

Post by apspurgeon » Sun Aug 02, 2015 3:59 am

Hi All

I've got a laser running perfectly from the ShapeOko3. Documenting for all shortly.

However, I have an issue with a delayed movement of the X/Y. The GCode to turn on the laser works perfect, and then the GCode to move X/Y...however it has a pause (approx 1/2 second) before it move. So, the laser comes on, 1/2 before any movement.

I suspect this is deliberate, as delayed period for the milling tool to cut before movement commands are acted on. With a laser, it means it 'over burns' at the 1st point.

Any GCode/GRBL settings to tweak this?

apspurgeon
Posts: 122
Joined: Mon Jun 08, 2015 9:18 am

Re: Delay in movement

Post by apspurgeon » Sun Aug 02, 2015 5:53 am

Wondering is it's this...hmmm


$1=255 (step idle delay, msec)
http://docs.carbide3d.com/article/38-sh ... l-settings

WillAdams
Posts: 8564
Joined: Mon Apr 09, 2012 6:11 pm
Location: Pennsylvania --- south of the Turnpike, East of US-15
Contact:

Re: Delay in movement

Post by WillAdams » Sun Aug 02, 2015 11:15 am

No, that setting governs how long the motors stay energized when the machine stops moving: http://www.shapeoko.com/wiki/index.php/ ... d_position

C.f., https://github.com/grbl/grbl/wiki/Configuring-Grbl-v0.9
Shapeoko 3XL #0006 w/ Carbide Compact Router w/0.125″ and ¼″ Carbide 3D precision collets
Nomad 883 Pro #596 (bamboo)

chamnit
Posts: 376
Joined: Tue Aug 12, 2014 2:16 pm
Location: Albuquerque NM, USA
Contact:

Re: Delay in movement

Post by chamnit » Sun Aug 02, 2015 2:36 pm

Grbl has no spindle delay but it does have a stepper disable delay. If the idle delay is set to anything but 0 or 255, it will delay by X milliseconds. Otherwise it doesn't. The short delay also could be GUI related if it delays sending Grbl the next command, but I don't recall any GUI doing this. Altough I've seen some weird similar things like this before.

That said, Grbl isn't designed for lasers CNCs but there are some forks that alter how Grbl runs so that it works better for lasers. However, I've got a couple of pressing things I need to do with Grbl first. I plan on installing a laser mode for Grbl officially very soon.

apspurgeon
Posts: 122
Joined: Mon Jun 08, 2015 9:18 am

Re: Delay in movement

Post by apspurgeon » Mon Aug 10, 2015 7:48 pm

Problem solved. It's the Carbide software, there is a deliberate delay coming from the software. I've switches to GRBL Controller and it's working perfectly

garetbiglow
Posts: 76
Joined: Fri Dec 26, 2014 6:33 pm

Re: Delay in movement

Post by garetbiglow » Fri Aug 21, 2015 7:28 pm

I suspect the delay is due to the architecture of the code.

Carbide 3D waits for the response from GRBL before sending the next instruction. You can really see this effect when you cut small circles using many G0 commands vs a G2 command. Since so many instructions are being executed in a short distance you'll see it stutter and stall it's way through a circle.

GRBL Controller and UGS both use an aggressive preload routine. This keeps GRBL's buffer full (128 characters) so as soon as it finishes an instruction it can grab another one. So the same situation, a circle with many instructions, will be executed smoothly.

These two different routines are very clear if you use GRBL's officially supported python scripts. Simple_stream.py does call and response, waiting for the "ok" from GRBL. Stream.py does the aggressive preload and keeps the buffer stuffed. Since all shapeoko users are using an open loop system (no real time feedback of actual position) I see no reason to use the call and response method. In all cases, we're just hoping that the motors actually do move the machine to the requested location. So since we can never know if the machine is where we think it should be, I would opt for the aggressive preload method and gain the smoother motion.
SO3 #0196

cvoinescu
Posts: 4442
Joined: Thu Jul 19, 2012 6:50 pm
Location: Camberley, UK
Contact:

Re: Delay in movement

Post by cvoinescu » Fri Aug 21, 2015 7:31 pm

That's why I object to calling it "aggressive" preload. It's just the usual way communication protocols work when there's a buffer.
Proud owner of ShapeOko #709, eShapeOko #0, and of store.amberspyglass.co.uk

garetbiglow
Posts: 76
Joined: Fri Dec 26, 2014 6:33 pm

Re: Delay in movement

Post by garetbiglow » Fri Aug 21, 2015 7:59 pm

Good point. GRBL has a buffer for a reason.

I sure like using those python scripts for control. They're so simple and bare bones.
SO3 #0196

apspurgeon
Posts: 122
Joined: Mon Jun 08, 2015 9:18 am

Re: Delay in movement

Post by apspurgeon » Sun Aug 23, 2015 6:16 am

Thanks all, the same code sent via carbide motion (delayed) and GRBL (no delay) has very different outcomes.
There are some GCode commands I've used before to wait until a motion is complete before next GCode is executed, but I think this is built into carbide (which is reasonable given the use case). Anyway, GRBL work fine

Post Reply