gnea / grbl-mega

An open source, embedded, high performance g-code-parser and CNC milling controller written in optimized C that will run on an Arduino Mega2560

---

Click the Release tab to download pre-compiled .hex files or just click here

---

Grbl is a no-compromise, high performance, low cost alternative to parallel-port-based motion control for CNC milling. This version of Grbl runs on an Arduino Mega2560 only.

The controller is written in highly optimized C utilizing every clever feature of the AVR-chips to achieve precise timing and asynchronous operation. It is able to maintain up to 30kHz of stable, jitter free control pulses.

It accepts standards-compliant g-code and has been tested with the output of several CAM tools with no problems. Arcs, circles and helical motion are fully supported, as well as, all other primary g-code commands. Macro functions, variables, and most canned cycles are not supported, but we think GUIs can do a much better job at translating them into straight g-code anyhow.

Grbl includes full acceleration management with look ahead. That means the controller will look up to 24 motions into the future and plan its velocities ahead to deliver smooth acceleration and jerk-free cornering.

• Licensing: Grbl is free software, released under the GPLv3 license.

• For more information and help, check out our Wiki pages! If you find that the information is out-dated, please to help us keep it updated by editing it or notifying our community! Thanks!

• Lead Developer: Sungeun "Sonny" Jeon, Ph.D. (USA) aka @chamnit

• Built on the wonderful Grbl v0.6 (2011) firmware written by Simen Svale Skogsrud (Norway).

---

Official Supporters of the Grbl CNC Project

---

##Update Summary for v1.1

• IMPORTANT: Your EEPROM will be wiped and restored with new settings. This is due to the addition of two new spindle speed '$' settings.

• Real-time Overrides : Alters the machine running state immediately with feed, rapid, spindle speed, spindle stop, and coolant toggle controls. This awesome new feature is common only on industrial machines, often used to optimize speeds and feeds while a job is running. Most hobby CNC's try to mimic this behavior, but usually have large amounts of lag. Grbl executes overrides in realtime and within tens of milliseconds.

• Jogging Mode : The new jogging commands are independent of the g-code parser, so that the parser state doesn't get altered and cause a potential crash if not restored properly. Documentation is included on how this works and how it can be used to control your machine via a joystick or rotary dial with a low-latency, satisfying response.

• Laser Mode : The new "laser" mode will cause Grbl to move continuously through consecutive G1, G2, and G3 commands with spindle speed changes. When "laser" mode is disabled, Grbl will instead come to a stop to ensure a spindle comes up to speed properly. Spindle speed overrides also work with laser mode so you can tweak the laser power, if you need to during the job. Switch between "laser" mode and "normal" mode via a $ setting.

  • Dynamic Laser Power Scaling with Speed : If your machine has low accelerations, Grbl will automagically scale the laser power based on how fast Grbl is traveling, so you won't have burnt corners when your CNC has to make a turn! Enabled by the M4 spindle CCW command when laser mode is enabled!

• Sleep Mode : Grbl may now be put to "sleep" via a $SLP command. This will disable everything, including the stepper drivers. Nice to have when you are leaving your machine unattended and want to power down everything automatically. Only a reset exits the sleep state.

• Significant Interface Improvements: Tweaked to increase overall performance, include lots more real-time data, and to simplify maintaining and writing GUIs. Based on direct feedback from multiple GUI developers and bench performance testing. NOTE: GUIs need to specifically update their code to be compatible with v1.1 and later.

  • New Status Reports: To account for the additional override data, status reports have been tweaked to cram more data into it, while still being smaller than before. Documentation is included, outlining how it has been changed.
  • Improved Error/Alarm Feedback : All Grbl error and alarm messages have been changed to providing a code. Each code is associated with a specific problem, so users will know exactly what is wrong without having to guess. Documentation and an easy to parse CSV is included in the repo.
  • Extended-ASCII realtime commands : All overrides and future real-time commands are defined in the extended-ASCII character space. Unfortunately not easily type-able on a keyboard, but helps prevent accidental commands from a g-code file having these characters and gives lots of space for future expansion.
  • Message Prefixes : Every message type from Grbl has a unique prefix to help GUIs immediately determine what the message is and parse it accordingly without having to know context. The prior interface had several instances of GUIs having to figure out the meaning of a message, which made everything more complicated than it needed to be.

• New OEM specific features, such as safety door parking, single configuration file build option, EEPROM restrictions and restoring controls, and storing product data information.

• New safety door parking motion as a compile-option. Grbl will retract, disable the spindle/coolant, and park near Z max. When resumed, it will perform these task in reverse order and continue the program. Highly configurable, even to add more than one parking motion. See config.h for details.

• New '$' Grbl settings for max and min spindle rpm. Allows for tweaking the PWM output to more closely match true spindle rpm. When max rpm is set to zero or less than min rpm, the PWM pin D11 will act like a simple enable on/off output.

• Updated G28 and G30 behavior from NIST to LinuxCNC g-code description. In short, if a intermediate motion is specified, only the axes specified will move to the stored coordinates, not all axes as before.

