Jerkiness in motion using GRBL-LPC

Controllers Grbl-LPC
1

I seem to have some jerkiness in motion using GRBL-LPC

So I have GRBL-LPC and Smoothieware running on two separate Sbase boards I have. Using external steppers to move my custom machine and with all the equivalent settings being the same, the movement seems to stutter a bit with GRBL-LPC. This most apparent when doing engraving at 45 degrees where both the A and X are utilized simultaneously…

Any idea where to start looking?

2

That sounds odd. Usually grbl-LPC is much faster than Smoothieware on plaing gcode. Did you set grbl to laser mode with $32=1?

Which software do you use for sending the gcode?

3

I do have laser mode on and the behavior exists for both Lightburn and Laserweb4 on GRBL-LPC

To be clear I am testing Smoothieware with Coheshion 3D’s smoothie cluster update. Laserweb does not recognize this board. On Lightburn though it runs smooth regardless if I turn on smoothie cluster in the software.

I am not sure if this is a issue with speed in sending data to the controller as I am not moving very fast.

4

Hi All,

I have made some great progress with our custom rotary laser. Some videos below

[3 new photos added to shared album] Makerforum Share

We had some custom CAM software which etches in a continuous rotary like a lathe. As you can see we are achieving pretty decent speed especially when we do not have to constantly decelerate. We send the code using Laserweb.

The rotary in the video is a chuck directly driven by an external integrated stepper. GRBL is sending 35ish pulses per degree $103 through the MKS Sbase signal pins. This value is adjustable by the integrated steppers. We have since updated our rotary to a larger belt driven unit with a 5:1 reduction. By adjusting the settings on the microstepping input on the driver we reduced GRBL $103=22.22.

We seem to be having a couple issues with the laser significantly slowing down now once it fires and I am wondering if there is some wrong with the way we are exporting our Gcode, now that we have more dots to put down per revolution. I copied a small section of our Gcode at the bottom.

Questions

Is processing A axis moves anymore intensive than X or Y
Does having moves or laser power with higher decimal points bog things down?
Is there a table or resource that I could theoretically calculate what my speeds can be?
Does increasing steps per mm or degree slow things down?
Would a faster computer for sending help?

Any help in troubleshooting is greatly appreciated.

Gcode sample. etching only 0.25mm length of rod. We have run code that extends to 1200mm with the A values extending into the hundred thousands.

G92 X0 A0
M7
M8
A1800

G21
G90
M4 Z0
G0X0A0
F40000.0
G0 A1.000 X0.00 S0
G1 A1.451 X0.00 S1000
G0 A3.264 X0.01 S0
G1 A3.715 X0.01 S1000
G0 A5.528 X0.02 S0
G1 A5.979 X0.02 S1000
G0 A7.792 X0.02 S0
G0 A10.057 X0.03 S0
G1 A10.508 X0.03 S1000
G0 A12.321 X0.03 S0
G1 A12.772 X0.03 S1000
G0 A14.585 X0.04 S0
G1 A15.036 X0.04 S1000
G0 A16.849 X0.05 S0
G0 A19.113 X0.05 S0
G1 A19.564 X0.05 S1000
G0 A21.377 X0.06 S0
G1 A21.829 X0.06 S1000
G0 A23.642 X0.07 S0
G1 A24.093 X0.07 S1000
G0 A25.906 X0.07 S0
G0 A28.170 X0.08 S0
G1 A28.621 X0.08 S1000
G0 A30.434 X0.08 S0
G1 A30.885 X0.08 S1000
G0 A32.698 X0.09 S0
G1 A33.149 X0.09 S1000
G0 A34.962 X0.10 S0
G0 A37.226 X0.10 S0
G1 A37.678 X0.10 S1000
G0 A39.491 X0.11 S0
G1 A39.942 X0.11 S1000
G0 A41.755 X0.12 S0
G1 A42.206 X0.12 S1000
G0 A44.019 X0.12 S0
G0 A46.283 X0.13 S0
G1 A46.734 X0.13 S1000
G0 A48.547 X0.13 S0
G1 A48.998 X0.13 S1000
G0 A50.811 X0.14 S0
G1 A51.262 X0.14 S1000
G0 A53.075 X0.15 S0
G0 A55.340 X0.15 S0
G1 A55.791 X0.15 S1000
G0 A57.604 X0.16 S0
G1 A58.055 X0.16 S1000
G0 A59.868 X0.17 S0
G1 A60.319 X0.17 S1000
G0 A62.132 X0.17 S0
G0 A64.396 X0.18 S0
G1 A64.847 X0.18 S1000
G0 A66.660 X0.19 S0
G1 A67.112 X0.19 S1000
G0 A68.925 X0.19 S0
G1 A69.376 X0.19 S1000
G0 A71.189 X0.20 S0
G0 A73.453 X0.20 S0
G1 A73.904 X0.20 S1000
G0 A75.717 X0.21 S0
G1 A76.168 X0.21 S1000
G0 A77.981 X0.22 S0
G1 A78.432 X0.22 S1000
G0 A80.245 X0.22 S0
G0 A82.509 X0.23 S0
G1 A82.961 X0.23 S1000
G0 A84.774 X0.24 S0
G1 A85.225 X0.24 S1000
G0 A87.038 X0.24 S0
G1 A87.489 X0.24 S1000
G0 A89.302 X0.25 S0

