Print speed maximum

Hi @NilartPax
Does this mean the printer will not go faster, even if you tell it to in gcode?
Because my snapmaker 2 A350 has just arrived last week and it basic speed was 140mm/s (for the laser) in Luban. That was to slow so I bumped it to 200% on the snapmaker screen which made it visibly go faster. I assumed at 280 mm/s. On my next laser test I rounded that, and set it default to 300mm/s in Luban. But it still took a long time to laser something basic so in my first real job I bumped up the laser to 50% (from 30% earlier) and set the working speed to 500mm/s, assuming it would work faster. It seems like it went even faster, but now I’m wondering if this was just my immagination and is it actually printing at that 150mm/s speed you say? Because my snapmaker screen also displayed 499mm/s while working. Is it bad to set such a high working speed or will the printer just cap it at it’s maximum speed. The result looked perfect by the way at that 500mm/s speed (real or not), so I ussume no “steps were missed” as I read can happen at high speeds. Still took 1.5 hours to complete.

Can somebody with experience (you or @Tone maybe) enlighten me?
Thanks a lot.

Also command M503 just returns “OK” when I send it, no actual values come back (over wifi)

The default “Jog speed” for the laser is 3000mm/s in Luban.
So I assume that is the maximum speed the modules can travel?
Am I right to say that this could also theoretically be the maximum laser speed?
That would mean my 500mm/s is indeed the actual travel speed and I could possibly even bump that working speed higher if I set the laser to a higher percentage as well? I see the issue with fast travel in 3D printing, but I assume that’s not valid for laser work?

You have to connect with the USB cable to see the reply of the M503 command.
I’m not sure but I think the limits stored in the controller will limit any other value above these settings.

PS: When you are connected also perform extruder calibration.

1 Like

As mentioned, you need to connect via USB to get the readouts.

The Marlin 503 lists the highest possible speeds theachine will go. However, Is it possible that there are different limits depending on the module head? I don’t know the answer to that. I am in heavy 3d printing still for covid PPE (2 headbands at once), for like the last 6 months and now schools are in the mix, thank God I have filament donor.
What I’m getting at is, if you could tell us the return from the Marlin 503 command with the laser attached we’d know the “speed limit”. I imagine it’s the same as with the print head attached.

Do you know if the response that comes back is the actual maximum speed, or the one that the firmware responds?

I’ve seen a few posts where there is discussion around updating various settings and writing those back to firmware which in return reports those new values.

Okay, I see what you are saying. If the speed anjuster will overwrite this speed limit. I hope the answer is, no. With 3d printing I am pretty sure it gets to max and doesn’t go any faster even if the screen says so, but I haven’t actually tested this. I don’t know why you’d want to even attempt max speed, tbh. These number are in the firmware to protect the equipment. It’s like you can put a jet engine on a car, but it’s not a good idea, and you are responsible for the fallout at that point.
@Edwin Is this an issue? Does the % speedup slider on the UI override the Marlin max speeds, or stop at the max?

It’s been a while, but this is the result of the M503 command when connected through USB cable.

  • The laser module is currently mounted.
  • Firmware 1.10.1.
  • Luban 3.10.2

I’m not sure how to read these value’s but I wanted to follow up this thread for those who care.

1 Like

Hello @JKC20 and @Vinobe93

Can you please clarify the units? Is it mm/s or mm/min?
It makes a 60 fold difference…

My version shows “Jog speed: 3000 mm/min”, which translates into 50mm/s

This would translate into:
7200mm/min, 7.2meters / min, 0.432km/h

As mentioned above, Luban version 3.12.3 displays 3000 mm/min

Thanks in advance for clarification.

It’s mm/min.
3000mm/s is obviously a typo.
That would be traveling the length of 9 A350’s in 1 second.


1 Like

Also thought so initially,
but new electric engines can easily get there.
Just check your “gearless” electric car.

The only problem is starting/stopping inertia, which would affect quality and durability,
thus explaining software limitations.
But it would make a difference in long linear projects.

Might be theoretically possible with a belt drive.
SM is screwdrive.

  • Yes @nelson.brito, that was a typo.
    The max speed in Luban is indeed 3000mm/minute, not per second

  • @NilartPax & @JKC20 to get back on topic:
    I see in my screenshot M201 which is “Set Max Acceleration speed”.
    It says 3000 for X and Y, 100 for Z and a whopping 10.000 for the extruder.
    I also see M203 which is “Set max feedrate
    which means the work speed as far as I understand right?
    Those limits are much lower at 150 for X and Y, 50 for Z and 25 for the extruder.