• Lots of minor bug fixes and refactoring to make the code more efficient and flexible.

List of Supported G-Codes in Grbl v1.1:
  - Non-Modal Commands: G4, G10L2, G10L20, G28, G30, G28.1, G30.1, G53, G92, G92.1
  - Motion Modes: G0, G1, G2, G3, G38.2, G38.3, G38.4, G38.5, G80
  - Feed Rate Modes: G93, G94
  - Unit Modes: G20, G21
  - Distance Modes: G90, G91
  - Arc IJK Distance Modes: G91.1
  - Plane Select Modes: G17, G18, G19
  - Tool Length Offset Modes: G43.1, G49
  - Cutter Compensation Modes: G40
  - Coordinate System Modes: G54, G55, G56, G57, G58, G59
  - Control Modes: G61
  - Program Flow: M0, M1, M2, M30*
  - Coolant Control: M7*, M8, M9
  - Spindle Control: M3, M4, M5
  - Valid Non-Command Words: F, I, J, K, L, N, P, R, S, T, X, Y, Z

---

Grbl is an open-source project and fueled by the free-time of our intrepid administrators and altruistic users. If you'd like to donate, all proceeds will be used to help fund supporting hardware and testing equipment. Thank you!

grbl-mega's Issues

Ramps 1.4

Please add Support for Ramps 1.4.

Date format changed

1- in Uno

grbl.h -> #define GRBL_VERSION_BUILD "20161219"
=> [VER:1.1d.20161025:]

2- in Mega

grbl.h -> #define GRBL_VERSION_BUILD "20161219.3"
=> [VER:1.1d.20161025.x:]

Could you change the separator => [VER: 1.1d.20161025-x:] ? This simplifies detection.

Svn644 compiles correctly, good job.

change USART

Is it possible to use a different USART on the Arduino mega?

I tried to change the USART in cpu_map.h from:
#define SERIAL_RX USART0_RX_vect
#define SERIAL_UDRE USART0_UDRE_vect

to

#define SERIAL_RX USART1_RX_vect
#define SERIAL_UDRE USART1_UDRE_vect

and then connect FTDI232 serial programmer but it out puts nothing.
Basically the Serial chip on my arduino mega is broken.
is it possible to change to a differnet serial port?

Better interrupt priorities

AVR is shackled by the fixed ( and unsuitably high ) priority of the serial interface. This means that USB has precedence over the motor pulses and anything but the most trivial serial I/O has to be disabled while motion is occurring.

In moving to less limited h/w lots of these necessary defects can be dealt with.

In experimenting with GRBL on STM32, I have increased the Gcode line length to the official NIST 256 chars and increased the txbuff to 1024. The latter is enough to buffer the output of $$, for example.

Most newer platforms will also allow freely assigned priority levels, so I have set the USB interrupts below the stepper timing pulses.

The aim is to enable commands like $$ during motion and use if to test whether the priorities are working and GRBL is producing stable pulses even with some continuous serial output running. This should be possible on fast h/w like STM32 even with a fairly fast step rate.

It seems like the pulse train should be the highest priority on the system not the serial I/O.

