GBRL why the mystery?

[Simon]

I'm looking at various cheap CNC machines, usually they all have 3018 in the name as they have a 300x180mm working area. They also all come with some variant of a more or less standard GBRL controller. such as this one: https://www.ebay.co.uk/itm/3-Axis-GRBL-CNC-Router-1-1f-USB-Port-Engraving-Machine-2418-3018-Control-Board/274571623432?_trkparms=aid%3D1110006%26algo%3DHOMESPLICE.SIM%26ao%3D1%26asc%3D225113%26meid%3Dc4d88159b7ed48838fbcd92a4835378d%26pid%3D100005%26rk%3D3%26rkt%3D12%26mehot%3Dco%26sd%3D383679158757%26itm%3D274571623432%26pmt%3D1%26noa%3D1%26pg%3D2047675%26algv%3DSimPromoteOrganicWithFloorBidWebWithBBEV2%26brand%3DUnbranded&_trksid=p2047675.c100005.m1851

I'd like to be able to drive this controller myself, this seems to be over USB or via the "offline" controller input which I am assuming is a serial input? Looking up GBRL seems to just yield a load of arduino projects or poorly written explanations. Ho do I find out how to control one of these things?

[Ian.M]

Since GRBL is a FOSS G-code interpreter  /CNC controller for the Arduino platform, its not surprising you find a lot of low quality Arduino crap!

Go straight to the horse's mouth: https://github.com/gnea/grbl/wiki

[Simon]

Right so let me get this straight. The controllers being supplied have the GBRL core in them and handle the stepper motors. The port that is often marked as for the offline controller or joystick is the serial input that takes the commands in GBRL that will tell the controller what result I want from the system.

[Ian.M]

This: https://github.com/gnea/grbl/wiki/Using-Grbl may help.

You send G-code from a terminal program (minimalist) or from a utility designed to stream G-code CNC programs to GRBL via a serial link (usually a USB UART).

[Simon]

Right so actually I don't care about GRBL then? that is the G-code interpreter on the machine and I need to send G-cade over serial to make it move although knowing it's the GRBL G-code interpreter at least tells me the baudrate and G-code flavour to use.

[Ian.M]

G-code has many subtly different dialects.  The core functionality is pretty much the same for any class of machine and number of axes, but as each manufacturer has proprietary extensions and settings, so unless you are writing hand-crufted G-code, whatever software you are using to generate the G-code for the toolpath needs to know to output GRBL 'flavor' G-code, and as GRBL is so ubiquitous, is probably going to need to know a whole bunch of machine parameters as well.

[Simon]

All I am concerned with is being able to move the 3 axis's 

[Simon]

Even on the GRBL help pages they just send you to the linuxCNC G-code implementation but admit that they also use other standards

[phil from seattle]

I just noticed this thread.

Grbl doesn't really have a lot of different dialects. There are versions that have added a few features but there is a core set of GCodes that they all execute - basically Grbl 0.9. Most CAM systems have post processors for Grbl and almost any Grbl based system will accept the output.  One issue is tool change commands that most don't accept but every CAM I've ever seen has an option to suppress them. The best documentation on Grbl GCode is the ShapeOko wiki.

I think the mystery comes about because the Chinese vendors of the "3018" machines don't know anything about it and just package up stuff to sell with zero documentation.  The "original" Grbl is the grbl/gnea version that is currently on Version 1.1h and is found here. The wiki there is the most authoritative.  The most interesting thing to me about grbl/gnea is that it does an amazing amount of things running on an 8-bit 16 MHz microcontroller - the Arduino Uno or Mega. There are follow on ports to 32 bit ARM, the best is grblHAL which runs on 13 different microcontrollers including a 600 MHz NXP Processor on the Teensy 4.1.

[Simon]

i wonder why they don't just port it to the DUE or also being arduino would it work on that too? My plan is to drive the supplied controller but struggle to find any information about this. I see a mention of it must run at a minimum of 115kbps or it will have problems. OK fine but surely if the speed is any over 115kbps then presumably this serial port works is synchronous mode with a clock? any other signals? There is just no information about the hardware setup as the expectation is that you plug the arduino straight into the PC.

[phil from seattle]

The issue of why didn't the gnea team port it to a 32-bit processor has been the source of much discussion but the fact is, they didn't. Grbl/gnea is tied very closely to the Atmel 386P, mixing motion control with direct manipulation of processor registers. I've heard more than one developer talk about spaghetti code. Grbl sat in maintenance mode for a number of years and in that time other developers got tired of waiting and ported it themselves.  That lead to fragmentation as no strong developer can possibly not add a few new features along the way. I wrote about that here. I am actually glad the original team didn't port to the Dué because it is kind of a dog processor and pricey for what you get.  It would have stopped a lot of developers from porting. Consider the Teensy 4.0 - 600 MHz iMXRT 1062 ARM M7 with huge amounts of flash and RAM - only $20 USD. With a real FPU, the grblHAL port shines on it. There is a fair amount of info on the site in the Wiki, Discussions and the source code.

I made a breakout board for it that I sell on Tindie.  Here are some machines based on it. It supports Ethernet as well as USB.

[Simon]

Yea I wondered why there are no ARM ports but there are several? well I'm not looking to make a controller just talk to one.

[langwadt]

Yea I wondered why there are no ARM ports but there are several? well I'm not looking to make a controller just talk to one.