Now the following questions rise:

  • Luban let’s me set a work speed of a 1000mm/min.
    If I inspect the gcode I find G0 F1000 (Travel speed) and G1 F1000 (Work speed) which seems to confirm that it is at least set in gcode… But… As I set the travel speed equal to the work speed I would expect the laser to have a constant speed when doing travel-engrave-travel lines. But that’s not what I visually see. I see it decelerate on the engrave parts and accelerate on the travel parts. Which seems to suggest that the work speed is still limited somehow, I asume by the M203 setting. Even though on-screen it also displays a work speed of 1000mm/m.
  • Would there be any harm in sending the M203 code to the snapmaker to a higher value and saving that setting? If the max travel speed is 3000, why shouldn’t the max work speed for the laser not be 3000. (ONLY FOR LASER, AS IT DOES NOT TOUCH THE BUILDPLATE. I would never go over 150 for 3D printing, and even lower for CNC. I assume the setting is shared on all 3 modules so it would be at own risk ofcourse and only for those who understand the values)
  • Let’s assume the limit is real, would the on-screen speed dial actually force the speed over the limit?

Mine is set at 9000, works fine for me. I usually don’t run it faster than 6000 though, haven’t fully vetted it against skipped steps though. The developers posted somewhere 9000 or 10000 is the limit before it skips steps from the controller.

That’s not going to happen because the laser is planner synced, meaning to change laser power requires all motion to stop.

That’s actually one of the things I fixed in my firmware, enabling laser inline power from a later branch: Laser Pause While Changing Power

1 Like

Thank you! This is the confirming answer I was looking for! 9000 is probably a little overkill for me. But if I can already safely set it to 3000 the range of available work speeds increases drastically and the max speed would be 20x of what it is default.

Edit: but that would mean - based on what you explained about the full stop on laser power on/off - that my machine will have to handle bigger accelerations/decelerations on those laser on/off stops right? Could that be harmful (as in more ware and tear) at let’s say 3000mm/s? Or should the machine be well able to handle that?

Oh ok, good to know. I understand the reason behind it. A full stop makes sure the laser switches on at the exact desired location, while doing it while in (fast) motion could theoretically be “to late” if the LED takes a fraction to long to power on. And you should take that theoretically delay into account which is to much of a haste probably. But makes sense now.

Well, I’m not sure if I’m ready yet to flash custom firmwares on my machine, but I will read up on your topic if I find the time. Looks interesting.

For now I’ll start with changing the max work speed on the machine + experiment with faster settings for my regular laser jobs, or regenerate them at the previous 150mm/min max speed so that they still print the same after I change the limit.

Thanks for your response, made some things clear for me. Much appreciated.

It’s actually not that, exactly: The laser is capable of being turned on and off at a precise point, but the feature to do that was added later than Snapmaker branched off from Marlin. The later addition moves laser control into the motion part of the firmware, same that handles the stepper motor steps. As it is now in the official firmware the laser is controlled at the time of gcode parsing, decoupled from the motion, so what you said is true about it being imprecise unless it waits for the motion to stop.

The Y axis has visible resonance above 1500mm/s^2, in my opinion, and I’ve limited acceleration to that. Of course you can raise it “safely” until the machine skips steps, but it will be like hitting the build plate with a hammer each time velocity changes. The machine is primarily jerk limited (technically junction deviation, a specific form of jerk limitation) which will serve to also dynamically limit acceleration regardless of what you set acceleration to, based on the movement vectors.

In the meantime, if you want smooth grayscale, or even want clean edges without burning, it’s nearly impossible without changing the firmware or using dithering. I didn’t look much into acceleration, but you should and post your results - could be an easy workaround. It can be set in Lightburn as a user startup script, so the M503 EEPROM settings could be for 3DP and more conservative, but laser gcode instead changes acceleration and JD temporarily to reduce the effects.

It would be great to summarize these findings and organize a test template.
As we know that the depth of the burn is a function of applied spot intensity (focus&power) and time on the spot (speed), we could be paving the way for further improvements in SM2.

For instance, variable speed in straight lines would only need:
_acceleration plus more intensity followed of
_deceleration plus lower intensity.

This is easy to achieve in programing (for some;) but hard to apply due to the difference of materials.
So finding/adapting/creating a template for these tests using the full length of the bed to test speeds and strange sounds, as people understand better what you mean when they hear the limits.
I think it would be a way to favor replication and facilitate our communication, but acknowledge that I do not have the capacity to do it alone (yet or ever in my life?).

If someone finds organizing these inputs a good idea, we must also find a way to organize resulting information better, as reading all the available threads on all the three main SM2 topics is a challenge; as, for me, the value of SM2 is being an excellent “3 in 1”, not the best “1” in each of the 3 areas.