One $$ command works fine ( it's buffered ) but if I send two such command lines immediately by pasting them into my sender ( minicom ) it causes the motor to stall. I'm assuming that this is because there is a delay in one of the pulses resulting in a rapid change of speed which is tripping the motor up. It's running at about 10% down on it max. stable pulse rate on this mechanical hardware.

This maybe just something which I need to debug on the new platform but I was wondering whether I may be causing a glitch in GRBL's functioning in doing this in an untested context.

Any advice on that?
Thx

Frecuencia y velocidad de avance.

se dice que grbl puede aumentar hasta 100khz lo hice y pude aumentar el valor$110=30000 pero no veo un cambio considerable en la velocidad, no tengo como comprobar si los pines entregan esa frecuencia pero note que en un mando g1x300f1000 el máximo feed que alcance fue de tan soloF500, la pregunta es si el feed me esta limitando la velocidad en realidad y como lo puedo aumentar?
aclaración estoy usando un servomotor yaskawa incremental encoder con un máximo en la frecuencia de 500 Kpps.

CoreXY homing problem

Hello,
I built a CoreXY laser machine and I am using Mega2560+RAMPS combo with grbl-Mega 1.1f. I have a problem with homing. Simply put after initiating homing, only one motor moves at a time. That means when machine should be homing X first, then Y, it doesn't. The gantry moves diagonally because only one of the motors moves at a time. Jogging works without an issue. I tried Repetier firmware and there homing and jogging works both flawlessly. But it isn't grbl, which I want to use.

I downloaded fresh .zip file, extracted the grbl folder to Arduino\libraries and edited following in config.h (pure minimum to get things working):

• Commented lines 37 and 38 //#define DEFAULTS_GENERIC, //#define CPU_MAP_2560_INITIAL
• Uncommented lines 41 and 42 #define DEFAULTS_RAMPS_BOARD, #define CPU_MAP_2560_RAMPS_BOARD
• Commented line 112 //#define HOMING_CYCLE_2 (1<<Z_AXIS) and left line 110 and 111 uncommented #define HOMING_CYCLE_0 (1<<X_AXIS), #define HOMING_CYCLE_1 (1<<Y_AXIS)
• Uncommented line 190 #define COREXY
• Uncommented line 208 #define INVERT_MIN_LIMIT_PIN_MASK ((1<<X_AXIS) | (1<<Y_AXIS) | (1<<Z_AXIS)) to make my limit switches work as they should

This was my second attempt in case I missed something on the first try. I tried to edit the config.h as little as possible. But still homing doesn't work. Can you guys tell me what am I missing?

Thanks for any info.

ATMega16U2 virtual com port on ATMega2560

We have spent three days trying to get consistent communications with a Mega2560R3. The problem was the ATMega16U2. We could not consistently get welcome messages from the Mega2560 board. We found that cutting the trace so it would not Auto Reset has fixed most of these problems. Tried XON/XOFF and several other settings first. Some of these helped, but cutting the reset trace looks like the thing to try!

Trying to connect the Mega2560 to a Eleks Maker L6 or L7 board through the headers after the Nano has been removed. This is for the Chinese Benbox DIY kit laser engravers. then try to make a "Shield" that is specific to our laser machines after proving the concept and performance of the Mega2560.

jog after probe problem

I'm running the code on an STM32 so it entirely possible I screwed something up porting, but before
I start digging I'd like to know if it is a common issue.

The first jog following a probe, set the state to "run" rather than "jog" which means jog cancel is ignored
once it's back to idle any following jog works as expected, setting the state to jog and respecting cancel

after further investigation: after probing sys.step_control is 3, i.e. END and HOLD, to make the following jog work correctly I either have to issue a cycle start or a regular move

Feature proposal : 5 axis for grbl-Mega

Hi all,

The first version of GRBL-Mega-5X is here : https://github.com/fra589/grbl-Mega-5X

5-axis version for GRBL Mega with RAMPS 1.4
Since the RAMPS board has 5 stepper driver slots, I added the management of the 2 unmanaged stepper driver slots in the original version of gnea/grbl-Mega.

The number of axes is parameterized using the variable N_AXIS in the file grbl/nutbolts.h, the accepted values are 3, 4 or 5.
Great care has been taken to maintain compatibility with the original version gnea/grbl-Mega: By setting N_AXIS to 3, we get the same executable as the original GRBL with same other options.
This 5-axis version is currently limited to the use of the RAMP card. The 2 additional axes are the rotary axes A and B.

TODO: (without order priority, but I will continue to make it better)

• Make the same 5 axis functionalities for other hardware (DEFAULTS_GENERIC + CPU_MAP_2560_INITIAL), perhaps add 6th axis. :-)
• Possibility to choice which axes are enabled for 4, 5 (or 6) : A, B or C rotational axis or U, V, W linear axis.
• Add axis cloning for dual motors axis or else,
• ?

If you are interested I can make a push request to merge it in this branch...

Regards, Gauthier.

grbl reboot after clicking on start

Helleo

everyone

I have a big problem:
I use the grbl mega and i have a NEMA 17 stepper motor with an HY-DIV268N-5A Controller.
Sometimes it works but everytime when i start the Universal G-Code Sender, they is already in alarm mode.
If i type $X and trie to jog i get this error:

`Grbl 1.1f ['$' for help]

$$
$G
[MSG:'$H'|'$X' to unlock]
$0=255
$1=255
$2=255
$3=255
$4=1
$5=1
$6=1
$10=255
$11=2147483.648
$12=2147483.648
$13=1
$20=1
$21=1
$22=1
$23=255
$24=2147483.648
$25=2147483.648
$26=255
$27=2147483.648
$30=2147483648
$31=2147483648
$32=1
$100=2147483.648
$101=2147483.648
$102=2147483.648
$110=2147483.648
$111=2147483.648
$112=2147483.648
$120=2147483.648
$121=2147483.648
$122=2147483.648
$130=2147483.648
$131=2147483.648
$132=2147483.648
ok
[GC:G0 G54 G17 G21 G90 G94 M5 M9 T0 F0.0 S0]
ok
$J=G21G91Y8F10
(error:8) Grbl '$' command cannot be used unless Grbl is IDLE. Ensures smooth operation during a job.(error:8) Grbl '$' command cannot be used unless Grbl is IDLE. Ensures smooth operation during a job.`

If i try to load a g code and click on start the stepper motors dont move.
error:

`**** Connected to COM5 @ 115200 baud ****

Grbl 1.1f ['$' for help]
[MSG:'$H'|'$X' to unlock]

$$
$G
$0=255
$1=255
$2=255
$3=255
$4=1
$5=1
$6=1
$10=255
$11=2147483.648
$12=2147483.648
$13=1
$20=1
$21=1
$22=1
$23=255
$24=2147483.648
$25=2147483.648
$26=255
$27=2147483.648
$30=2147483648
$31=2147483648
$32=1
$100=2147483.648
$101=2147483.648
$102=2147483.648
$110=2147483.648
$111=2147483.648
$112=2147483.648
$120=2147483.648
$121=2147483.648
$122=2147483.648
$130=2147483.648
$131=2147483.648
$132=2147483.648
ok
[GC:G0 G54 G17 G21 G90 G94 M5 M9 T0 F0.0 S0]
ok
$X
[MSG:Caution: Unlocked]
ok
G17
G20
G90
G94
G54
M0
M5
M9
G0Z0.25F5
X-0.5Y0.
ok
G1Z0.
Skipping command #14
G2X0.Y-0.5I0.5J0.
G2X-0.5Y0.I0.J0.5
ok
ok
ok
ok`

