GRBL 1.1 Running on a Smoothieboard 500 mm/s, 79,000 steps/s 0.3 mm pixel spacing

CAD & CAM Tool Chain LaserWeb/CNCWeb
,
1

GRBL 1.1 Running on a Smoothieboard

500 mm/s, 79,000 steps/s
0.3 mm pixel spacing. Join Pixels is Off.
LW3 (branch) streaming 1666 blocks/s over USB

Port by @Brett_Fleming and myself with advice from @Sonny_Jeon
https://youtu.be/jv0lxEan_Xw

2

The port lives at https://github.com/gnea/grbl-LPC

LW3 branch is grbl-buffer.

3

Is this a firmware branch? If so #ShutUpAndTakeMyMoney

4

@Alex_Krause it’s a branch of GRBL, with additions for motor current control and on-chip USB-serial

5

Runs on on smoothieboard?

6

@Alex_Krause yes

7

A round of beers need to be added to all of your PayPal accounts!!!

8

+Peter van der Walt Will be testing this shortly.

9

If you generate using LW4, then you’ll have to strip out lines which only have S# in them. I don’t know why lw-rasterizer puts them there. They sometimes cause GRBL to slow down. We don’t know why yet.

10

Hats off to @Todd_Fleming and @Brett_Fleming ! They ported Grbl v1.1 in about two weeks, even after running into a deadend with a different approach. Beautiful job fellas. I have a feeling this is just the beginning.

11

For the curious: the largest deadend was mbed. They have unfixed bugs that have complaints dating back 4 years.

12

+Peter van der Walt ah-ha! Now it makes sense. Yes, please remove those.

13

Is there anything else needed to test other than installing the firmware.bin?
We can connect with GRBL reporting back ‘GRBL 1.1e…’, but nothing further and commands are unresponsive.

We are using Ultimate GCode Sender.

14

There’s a key difference between GRBL on Arduino and GRBL on Smoothieboard: opening the port doesn’t cause a reset. I changed LW3 to send a ctrl+x when it connects. Once it’s working, there are a couple changes to senders for them to run at full speed:

  1. If they don’t support character counting, then there’s no way they can run at speed.
  2. RX buffer size is now 8k (8192 bytes)
  3. They should try to stuff as much gcode as possible, up to the free space in the RX buffer, into as few USB packets as possible. i.e. they should use a single send() call.
  4. They should realize that a single USB packet may contain a bunch of OK’s. They should count the OK’s before sending new gcode. This avoids multiple send() calls. They need to be careful: a single response can be split across USB packets.

Before testing on a sender, I recommend connecting a terminal to the COM port to make sure it responds. I use PuTTY.

15

My LW3 changes are in the grbl-buffer branch; I don’t know if the ctrl-x will break TinyG or Smoothieware.

16

@Todd_Fleming Is there a way of detecting it is Grbl running on Smoothieboard? For example: a welcome string like "Grbl v1.1e (LPC1769)

17

Grbl sends the welcome string after each reset. Could you change that behaviour to send the welcome string after a connect (and reset)?

18

Should it work on an azteeg X5?

19

Really nice :slight_smile:

20

@Todd_Fleming I have found that you set the default for $10 to 1 but LW needs 0 (WCO). Not a big deal, as it could be set with $10=0.