Head pauses after each line of an engrave, causing slowwwness of overall engrave

Not sure what the GF is doing after each line of an engrave, but it’s really slowing down the overall engrave. Sure it’s 400ms or whatever, kind of quick, but those add up! Kind of infuriating to see this tiny stop-pause rather than fluid back and forth

So… three options what it could be in my mind:

  • It’s a flaw, or GF engineers were just being conservative - is it being worked on / improved?
  • Is it an intentional cripple-ware because my unit isn’t a PRO. ?
  • Maybe the CPU is really that slow, and it takes that long to load the next set of instructions?

UPDATE: after measuring at 1000 speed, it’s actually 100-133ms. that 400ms figure was a guess

1 Like

Don’t know about the rest but we know that this isn’t true because it’s not GCode based. They send motion waveforms that tell the motors & PSU what to do.

1 Like

Cool, then we can translate that bulletpoint from GCODE to “instructions”… :slight_smile:

updating original post to be more accurate…


I doubt it’s about the CPU. I haven’t really noticed a pause in my engraves, but I have noticed that the head (which weighs close to a pound) goes well past the engraving area as it slows down and reverses direction. There’s probably an acceleration limit (before losing steps) that they really don’t want to violate.


The entire job is loaded before anything gets rendered.


That occurred to me as well, the first time I saw it doing this. That the head is heavy, and since secured by magnets, probably can’t have that big a force change on it or things get jilted quick. At best, the head could shift, causing an offset in the print, and at worst the head could tip and get stuck at an odd angle.

It’s quick. But it is a pause… But you’re probably right… I wonder how much room (in milliseconds) there is for improvement… :slight_smile: ever the optimizer i am… but at 600 lines per inch, it’ll add up :slight_smile:

It may be that they were conservative, but they may be being conservative with cause. I think it’s more about conservativism with respect to the motion mechanics than the CPU since the local CPU is just playing back a stepper waveform. It’s the CPU in the cloud that computed the waveform that said to be slow and careful around the uturn at the end of each scan line.

So you’ve got speed, stiffness and moving mass. Increasing speed or mass without sufficient stiffness means you’ll lose positioning accuracy as the components flex and spring back. Since the machine is already shipped with a particular mass (for the Y motion that includes the laser tube) and stiffness, the only variables you get to play with are speed and acceleration. And basically the trade off is time vs. quality. The conservative approach is to preserve quality at the expense of time.

It’s clear that the sliders already let you ask the machine to go faster than quality will allow so letting it go faster trivially (ie set a higher preset speed) won’t produce good enough results. They may have room to tweak the acceleration as well as the particular Y motion for one scan line.


:wink: agreed. that’s likely. magnets are not a stiff linkage and prone to dislodge, plus the center of gravity of that tall head is waaay above the connecting point. better to be careful. one downside of a magnet design. though, it’s a pretty awesome design. :slight_smile:

Also, if you ship slow, then tweak faster later, you make your users feel good (can make an announcement about performance improvement, etc.).

(as an aside, Reminds me when I worked on video games (xbox), we would allocate several 10’s of MB of nothing (blank character array), then when an artist ran out of memory, we’d tell them “let me see what i can find”, come back a day later “yeah, I found a couple MB for you”… Of course, leaving some allocated for next time. :slight_smile: )


Not sure what you mean by pause. What it should do is engrave the line at constant speed, then decelerate to a stop with the laser off, then accelerate up to speed again in the opposite direction while also moving down a line before turning the laser on again.

So it is only stationary for an instant as it reverses. Is that what you are seeing or something else?


I haven’t watched carefully enough to see whether it overlaps the gantry move with the deceleration/reversal. It should, and yet.

It does in the waveform files I have inspected.


How are you able to tell there’s a pause? Did you record it with a high speed camera?

… Actually, even at 30 FPS, a 400ms pause would be ~12 frames.

I guess I’m wondering how confident you are that the head is actually remaining motionless for such a long time.

Something to focus on instead of mental pictures. :wink:

This is at 600 speed

Are there pauses in there? Mine eyes don’t see any.

According to the video player I can see in my phone’s browser, the video is 1 second long and the head changes direction 4 times, if ALL it was doing was pausing, the pauses would be 250ms each, on average. And it’s clearly spending most of its time moving.

1 Like

Yeah… Not seeing a pause… The head has to stop in order to reverse direction.


It’s a lot more apparent at 1000 speed. (Previous was at 600)

And I’ll be the first to admit that the decelleration could be tricking my eye.

Scrubbing though the .MOV video in QuickTime player, I see 4 frames at the same ‘left’ position. Scrubbing forward to the ‘right’ position, I see another 4 duplicate frames…

This video is 29.99fps

  • At 1000 speed the full pause is ~4 frames: ~133.3ms (4 frames * 1/29.99ms), and at least >100ms (3 frames * 1/29.99ms)

  • At 600 speed the full pause is ~2 frames: ~66.7ms (2 frames * 1/29.99ms)

Maybe more pause is needed for inertia (let the elastic material of the laser head settle?).
Also, I wonder if the deceleration could be a lot more aggressive to get this thing moving faster…

Certainly too fast for my old brain to see a pause.


@palmercr how do you view the waveform files? Are you snooping the network traffic or something?

At 450LPI, engraving a 3in fret slot (0.023" wide) at 1000 speed, there’ll be at least 100ms * 450lpi * 3in of pausing == 135seconds == (135/60)min == 2.25 extra minutes of pause on top of the actual work being done, and that doesn’t include the time needed for accel/deceleration… :slight_smile:

(3 minutes, if you’re using the 133.3ms measure)

would be interesting to see a video from a pro at 1000… wondering if it has less pause.