then the active state is HOLD and i cant do anything

The only way to bring them in action is to click on return to zero. that work one time and then i must unplug and plug again the arduino.

i used pin 24 for PUL+, pin 25 for pul+, pin 30 and 31 for dir+
enove power is also there.

please help me fast :-)
Greetings Lukas

PWM frequency too low, motor noise

Hello how to change PWM frequency from 1.9khz to +-20khz? The problem is that then the frequency is lower my spindle motor generates hearable pitching noise and it is very anoying.

Parser state message question

As far as I know, grbl doesn't allow mixing $-commands ($G in this case) and regular G-codes together.
Even if it does, the solution is ugly. Is there a simple way to keep active codes up-to-date while streaming? Wiki says nothing about this. Thanks.

2 Y axis motors, one as inverted slave

I'm looking at the code and realized it doesn't seem to natively support two motors on one axis without using something like an external hex inverter.

I'm thinking that adding a Y2_STEP_BIT & Y_2_DIRECTION_BIT on the ports would work, as long as the step direction is inverted, right?

i.e. in cpu_map.h:
#define X_DIRECTION_BIT 7 // MEGA2560 Digital Pin 30
#define Y_DIRECTION_BIT 6 // MEGA2560 Digital Pin 31
#define Y2_DIRECTION_BIT 5 // MEGA2560 Digital Pin 32
#define Z_DIRECTION_BIT 4 // MEGA2560 Digital Pin 33
#define DIRECTION_MASK ((1<<X_DIRECTION_BIT)|1<<Y_DIRECTION_BIT)|(1<<Y2_DIRECTION_BIT)|(1<<Z_DIRECTION_BIT))

To get the Y direction inverted for Y2, that seems a bit trickier as I'm not super familiar with the code base. Setting N_AXIS in nuts_bolts.h to 4 and modifying get_direction_pin_mask() in settings.c to:

if ( axis_idx == Y_AXIS ) { return((1<<Y_DIRECTION_BIT)|(1<<~Y_DIRECTION_BIT)); }

seems like it might work, but I wanted to see if anyone had some thoughts or sees a glaring deficiency in my approach.

grbl port on xmega avr

hi
i have been working on grbl port on xmega controller i have seen an older port of grbl to xmega avr but thats V0.8 grbl port
i have added many new features as i have more processing power in xmega avr
at this moment i have few question
how to configure xmega uart for communication , how does serial communication works in grbl current release i am working on v1.0 version here i want to know that does serial communication use any "print" c library function or it uses only interrupt driven communication
if it uses only interrupt driven communication then it will be easier to configure xmega interrupts and i am good to go with it
second question is ADAPTIVE_MULTI_AXIS_STEP_SMOOTHING how does this works in real time and how to adopt this feature in xmega avr timer
waiting for quick guide

question about the download zip contents

Hi , I downloaded the zip file grbl-Mega.edge and I see under the grbl folder there is a "examples" folder. Is this "examples" required to be imported into the IDE ? Thanks

Real-time adjustable feedrates

sorry, i'm not good in write English
i waiting for Real-time adjustable feedrates and rapids overrides in version 1.0 , but it,s so long time
i had write Backlash compensation so good, but Real-time adjustable feedrates and rapids overrides so difficult.
can't you help me ?,

Adding outputs for external state signals

Addition for external signals would be very useful feature. Users would benefit having option for visual/audible indicators that tells machine state (cycle running, feed hold, idle and alarms), and they could be used to control other functions like interlocks with external PLC.

External alarm input would also be good addition, that stops machine and sets it locked state, for e.g. driver failure and other unrecoverable hardware faults.

These features could be more or less easily implementable for next release with mega2560 branch as pinout is still initial and there is no limitations with available I/O pins.

which g-code sender is being used in grbl-Mega testing?

I'm using UGS 1.0.9 but I am wondering which sender and build is being used in development/testing ? Seems to be working at least running gcode through so I'll hook up some drivers and steppers and test soon hopefully. cheers

just uploaded 2.0 classic (latest build oct 2nd) seems to work too. The UGS Platform looks good too but it started behaving weird so I went and loaded latest classic build.

4th axis ?

Bonne année à tous.
Happy New Year everyone.
Frohes Neues Jahr alle.
Buen año a todos.

@chamnit
Is the 4th axis (rotary or linear) planned ?
Or do we have to wait for 'Gnea' ?

One more control channel

Hello everyone!