5

Can you post your $$ settings. Specifically looking for $32=1 to put it in laser mode.

6

I don’t have access to the machine for a while but yes I am 99% sure laser mode is still on and was not changed.

7

If lLserWeb does not recognize the board with smoothie cluster firmware then maybe this firmware is sending a different version string, which is not recognized by LW. If I know what they send, I can add it to the accepted firmwares.

8
  • On grbl-LPC all 4 axis are handled the same way. No difference on A axis.
  • Yes, having more decimal digits in your gcode results in longer commands, which fills up the input buffer quicker and slows down the maximum feed.
    • You should cut unnecessary digits like .000!
    • Also don’t generate S parameters in G0 commands as in laser mode ($32=1) with M4, the laser will only fire during G1, G2 or G3 moves.
    • When you always want the same power (S value) as in your sample code, you sould not add S parameters to every G1 command. Instead set the power once with M4 S1000. The M4 S1000 will not fire the laser until a G1, G2 or G3 move.
    • You can even stripe the spaces between the params, like you did in the first “G0X0A0”.
    • All this together will make your code much shorter and the maximum feed much faster!
  • The main limiting factor is the length of commands that needs to be transferred over USB/serial. A higher pixel resolution (= smaller laser diameter in LW) means more commands per mm. For example, setting laser diameter to 0.1mm means 10 pixel/mm = 10 G1 commands per mm. With 0.2mm there are only 5 commands / mm, so you can go twice the speed. To get the whole surface covered with no gaps in between and also no overlapping, you should set this to the size of the focussed laser point.
  • The steps per mm or degree for the stepper motors in the $ settings is usualy not a limiting factor, because the stepping is made by internal interrupt routines which are much faster than the serial communication and gcode parser.
  • It’s unlikely that a faster computer would help (unless your actual computer is extremely slow).

Hint: The M4 line in your sample is a potential problem. You should set the Z0 on a separate line with a G mode in front (i.e. G0 Z0).

9

Thank, I suspected there was a lot of room in optimizing our code. I’ll try some if your suggestions and report back when I get back from vacation!

10

Thank you for these thorough suggestions. I tried optimizing my code with each of these items but without much improvement sadly. There are two areas I intend to review further.

  1. We are revising our software to output a to 3 decimal points for the X axis. I think there may be some rounding errors preventing a smooth spiral causing the machine to jitter. We tried the same code without any x movement and there was a bit of improvement.

  2. I think my expectations or off. As I understand now the GRBL has no idea what the A axis diameter is, so it will not adjust the rotary rpm to match the linear speed provided. Further larger diameters will have much more “dots” than smaller diameters.

I put together the below spreadsheet.

image
image745×213 4.61 KB

I wonder if anyone can comment what would my max theoretical speeds could be. Is it limited on the lines of gcode per second (the last column)?