That is the function of trapezoidal power control, a function native in GRBL, added in recent Marlin, not yet brought in to SM. I do have that working on my machine, further testing required.

1 Like

Hi again,

I vaguely understand, but this is way above my knowledge level.

I’m a little confused. In your previous comment you say you have the max speed at 9000mm/s and that it works fine for you even though you do not set a speed over 6000. Now you say that it has visible resonance above 1500mm/s, which looks like a bad thing to me? So do you actually travel/work at 6000mm/s with high resonance? Or did I misunderstand and are you working under 1500mm/s? I’d consider setting it max to 1400mm/s, which would still be almost 10x the original max speed.

I’m currently not using any greyscale, and the rest of your comment I just don’t understand. :frowning: Too complicated. Movement vectors, trapezoidal power control… No idea what you guys are talking about :smile: I got much to learn, but no time :wink:

9000mm/minute velocity. 1500mm/s^2 acceleration. The acceleration units were wrong in my previous comment, it’s been corrected.

From here: Mathematics of Motion Control Profiles

Figure 1A would be called an “S-curve profile” and 1B is a trapezoidal profile. The Snapmaker uses 1A, with smooth changes to velocity.

The ‘trapezoidal power control’ I’m referring to is a bit misnamed in this application since it’s actually an s-curve shape. But the idea is you take the peak velocity as representing full laser power of whatever was commanded in the M3 gcode command, and then you scale it as the machine speeds up and slows down so that when the machine is moving at less than full speed there’s proportionally less laser power than what was commanded (eg 50% power at 50% of max speed). This prevents over-darkening as speeds change. Restated, in the above graph the laser will only be on at the full commanded power in phase IV. In phases I and VII laser power will be close to 0%.

The “max speed” I’m referring to is per line segment, not the machine maximum speed. Since the machine is acceleration (and jerk) limited, there will be a maximum achievable speed that is unique to each movement. For example, a tight circle, vs a long straight line, will have different maximum speeds. Even if the machine is asked to travel around a 1mm diameter circle at 9000mm/min it will not, as it would violate the maximum allowable acceleration. In that case ‘trapezoidal power’ scaling will also reduce the maximum laser output so that the correct amount of laser energy goes into the workpiece and you get a better, more consistent, result.

This also occurs at direction changes, for example when the machine is asked to turn 90 degrees at high speed. The machine will actually decelerate to a slow enough velocity that when it changes direction it limits the acceleration so that nothing is overstressed.

Funny enough, with 3D printing this already happens - the extrusion happens exactly as it should as the machine accelerates and decelerates because it’s natively handled by the motion controller just like the X and Y axes. The difference here is the laser, by default, is not handled like a movement axis, and this trapezoidal power control begins to treat it like one, equating “power” with “velocity”.

Thanks for the explanation! That is actually much clearer to me and makes sense. :100: :+1:

As you have much better understanding about this I might rephrase my original question:
Can the machiene - in it’s current state (official firmware I mean) - be made faster for the laser module?
And if so: what commands should be done to change the max work and acceleration speeds, and what are safe value’s?

I’m happy I understand more of the logic behind it now, but in essence I was just hoping to shorten my laserwork times… Even if it’s only double or tripple speed, as the default 140mm/min work speed is way to slow… If I could change the work speed to be 450mm/min (and acceleration accordingly) laserwork times would already be reduced by a 1/3 factor, which would be a lot i.m.h.o. and that would still be more than safe speeds if I understand you correctly.

Thanks a lot for your responses!

Sure, you can command it to run at 9000mm/min.


Every time the laser changes power/turns on/turns off the machine will come to a complete stop. This necessitates decelerating and accelerating, which will be the primary time spent in the process. That’s assuming there’s a dwell over each point, additionally.

The following is based on my settings in Lightburn:
I personally limit acceleration to 1500mm/s/s, and use fast travel at 9000mm/min and get fine results. On a 4 hour job using a fast travel of 9000 instead of 3000 it saves maybe 5 minutes of travel time, as the vast majority of the time is spent doing things other than travelling.

Be careful with your units: 450mm/s and 450mm/min are very different.

If you’re instead talking about how long it takes to cut by traveling with the laser on, you will primarily be limited by the amount of energy being deposited into the material to cut / etch. Typically 1-2mm/s is going to be the limit to get acceptable results for cutting, a bit faster for engraving. The machine is capable of moving faster but you won’t deposit any laser energy and will not get the desired result.

For long, complicated designs, expect hours to be a reasonable runtime.