Grbl is a great project! Many thanks to all the authors and participants!
Now, with grbl-Mega are opening new opportunities.

What about creating a second UART-channel for Realtime and Extended Realtime commands?
This will allow us to do an optional hardware control panels, with buttons, lamps and POTs
(with addition Arduino, of course).

The diagram says spindle PWM is on 7,, but it's next to the 4 pin

Which one is it??

Inches are EVIL!

When G20 is commanded, grbl starts reporting in inches no meter if $13 flag is set to 0!

error messages codes

what happened to the error descriptions ? in the previous versions the error messages (and the settings) has nice explanations, now it's all gone... :(

Spindle PWM non-functional

I am using this version of grbl-mega with a RAMPS 1.4 board:

$I
[VER:1.1f.20170802:]
[OPT:VNML,35,255]

$$
$0=10
$1=100
$2=0
$3=2
$4=0
$5=0
$6=0
$10=1
$11=0.020
$12=0.002
$13=0
$20=0
$21=0
$22=1
$23=0
$24=500.000
$25=2000.000
$26=250
$27=5.000
$30=255
$31=0
$32=0
$100=200.000
$101=200.000
$102=4535.000
$110=3000.000
$111=3000.000
$112=300.000
$120=400.000
$121=400.000
$122=55.000
$130=600.000
$131=600.000
$132=60.000

I don't get any spindle PWM. If I turn the spindle on with any value but zero (M3 S1) I get full on, and when I turn it off with M5 or M3 S0 it turns off, but I don't get any PWM. I've modified this section of cpu_map.h:

//Control Digital Pin 6 which is Servo 2 signal pin on Ramps 1.4 board
  #define SPINDLE_TCCRA_REGISTER    TCCR4A
  #define SPINDLE_TCCRB_REGISTER    TCCR4B
  #define SPINDLE_OCR_REGISTER      OCR4C
  #define SPINDLE_COMB_BIT          COM4C1

  // 1/8 Prescaler, 16-bit Fast PWM mode
  #define SPINDLE_TCCRA_INIT_MASK ((1<<WGM40) | (1<<WGM41))
  #define SPINDLE_TCCRB_INIT_MASK ((1<<WGM42) | (1<<WGM43) | (1<<CS41) | (1<<CS40)) 
  #define SPINDLE_OCRA_REGISTER   OCR4C // 16-bit Fast PWM mode requires top reset value stored here.
  #define SPINDLE_OCRA_TOP_VALUE  0x0100 // PWM counter reset value. Should be the same as PWM_MAX_VALUE in hex.

  // Define spindle output pins.
  #define SPINDLE_PWM_DDR   DDRH
  #define SPINDLE_PWM_PORT  PORTH
  #define SPINDLE_PWM_BIT   5 // MEGA2560 Digital Pin 8

Because I'm trying to use that PWM pin. It doesn't work for other pins, either. Enable and direction work correctly.

Thanks for any help you can give!

PWM on Ramps with grbl-MEGA not working. Only 0 to 5 volts nothing in between...

Hey folks. I can’t get PWM to function properly on Sainsmart RAMPS Mega2560 board with grbl-Mega.

