-
Notifications
You must be signed in to change notification settings - Fork 0
Frequently Asked Questions
Please feel free to contribute more up-to-date answers or questions!
The pre-compiled Grbl HEX files are located in the Downloads tab on the main front page.
Yes, it should. The compiled HEX file is in hexidecimal format, not binary. So it can be somewhat larger than the 32K flash limit on Arduinos. No more than about double the 32K, though.
Please check the Wiki help pages for details. If they are not up-to-date, please notify us or update them if you found they were in error or have another method. Thanks!
No, grbl fits on the ATmega328P without having to overwrite the bootloader; you will still be able to upload Arduino sketches after flashing without having to re-burn the bootloader.
The Arduino bootloader takes a second or two to boot up before Grbl initializes. During this time, the stepper enable pin is LOW, which is enabled, before Grbl finishes its initialization and sets the pin to HIGH to disable the steppers. This brief moment makes your stepper drivers susceptible to electronic noise, so if your driver step pins have enough noise to falsely indicate a step, your steppers may start moving erratically.
We are looking into this, but this may be an unavoidable problem with straight-up Arduinos. There a some solutions however. You can try to locate the source of the electronic noise and remove it (a fan too close the other electronics). You can place a pull-up resistor on the stepper enable line to disable the steppers during the boot-up process. You can also remove the Arduino bootloader altogether and install Grbl through the ISCP header, which requires specific hardware to do it.
When the Arduino board is USB powered and the stepper drivers have their own logic voltage supply, don't forget to connect the ground of both circuits.
Grbl communicates through the serial port, just as in the Arduino IDE. You may connect to it via any standard serial terminal program (Coolterm) at 9600 baud. Once you are connected, you should be presented with a short message indicating the Grbl version and settings how-to. Just type valid g-code commands followed by an enter and Grbl should respond with an ok or an error: message. Note: You won't see any character echos as you type commands to Grbl.
Streaming g-code programs to Grbl may be done by a simple call-and-response method through the serial port. Every command followed by a return is responded to when Grbl is ready to receive another command. See the Using Grbl wiki page for more details, as there are multiple streaming scripts and GUI's available to do this for you.
You would think that just uploading a file to Grbl would work, but it won't. This functionality requires some kind of serial flow control to indicate to the computer when the receiver's(Grbl) serial read buffer is full and when it's ready to get more data. The Arduino's hardware flow control lines are hardwired to reset and re-flash the Arduino, not for flow control. XON/XOFF software flow control is not officially supported by Arduinos, but they used to work on older Arduinos. This was due to a recent switch in the Arduino's USB-to-serial emulator chips, from FTDI to Atmega. The idea was to allow for people to flash their own firmware onto these emulator chips for their own nefarious needs, where FTDI chips were a closed-platform. This switch inadvertantly removed the FTDI's XON/XOFF software flow control support. As far as we know, there is no push to bring XON/XOFF flow control back. Although, since this firmware is now open-source, it may show up if someone does it or badgers the right people.
My stepper drivers require a time delay between the direction pin and step pin settings! (Or I'm noticing that my steppers drift after many many direction changes.) How do I configure this/fix this problem?
This problem comes from Grbl's main stepper algorithm. It sets the direction pin immediately before the stepper pins, which may not occur with enough time in between for certain stepper drivers to acknowledge a change in direction. This can cause a slight stepper drift after many direction changes. In the Grbl edge branch, there is an experimental compile-time option that creates a user-specified time delay after the direction pin is set and before the step pulse is initiated. This is done by enabling another interrupt (Timer2 compare). However, since it does add another interrupt, there is a chance that this can adversely effect Grbl's high-end performance (i.e. high step frequencies or complex curves), but this has not been thouroughly tested to verify this. If everything proves to be solid, we will consider adding this feature in later releases. So, please report any successes or problems with this feature! There is also a hack/work-around without needing to re-compile. The Grbl invert mask setting not can not only invert your direction pins, but also your stepper pins as well. So instead of being normal low, they can be normal high. Since most stepper drivers acknowledge a step by sensing only a rising(or falling) edge and the other is ignored, you can create a virtual direction pin time delay. Note that now your Grbl pulse microseconds settings will now define this time delay and you will no longer have any control over your step pulse time length (but this shouldn't matter since your stepper drivers shouldn't care.) Although there has been reports that certain stepper drivers don't like to be held normal high for prolonged periods, but it doesn't hurt to try. :)
There can be a lot of reasons for this, but the most common is electromagnetic interference. If you have AC power lines or your stepper motor wiring near the logic wires or USB cord, the electro-magnetics from these 'high' power lines can cause the logic lines to spike occasionally. This leads to weird connection problems, freezing, etc., etc. Make sure you route these clear of each other and if you can't try routing them at a 90deg to each other (works with ethernet cables, should work here as well). Another solution can be placing a small capacitor in parallel with your logic lines creating a high frequency low-pass filter. This will even out some of those spikes. Also, check for grounding. If your setup is poorly grounded, ground loops can cause the logic input voltages to be unstable. Make sure you star-ground wherever you can, especially your motor drivers.
In the past, users reporting this problem has typically been caused by too many devices on a shared AC circuit, poor grounding, a vacuum motor too close, or a logic line too close to a cooling fan.
Also, if you are dropping lines when streaming, this could be caused by a problem with USB-to-serial drivers on particular computers or environments (Java). It's been reported that the Java-based Universal GcodeSender can drop lines, where the Grbl-supported Python streaming script does not. Please try using the supported streaming script as comparison if you are experiencing this problem.
Grbl follows the NIST NGC/RS274 v3 standard for numerical control, aka g-code. EMC2 and Mach3 follows this standard very closely as well. Click the link to download and read the g-code standard document.
While we follow the NIST NGC/RS274 v3 standard, this is actually not completely standardized between all existing CNC machines and manufacturers. Numerical control is pretty old, arcane, and predates MS-DOS. In other words, it's a mess. There have been pushes to standardized it, like by NIST, and it has been successful for the most of common g-code commands. Yet, there are a few g-codes that are not standardized, like the g-codes G28/G30, G92.X, etc. It's a goal of Grbl to strictly follow one published standard so that people may build off of it, so that not to muddy the g-code waters even more.
This comes from a problem of how the arc are defined in g-codes. In radius mode (R), solving the path for a complete circle will cause severe numerical round-off problems that are unavoidable. This can lead to an error in the tool path. In incremental arc mode (I,J), this isn't a problem. Some CNC manufacturers actually don't allow users to draw a complete circle to avoid this problem altogether, limiting users to either a maximum 90 or 180 degree arc motions only. It is good practice to seperate all of your arc motions into 90 or 180 degree motions.
On v0.7 Master: Linear Motions (G0,G1), Arc Motions (G2,G3), Dwell (G4), Plane Selection (G17,G18,G19), Units (G20,G21), Homing* (G28,G30), Distance Modes (G90,G91), Feedrate Modes (G93,G94), Coordinate Offset (G92), Spindle Control (M3,M4,M5), and Others (G53,G80).
On v0.8 Edge: Work Coordinate Systems (G54,G55,G56,G57,G58,G59), Set Coordinate System Offsets (G10 L2,G10 L20), Go to Pre-Defined Position (G28,G30), Set Pre-Defined (aka Home) Position (G28.1,G30.1), Coordinate Offset Disable (G92.1), Coolant Control (M8,M9), and Program Stop (M0,M2,M30).