EEVblog Electronics Community Forum

Electronics => Mechanical & Automation Engineering => Topic started by: Simon on December 24, 2020, 02:11:39 pm

Title: GBRL why the mystery?
Post by: Simon on December 24, 2020, 02:11:39 pm
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 (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?
Title: Re: GBRL why the mystery?
Post by: Ian.M on December 24, 2020, 03:42:20 pm
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
Title: Re: GBRL why the mystery?
Post by: Simon on December 24, 2020, 03:48:19 pm
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.
Title: Re: GBRL why the mystery?
Post by: Ian.M on December 24, 2020, 06:14:28 pm
This: https://github.com/gnea/grbl/wiki/Using-Grbl may help.

You send G-code (https://en.wikipedia.org/wiki/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).
Title: Re: GBRL why the mystery?
Post by: Simon on December 24, 2020, 08:18:52 pm
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.
Title: Re: GBRL why the mystery?
Post by: Ian.M on December 24, 2020, 08:45:00 pm
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.
Title: Re: GBRL why the mystery?
Post by: Simon on December 24, 2020, 08:47:13 pm
All I am concerned with is being able to move the 3 axis's 
Title: Re: GBRL why the mystery?
Post by: Simon on December 24, 2020, 08:52:05 pm
Even on the GRBL help pages they just send you to the linuxCNC G-code implementation but admit that they also use other standards :palm:
Title: Re: GBRL why the mystery?
Post by: phil from seattle on December 29, 2020, 08:18:47 am
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 (https://wiki.shapeoko.com/index.php/G-Code).

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 (https://github.com/gnea/grbl). 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 (https://github.com/terjeio/grblHAL) which runs on 13 different microcontrollers including a 600 MHz NXP Processor on the Teensy 4.1.
Title: Re: GBRL why the mystery?
Post by: Simon on December 29, 2020, 08:36:06 am
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.
Title: Re: GBRL why the mystery?
Post by: phil from seattle on December 29, 2020, 06:42:33 pm
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 (https://www.grbl.org/what-is-grblhal). 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 (https://github.com/terjeio/grblHAL) 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 (https://www.grbl.org/grblhal-breakout-board) that I sell on Tindie.  Here are some machines based on it (https://www.grbl.org/t41-examples). It supports Ethernet as well as USB.
Title: Re: GBRL why the mystery?
Post by: Simon on December 29, 2020, 09:45:29 pm
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.
Title: Re: GBRL why the mystery?
Post by: langwadt on December 29, 2020, 10:03:03 pm
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
Title: Re: GBRL why the mystery?
Post by: Gyro on December 29, 2020, 10:13:29 pm
The simplest way to drive them over USB from the PC is using Grblcontrol, now called Candle.  https://github.com/Denvi/Candle (https://github.com/Denvi/Candle)

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

Title: Re: GBRL why the mystery?
Post by: Simon on December 29, 2020, 10:22:34 pm
OK, all I need to do is move the 3 axis's 
Title: Re: GBRL why the mystery?
Post by: langwadt on December 29, 2020, 10:44:18 pm
OK, all I need to do is move the 3 axis's

G0 or G1
Title: Re: GBRL why the mystery?
Post by: phil from seattle on December 29, 2020, 10:59:26 pm
The simplest way to drive them over USB from the PC is using Grblcontrol, now called Candle.  https://github.com/Denvi/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

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. 
Title: Re: GBRL why the mystery?
Post by: Simon on December 30, 2020, 08:15:42 am

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.
Title: Re: GBRL why the mystery?
Post by: Doctorandus_P on December 30, 2020, 08:23:31 am
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.
Title: Re: GBRL why the mystery?
Post by: Simon on December 30, 2020, 08:26:30 am
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.
Title: Re: GBRL why the mystery?
Post by: Doctorandus_P on December 30, 2020, 08:35:26 am
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.
Title: Re: GBRL why the mystery?
Post by: Simon on December 30, 2020, 08:37:17 am
Yea I am not bothered what it has. If I don't like it at some point I'd just change the controller.
Title: Re: GBRL why the mystery?
Post by: Simon on December 30, 2020, 09:52:09 am
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.
Title: Re: GBRL why the mystery?
Post by: Simon on December 30, 2020, 10:04:29 am
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.
Title: Re: GBRL why the mystery?
Post by: cgroen on December 30, 2020, 10:36:55 am
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 (https://www.grbl.org/what-is-grblhal). 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 (https://github.com/terjeio/grblHAL) 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 (https://www.grbl.org/grblhal-breakout-board) that I sell on Tindie.  Here are some machines based on it (https://www.grbl.org/t41-examples). It supports Ethernet as well as USB.

Nice board you have made there Phil  :-+
Title: Re: GBRL why the mystery?
Post by: langwadt on December 30, 2020, 01:21:05 pm
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.

GRBL is not and has never been arduino, it's plain C that just runs on arduino HW and you can program the HW via the arduino IDE

I don't understand the confusion over the serial port. GRBLs interface to the world is the AVR UART, default is 115.2kbps but you can program
it to any baudrate you like.
Title: Re: GBRL why the mystery?
Post by: phil from seattle on December 30, 2020, 08:21:50 pm
The Grbl Wiki (that I pointed you to) has a fairly extensive section about interfacing to Grbl and how to keep it running smoothly while feeding it GCode.  So, to answer your "I just want to use it" question, look there.

Quote
Nice board you have made there Phil
  Thanks!

Quote
the answer is always "read the code" why should I have to do that?
Well, in a perfect world the developer would have put the effort in to equal the amount of effort that the professional product developers did.  So, no, you shouldn't have to. Bunch of good-for-nothing, lazy FOSS developers. What's the world coming to??? :-DD

Title: Re: GBRL why the mystery?
Post by: Simon on January 03, 2021, 11:56:21 am

Quote
the answer is always "read the code" why should I have to do that?
Well, in a perfect world the developer would have put the effort in to equal the amount of effort that the professional product developers did.  So, no, you shouldn't have to. Bunch of good-for-nothing, lazy FOSS developers. What's the world coming to??? :-DD



Yes of course but when you have to read the entirety of the code to figure it out you end up in a position where you may as well write it yourself which is where I ended up with micro-controller manufacturer middleware where to use what the manufacturer gives you you need intimate knowledge of the chip anyway and to reverse engineer the code (read it all and see what it does) at which point it's easier to write my own as I study the the datasheet of the part. Obviously something like grbl is more complex but there is this tendency to "be clever" and then not explain it when it comes to programmers. It's the same reason why Linux will never take hold even if it's better than windows, we can all (within reason) use windows as it's made for the non technical user unlike linux.

Presumably open source projects are therefore about just showing off to your peers.

My machine has arrived. The frame is built up although they missed some of the nuts that slide into the extrusion to mount the controller so will see if I can get those before powering it up as I'd rather mount the controller properly. The controller is based on an ATMega328. Strangely it claims two Y axis outputs but I assume these are simply parallel connectors for motors that will be driven together either side of a frame.
Title: Re: GBRL why the mystery?
Post by: Simon on January 03, 2021, 02:08:04 pm
No I don't want to make this a linux versus windows thread and I am talking about the types of people that use them rather than the platform itself. I also meant just the two OSes not the possibility of commercial offerings on Linux. And of course often hidden behind the "free" is a commercial interest. When I started with hosting I tried Vesta cp, oh wonderful, free. But there was a bug after an update that apparently was well known about and with some difficulty I got help to resolve the issue with software that I was being told was wonderful and free but was known to have a bug that needed a file editing with a text editor on update. When I was faced with further problems and with an unhelpful "support" forum I was offered commercial help to the tune of £100 for an hour or two. For less than that I can rent cPanel that broadly works out of the box and has some support. Obviously if I was deeply knowledgeable about Vestacp and doing largescale hosting it would pay for me to invest the time in learning it inside out given the huge savings in cPanel licensing which is what some actual hosting companies do, but this is out of reach of little old me that just wants to host a few sites for friends and it's easier to pay what vestacp support costs by the hour for an entire year of trouble free software operation.
Title: Re: GBRL why the mystery?
Post by: Simon on January 03, 2021, 02:12:00 pm
With the dual Y axis drive it is just a cheap and dirty way of doing it to put two same axis motors in parallel. There is 1 X socket, 2 Y sockets and one Z socket, but each axis is driven by an identical plug in driver so clearly it's just two sockets in parallel as if the driver was truly dual channel then only two drivers would be required for the 4 sockets. As things stand with this machine it's only one Y axis so the question is just academic.
Title: Re: GBRL why the mystery?
Post by: phil from seattle on January 05, 2021, 07:58:05 pm
Yes, at the bottom end of the CNC market the Chinese Grbl based controllers only have 3 axis outputs and thus a ganged motor axis simply takes the Y Axis output and shares it with 2 drivers.  For those little stepstick stepper drivers, it's not the end of the world.

Sadly, this makes auto-alignment impossible for a ganged Axis machine. Manual alignment isn't terribly hard but it is a bit tedious. There are breakout boards that support auto alignment though.
Title: Re: GBRL why the mystery?
Post by: LaserSteve on March 05, 2021, 09:37:01 pm
Has any one here ever demonstrably done single axis homing in GRBL?  I love it, but I have struggled making a single axis configuration that homes without crashing.

Steve 
Title: Re: GBRL why the mystery?
Post by: langwadt on March 05, 2021, 09:45:22 pm
Has any one here ever demonstrably done single axis homing in GRBL?  I love it, but I have struggled making a single axis configuration that homes without crashing.

Steve

what did you do? it works just fine, in config.h define HOMING_CYCLE_0 as the axis you want to home, don't define HOMING_CYCLE_1 etc.