First off - I’m checking output on D11. Correct pin for RAMPS? (I guess not but can't find any other pin that gives me 5 volts when sending an M3)

It’s all or nothing - 0 or 5 volts. I can switch it on and off with M3 and M5 but get no change when changing the S value.

I’ve been through the config.h spindle settings and checked cpu_map.h but nothing fixes this issue.

Everything works as it should on an UNO with normal GRBL but it would be useful to get some use out of this board.

Any ideas on how to sort this before this board is consigned to the parts bin?

Cheers

Possibility to redefine home location

Hi, I'm using grbl mega with bcnc. I have limit switches installed and have home in back-right-top corner so it's sort of in compliance with "all-negative workspace". When arduino is just loaded and connected, it reports machine coordinates as 0,0,0. After home cycle the coordinates become -1,-1,-1. Is it possible to change these values to 0,0,0 or better 1,1,1?
bcnc guys told me it's a grbl thing but I could not find it myself so far.

Shield for mega

Hi,
I'm trying to convert my chinese 3040 CNC with VFD spindle to operate from mega. I had a great success by making a proto-shield and outputting signals from mega to internal LPT-ready control board. Now I want to rid of that controller and run everything directly from mega. Trying to use another proto shield and having lots of troubles made me think if there are any mega shields available. Apparently, not. So, I want to try and make one myself.
I guess, my main question would be about optocouplers. While it's not a problem to find nice little optos for limit switches (817 are generally pretty good and there is a quad versions like LTV-847 available) I'm not so sure about spindle part. I need to turn spindle on/off, switch direction and provide 10v PWM for speed. I have a feeling that even if transistors would work for 10v PWM, it's better to isolate as much as possible. How would PWM go through an optocoupler; is opto quick enough for the task? Would something like this be good enough for on/off, direction and PWM?
Another thing, should stepper drivers be isolated as well? I mean, generally the drivers have optos on them anyway, but would having an extra be bad and slow everything down?
And lastly, considering that not many pins are really used on mega and the main reason that mega is used is for it's chip, would a dedicated driver board on 2560 be better than mega+shield?

New Connecting Grbl Wiki Page

I've created a new Connecting Grbl Wiki Page in this repo that is specific to the Mega. I had some trouble finding this information, so I thought making it a page would be helpful. The information came from this issue and I've copied just the first bit of the Connecting Grbl page from the main Wiki.

I filed this issue to let the maintainers know of the new page. If you find it not satisfactory please feel free to remove it.

Doxygen?

I was in the middle of regex'ing Grbl-Mega code comments for code documentation with Doxygen on a fork; but realized later I cannot publish these on my local 'forked' repository as far as I could determine. Please let me know if this incorrect.

So; I've copied the work into a non-forked repository and published it at https://tgit23.github.io/grbl-Mega-Doxy/index.html

I'd be willing to work on this further if it would be considered on a pull request. It would add a /docs directory to the repository and it may have to publish clear back on grbl/grbl (not sure on those details as it appears the grbl-Mega is also a 'fork'.

Anyways; thought I'd open this issue for discussion.

Lathe pulse input for threading (feature request)

Hey guys,
Just wanted to get this on the list for grbl mega. Not sure how this would be done but it would be nice to have the capability to do threading with a grbl controlled lathe.

If this should be with grbl arm I can move it. Not sure what the difference is between arm and mega.

Thanks!
Tim

Rounding error?

Not sure what's happening but when using multiple tool changes in a program (I do manual changing with probing after using bCNC) it all works ok on first tool change and probe, but on next one I get an error that requested move on Z exceeds machine limits. For some reason, it always tries to move 0.01mm or 0.001mm (not sure now) beyond limit. I have to break program and zero Z every time before tool change.
I asked this on bCNC git, they pointed towards this community, saying that it's something to do with rounding in grbl. Can anyone help please?

Spindle PWM Pin Swap

I'm wondering if there is a reason why the spindle PWM was set up to use OCR4A for the top value instead of simply using the fixed 10bit timer/counter. I had been trying to change the PWM output pin from Arduino Mega D8 to pin D6 and believe I have it working by changing timer4 to use the ICR4 register for the top value, OCR4A to set the duty cycle, and OC4A for the PWM output.

It may have been a simpler route to use a different OCR4x register for the top value but I could not figure out how to get that working. It also seems to me that just using the timer in fixed 10bit fast PWM would make setup easier.

I am by no means an expert and am only just now diving into GRBL while trying to get a laser diode setup. I am also new to the GitHub workflow so I apologize if this should be brought up elsewhere. BTW I have an Arduino Mega with Ramps 1.4.

Edit: I'm not familiar with driving a spindle but would a variable frequency be desired? In that case it would make sense to use those particular settings for the timer.

Problem to move stepper motor

Hi, i'm an italian guy and i building a homemade cnc with Arduino Mega2560 and driver Pololu MD09B mounted on shield. I bought that here (http://www.futurashop.it/shield-per-arduino-motori-stepper-in-kit-da-saldare-8190-stepshield?search=step%20shield). At this link technical documentation ad electrical circuit explanation.
I load with IDE this GRBL library but stepper motors not moving.
I try a simple sketch without library and in this case motors work fine.
My question: is possible than library have a wrong configuration for my hardware. You can drive me on correct way, I'm not an expert of electronics and i not understand very well the pins configuration of your library.
Thank you very much.
PS. Excuse my bad english but I'm at work and write speedy not to let me find out of my boss XD

I want to connect Arduino Mega [4 pins / stepper / per axis] (look image) how ?!!!

Add support for CO2/YAG lasers

The included support for lasers is nice but somewhat rudimentary. I don't know what kind of lasers can be accessed with this mode, but industrial lasers are not usable. So I would request some changes which would make it possible to connect more professional lasers:

For CO2 lasers:

• free to choose frequency for the laser PWM signal with frequencies of up to 200 kHz (or even more when possible)
• basic tickle pulse, so also when the laser should be turned off, this minimum tickle pulse is emitted at the PWM output (this is a frequency with a very small duty cycle)
• maximum duty cycle - instead of going to 100% duty cycle in case of full power, this maximum duty cycle should be applied to full power; value should be freely configurable in order to support different CO2 lasers

For YAG lasers:

• all the above
• plus: FPK signal which is a short pulse of freely definable width applied on an separate output whenever laser is turned on

Mega for heavy duty engraving laser job

hi ,
with enhanced memory of Mega2560 how much serial speed can be increased and what is the maximum stable buffer for heavy duty CNC job like laser engraving ?
BR

Feed speed varies?

Hi, I seem to have GRBL controlling my laser alright, but when I try to cut a SVG file (I'm using LaserWeb) the feed seems to really slow down around the arcs and then just take off on the straightaways.

I've confirmed the gcode only has one feed rate set.

I've done some searching but my google fu is failing me... is this a common thing for GRBL? Am I abusing it somehow? Is there somewhere in the source code I can look to understand what's happening?

Chatter reduction through variable speed control possible?

Would it be possible to add a speed variation for the spindle to counter chatter like described in this paper: http://oatao.univ-toulouse.fr/13508/1/Seguy_13508.pdf

To summarize: If the speed of the spindle is changed a bit in a triangular way it counters chatter in a significant way thus increasing tool life and surface finish.

The only two variables are: The amplitude of the change and the frequency (and this might be even hard coded as the paper says that the amplitude has the greater effect).

Example: Amplitude 1000 rpm, Frequency 1Hz. When the user sets the spindle to 10000rpm GRBL will linearly change the speed from 9000rpm to 11000rpm and back again over a period of 1 second.

I guess the UNO version does not have enough resources left to implement this. But would it be possible to add something like this the the Mega version?

Some more details if this should be implemented:
According to https://diy.haascnc.com/reference-docs/lathe-spindle-speed-variation Haas uses M38 and M39 to turn this feature on and off (although http://reprap.org/wiki/G-code#M38_Compute_SHA1_hash_of_target_file shows that RepRapFirmware uses M38 to "computer the hash of a file an an SD card") but the parameters itself are not changeable by G-Code, so having those as regular configuration variables should be fine.

Why is RAMPS D11 active in grbl-Mega when it's not defined in cpu_map.h

Surely this is an easy answer for someone?

$ command extentions

Oicking up a suggestion I made on the main GRBL git.
grbl#980 (comment)

I have been using GRBL with L6474 driver boards ( Arduino pin-out ) , which require some additional set-up parameters since they are a lot more configurable than the typical STEP/DIR boards commonly used.

The boards use classic STEP/DIR pins but the rest goes through a SPI daisychain including ENABLE / DISABLE.

There's a bunch of parameters like slew-rate etc that can be set but the main difference is programmable current setting; a hardware error FLAG and status byte which needs to be read to clear the error.

I have added a few $ commands to the GRBL interpreter to set and interrogate the various parameters and an interrupt to respond to error pin input. The most common error conditions are over-temperture warning, over-temperture error ( hard fault ) and supply under-voltage condition.

I am going to be tidying this up a bit now and wondered whether there are any guidelines for extending GRBL's interpreter so that I can avoid clashes with future work any maybe provide something of more general use.

As an example I have commands like the following to set chip parameters for each board:
$P[board_id]:[param_id]=[param_value]

Boards are becoming more configurable and this sort of situation will start becoming more common. If there is not any defined way of extending the current code set, it may be good think about providing one.

The primary requirement will obviously be to avoid clashes with any NIST GCODES and anything that may be tentatively in the making for additional GRBL commands.

Grbl has not finished booting. (Using 115200 baud)

Greetings,
I was able to get my Uno grbl running without any issues on a few different operating systems. However, I am trying to get a Mega loaded up since it's got more hardware resources and it's just not working for me.

I have tried every solution online it seems with no luck. I have tried every baud rate possible. I have use UGS, bCNC, SourceRabbit GCode Sender, and none of them connect to the Mega after loading grbl. I have used XLoader to upload the HEX file version and I also tried uploading with the Arduino IDE. None of them work. The HEX file was "grbl-Mega_v1.1f.20170802.hex", which appears to be the latest.

I am out of ideas to get this thing working. I saw a number of guys on youtube make this work with the identical pieces of equipment that I am using so I do not know what the issue is.

Any suggestions would be greatly appreciated.

what is gnea grbl mega?

What is gnea exactly?

pinout same as arduino uno?

This is my first Issue ever so please correct me if i am doing it wrong!
I compiled to mega version and uploaded to an arduino mega. I can communicate with grbl by universal gcode sender. But my old setup (i made a shield for my old arduino uno) doesnt work with the mega. Are the pinouts the same? If not this maybe should be mentioned on the wiki.

Compile for windows

Hi,

after >1 hour trying to install the GRBL libs through the Arduino IDE I somewhere found a description to simply

• copy the grbl folder to the libraries,
• restart the ide
• ready for compilation.

Worked instantly.

I think this should be mentioned on the installation / compile section in the grbl wiki. At least as an alternative.

Best regards,
JM.

Z-Enable pin on RAMPS 1.4 collides with CONTROL_RESET pin

I'm trying to run the GRBL-Mega firmware on a RAMPS 1.4 compatible board.
X and Y are running well but Z does not.
I've found both Z-Enable PIN and CONTROL_RESET PIN are set to the same PIN:
PK0 (digital 62 I think) and this prevents the Z from working.
If I change the CONTROL_RESET pin to PK1 the Z axis works.

I'm guessing that I missed something that's supposed to disable the CONTROL_RESET, am I right?

In any case it seems that whatever it is, the pin should be disabled in RAMPS configuration

laser connected to digital pin 10

Hi,

first, thanks for this awesome project!
I am trying to use it with the Makeblock Laserbot and their MegaPi board.
I mapped all the pins, but my last problem is the laser pin. The MegaPi uses digital Pin 10 (PB4/OC2A).
This means, that I need to use timer2 for PWM on this pin and this is an 8-bit timer... the current implementation uses 16bit-timers.

Can somebody help me with using PB4 for the laser?
This is my current code in cpu_map.h
`
// Advanced Configuration Below You should not need to touch these variables
// Set Timer up to use TIMER2A which is attached to Digital Pin 10 - PB4
// warning: Timer2 is an 8-bit timer!
#define SPINDLE_PWM_MAX_VALUE 255.0 // Translates to about 1.9 kHz PWM frequency at 1/8 prescaler
#ifndef SPINDLE_PWM_MIN_VALUE
#define SPINDLE_PWM_MIN_VALUE 1 // Must be greater than zero.
#endif
#define SPINDLE_PWM_OFF_VALUE 0
#define SPINDLE_PWM_RANGE (SPINDLE_PWM_MAX_VALUE-SPINDLE_PWM_MIN_VALUE)

//rb MegaPi THIS HAS TO BE CHANGED TO A DIFFERENT PIN! OC2A is for D10 (PB4)
//Control Digital Pin 6 which is Servo 2 signal pin on Ramps 1.4 board
//#define SPINDLE_TCCRA_REGISTER TCCR4A
//#define SPINDLE_TCCRB_REGISTER TCCR4B
//#define SPINDLE_OCR_REGISTER OCR4C
//#define SPINDLE_COMB_BIT COM4C1
#define SPINDLE_TCCRA_REGISTER TCCR2A
#define SPINDLE_TCCRB_REGISTER TCCR2B
#define SPINDLE_OCR_REGISTER OCR2A
#define SPINDLE_COMB_BIT COM2A0

// 1/8 Prescaler, Fast PWM mode
#define SPINDLE_TCCRA_INIT_MASK ((1<<WGM20) | (1<<WGM21))
#define SPINDLE_TCCRB_INIT_MASK ((1<<WGM22) | (1<<CS21))
#define SPINDLE_OCRA_REGISTER OCR2A // Fast PWM mode requires top reset value stored here.
#define SPINDLE_OCRA_TOP_VALUE 0xFF // PWM counter reset value. Should be the same as PWM_MAX_VALUE in hex.

// Define spindle output pins.
#define SPINDLE_PWM_DDR DDRB
#define SPINDLE_PWM_PORT PORTB
#define SPINDLE_PWM_BIT 4 // MEGA2560 Digital Pin 10 - 12v output MegaPi

// Define flood and mist coolant enable output pins.
#define SPINDLE_ENABLE_DDR DDRF
#define SPINDLE_ENABLE_PORT PORTF
#define SPINDLE_ENABLE_BIT 0 // MEGA2560 Analog Pin 0 - 12v output
#define SPINDLE_DIRECTION_DDR DDRG
#define SPINDLE_DIRECTION_PORT PORTG
#define SPINDLE_DIRECTION_BIT 2// MEGA2560 Digital Pin 39 - MegaPi P15 5x2 pin1

// Define flood and mist coolant enable output pins.
#define COOLANT_FLOOD_DDR DDRA
#define COOLANT_FLOOD_PORT PORTA
#define COOLANT_FLOOD_BIT 2 // MEGA2560 Digital Pin 24
#define COOLANT_MIST_DDR DDRA
#define COOLANT_MIST_PORT PORTA
#define COOLANT_MIST_BIT 0 // MEGA2560 Digital Pin 22
`

Feature request: "Axis auto-squaring"

I'm using a MPCNC with GRBL. I don't know if this happens with other machines as well, but at least with the MPCNC the axis can "twist" a bit. One way to counter this is to make a distance piece and start X and Y axis at one end with the distance piece to the edge so that both axis are perpendicular to the edge.

But for each axis that has one motor per side there is another solution: Install two limit switches and while homing drive both motors in sync as usual but stop stepping the first motor as soon as it hits its limit switch but continue with the second motor until it also hits its limit switch (maybe stop and enter an alarm state if this goes on for more than a centimeter or two). This needs two additional pins per axis: Two limit inputs and two step outputs (the direction pin of the two motors can be shared). If the limit switches are correctly installed the axis should be perfectly straight after that. I think this would only be needed for the X and Y axis as I have not seen a machine yet that has two motors for the Z axis. The MPCNC is probably the most prone to getting the axis skewed, but maybe some other machines can profit from this as well if only to a lesser degree.

The Mega should have enough pins to spare for a feature like this. Port PA (where the step ins are located now) has 8 pins so all additional pins could be on the same port and there is even room to grow to six axis if this should ever be viable in the future.

Pinout

Hi,

what is the actual Pinout for the mega?
I found a Pinout in this threat grbl#390 (comment)
Is this the right one?

Will the pinout change in the near future?

Greetings theblackraven

Axis position not updating GRBL-Mega 1.1e

The axes positions are not updating in this release, not sure if this is a known issue but here it is.
update:
this is not an issue, my mistake.

error 26 for full circles

HI!
Grbl gcode parser returns an error in case G2/G3 command has all axis words omitted. For example, "G3J10". It is quite strange behavior, since circles with no helix don't require those values at all. Only offset values are obligatory to calculate radius and center. Correct me if I'm wrong