if you just want to talk to grbl all you need is something with a 115200baud* serial port capable of sending text. There's few special commands for settings,
homing, info etc. and you'll have to interpret the responses from any alarms, info request etc. but otherwise it is just gcode generally following linuxcnc behavior
though only supporting the most common g-codes

to play around just connect it to serial port and open a terminal, it is pretty straight forward


*if you rebuild the code it can be anything within reason

[Gyro]

The simplest way to drive them over USB from the PC is using Grblcontrol, now called Candle.  https://github.com/Denvi/Candle

This allows you to manually control the CNC, see the toolpath and load Gcode files etc.

[Simon]

OK, all I need to do is move the 3 axis's 

[langwadt]

OK, all I need to do is move the 3 axis's

G0 or G1

[phil from seattle]

The simplest way to drive them over USB from the PC is using Grblcontrol, now called Candle.  https://github.com/Denvi/Candle

This allows you to manually control the CNC, see the toolpath and load Gcode files etc.

There are a number of GCode Senders. They are all equally simple. Here are a few

• bCNC
• Universal GCode Sender (UGS)
• ioSender
• Candle
• GrblPanel

Yea I wondered why there are no ARM ports but there are several?

There are a lot.  I counted something like 20 before I gave up looking. 

[Simon]

Yea I wondered why there are no ARM ports but there are several?

There are a lot.  I counted something like 20 before I gave up looking. 

Err, I never actually looked? I'm not interested in putting GRBL into anything, I want to talk to something that I am told uses it as the communication protocol.

[Doctorandus_P]

GBRL?

Atmel 386P ?
Huh?

A few years ago I burned one of the many STM32 clones of GRBL into a Blue Pill and it works quite well. Dwell time is off, but that's probably because of the big change in clock frequency. I've also found a version for STM32 that supports upto 6 axis (from a french guy on github) but I have not done much with that yet.

The "gnea" maintainers on github there is a long thread (100+ posts running for several years) about switching to a more capable microcontroller. The atmega328 on which it started is bursting out of it's seams (So forget the "no compromise" part). From my experience the "Blue Pill" (STM32F103C8T6) is a quite reasonable uC for GRBL. It's quick enough to handle the current algorithms and it uses hardware USB instead of some half baked USB to serial chip.

The fork I used is a pretty straightforward port (except for the USB part) so it does not make use of things like DMA or other "more advanced" features of the STM32.

For the PC part I use bCNC.
I has some extra possibilities, such as importing .dxf files then applying tool offsets, making tabs and genereating toolpaths before sending G-codes to GRBL.

[Simon]

I don't even know what chip those 3018 CNC machines are using, for all I know it is ARM based. It's a QFP probably 32 pin, could be anything.

[Doctorandus_P]

One of those things with a ground off partnumber?

For an 32 pin device my first guess would be an Atmega328, and a quick check for power pins, reset and crystal locations can quickly verify that.

Soldering in an upgrade (STM32 / Blue Pill) would not be that difficult either. Most of the pins are unused. You mostly need the step and direction signals, PWM for the spindle and probably some end switches.

But if the PCB works good enough there is not much need to mess with it.

[Simon]

Yea I am not bothered what it has. If I don't like it at some point I'd just change the controller.

[Simon]

I will be doing a PCB with a keypad that talks to the machine over a serial port so that I can control it. That's all. but when you read the information from the source that talks about any speed over 115kbps the natural question is OK so surely that is a synchronous port? all this basic stuff is not explained on github because that was all written for the arduino which is a complete implementation of USB to serial to GRBL on a specific peice of hardware - the Arduino.

I assume things have progressed somewhat, a few years ago I sold a guy an ATMega328, I usually sold them blank or with a 8MHz or 16MHz Arduino bootloader flashed in. This guy wanted something specific which I did as a one off favour as he did not have a programmer or know how to do it he just wanted to make a controller for his CNC machine and it had something to do with Arduino but with an alternative bootloader. So I don't know if there was a time when rather than be an Arduino library it was an Arduino hardware compatible program so that off the shelf boards could be used by people like this chap that was more interested in CNC than electronics but was willing to dabble.

[Simon]

To be honest good code should be documented, this is what I hate about the open source world, the answer is always "read the code" why should I have to do that? Ultimately I have no idea what is on the machine I am getting and they say it has documentation so I will wait and see what I get.

I'm not using this to do machining, i just want an XYZ bed that I can control.

[cgroen]

The issue of why didn't the gnea team port it to a 32-bit processor has been the source of much discussion but the fact is, they didn't. Grbl/gnea is tied very closely to the Atmel 386P, mixing motion control with direct manipulation of processor registers. I've heard more than one developer talk about spaghetti code. Grbl sat in maintenance mode for a number of years and in that time other developers got tired of waiting and ported it themselves.  That lead to fragmentation as no strong developer can possibly not add a few new features along the way. I wrote about that here. I am actually glad the original team didn't port to the Dué because it is kind of a dog processor and pricey for what you get.  It would have stopped a lot of developers from porting. Consider the Teensy 4.0 - 600 MHz iMXRT 1062 ARM M7 with huge amounts of flash and RAM - only $20 USD. With a real FPU, the grblHAL port shines on it. There is a fair amount of info on the site in the Wiki, Discussions and the source code.

I made a breakout board for it that I sell on Tindie.  Here are some machines based on it. It supports Ethernet as well as USB.

Nice board you have made there Phil