Ruida rastering beyond max speed?

Dannym · July 8, 2026, 1:54am

Recently saw a user who had glitch mid-raster and mostly ruled out any normal cause- then I found the user had set the raster speed to 1200mm/s, but the x-axis speed limit is supposed to be configured for a 1000mm/s limit. Ruida 6445.So this begged the question, what happens if you ask for a raster (fill, in this case) speed it can’t reach??Now if I asked for 5000mm/s vectors, it would probably scale back power just like it does whenever it’s not at the commanded speed. 5000mm/s 100% max/1% min power command, when it’s doing 50mm/s it will be 10% power. If given enough room, it should max out at 1000mm/s 20% power.

But raster doesn’t use power scaling. At least it’s not supposed to, except in grayscale, which is a very different thing.

I did some tests on a Ruida 6445 with closed-loop steppers and a 6442 with open-loop and asked for 5000mm/s 100%max/1% min power when they were supposed to be limited to 1000mm/s. Lightburn won’t stop you.

Best guess:

neither one scales back the power.
The 6442 seems like it decided to just override it and run at 1000mm/s
The 6445 tried to go way faster than allowed, but the closed-loop drives allow you to get behind some amount before latching into a fault state. The fault state didn’t trip, but the drives appear behind by quite a bit. The motor drive itself may have imposed a speed limit on what it puts out, but may still be counting steps in correctly (not certain).

This is the 6442 with open loop steppers, those can just stall. It didn’t stall, and the raster is normal. 20% power 1000mm/s would not be enough to make a mark on this laser, so it didn’t scale. The panel said the job was 5000 99% but the top of the display said 1000 99%. But the 6445 seems to have read like that too. Thus my conclusion the 6442 just changed the speed and didn’t scale power

This is the 6445 with close loop steppers. There’s now an quasi-backlash in both directions, but no drive fault. What seems unusual now is the backlash doesn’t seem to catch up over distance, given more time to accel. Again, close-loops do not have a high speed stall like open-loop, they track rotor position and continue to drive out speed and torque when pushed too far, but can lag behind by a limited amount. Also, the burn is too dark for the power to have been scaled back. It’s something over 1000mm/s but I don’t know by how much, drives tried to go as fast as they could but lagged the whole line, then caught back up on the reversal.

If this were open loop on a 6445 asking for an impossible speed, I expect a stall and axis crash soon to follow. But the machine with open loop drives was a 6442, which looks like it made a saner decision to limit the x axis raster speed.

They don’t have the same config, they’re different controllers. This difference could be due to a config setting

parsec · July 8, 2026, 2:22am

Did you set Scanning Offsets for the 6445?

jkwilborn · July 8, 2026, 4:37am

As far as I know, these speed limits within the controller are there to protect the machine, not the user. These really depend on acceleration values. The Ruida will advise you of issues with overscan, but I don’t remember my grbl controller working the same way as a dsp operates related to overscan.

If you tell Lightburn to go out of the work area, it only warns you because you setup the work area size when you set up Lightburn. With grbl (soft limits enabled) can detect this and a dsp will know you’re running out of work area, only because you told it what size the work are is. Lightburn doesn’t read this data from the controller.

If the user doesn’t know enough to run the machine within it’s limits or some project file is used that was done on a gantry co2 and they attempt to run those speeds with their 500mW laser, the controller will prevent that from happening by limiting speed to what’s described in the controller.

I messed with this quite a bit, removing mass from the head area to get great speeds, but only useful for academia. My upper limit is set to 1750mm/s with an acceleration of 45,000mm/s^2. I’ve run and check the speed via a video, knowing frames/second and I know I can do 1650mm/s.

This is it running a test at 35inches/s or 889mm/s. It’s rather boring at 4 minutes in length.

I don’t know exactly how todays servos work, my experience with them is pretty far back in time.

I know a number of people have tried them and given up. They seem to get behind as far as when it lases. I know of no feedback to either controller that will tell it what it’s doing, it’s all done in the driver as far as I know. Do you know differently? You seem to have success with them.

I know grbl controllers limit their speed to what’s in the configuration, not what the software tells it to do. Unless Lightburn reads the controller for size and acceleration, I don’t know how it could realistically warn you. I also don’t know how it could scale power, based on speed, if these limits are used.

I also don’t follow how a servo could go faster than it’s controllers limits, assuming they are correct, as the speeds are not sent to the motor drivers, it depends on signals for stepping from the Ruida. I have looked at them and didn’t see any kind of way to get error or other signals from the controller to the motor drivers or vice versa if you use servos, maybe you can enlighten us?

Dannym · July 8, 2026, 6:06am

Closed loop steppers are not servos

Dannym · July 8, 2026, 6:13am

scanning offset isn’t set. this is caused by the 6445 apparently allowing a raster speed over the max x axis speed. it’s more or less what i would expect on a closed loop stepper drive system and not particularly puzzling. what’s weird is the 6445 is allowing it.
it’s got a simple solution: don’t enter illegal speeds. just had to FAFO that.

jkwilborn · July 8, 2026, 12:59pm

Part of my issue, I related them to regular steppers.

How can this be? If I ask for 20,000mm/s and it damages the machine, who is at fault the user or the controller? I don’t see how the 6445 is any different than a normal 6442 as far as driving motors. I find it very hard to believe that the 6445 ignores internal limits, doesn’t make sense to me.

NicholasL · July 11, 2026, 10:01am

Interesting, thanks for sharing…how much faster do you think it went? How do you know it went faster? Are the job times decreasing, at what speed does the actual job time stop getting faster?

I know you said scanning offset was not enabled but one thing to be aware of with that function is that if enabled it will keep on compensating and adjusting the output based on the speed you enter into LightBurn without any awareness of what the max speed of the hardware is, which could explain a bad scanning offset (as does not having it enabled when it should be).

jkwilborn · July 11, 2026, 3:17pm

Having worked with controllers since about 1980, I don’t know how you could fix a controller that doesn’t control?

I just can’t buy into the fact that the Ruida would allow you to run faster than your upper speed limit. That’s it’s whole purpose, machine protection.

As far as I know, how closed loop motors work have nothing to do with how you program the Ruida, the manual doesn’t even mention closed loop motors/drivers. It’s outputs are fixed and there is not way to send an error message or failure to the Ruida.

Lots of speculation here, personally don’t buy into it… however this wouldn’t be my first surprise from a Ruida controller.

If you had to fix one of these, how would you know where to start?

IMHO…

kersten_k · July 11, 2026, 7:14pm

My 8445 is set to 1900 mm/s; when I send a job from Lightburn at 3000 mm/s, Lightburn displays that 3000 mm/s speed, but the controller caps it at 1900 to protect the laser.

Overscan needs to be configured in the Ruida settings, and the specific values must be determined; two or three values are sufficient—in my case, 500, 1000, and 1500—as Lightburn automatically calculates the intermediate values.

MikeyH · July 14, 2026, 2:15am

No, closed loop steppers HAVE servos.

A closed-loop stepper circuit eliminates lost steps by using position feedback, such as an encoder, which continuously corrects motor alignment. It connects your Controller (e.g., Arduino) to a Closed-Loop Driver (like a CL57Y), the Motor, and a Power Supply.