Hello Open Builds Community! I'm the lead developer of the Grbl CNC project, which is the firmware that runs most of the Arduino/AVR-based CNC machines out there. Mark Carew has recently brought me on board, and I'll be available to answer any Grbl-related questions or help troubleshoot problems here on this forum. Please feel free to start a new thread. Thanks!
Super and welcome ... I'll need to find my wish list ... right after I update to the latest release of GRBL. I'm still running .8 on CNC xPro.
I would like to use your software to control a small rotary engraver, like a stand alone 4th rotary axis rotating on Y axis. Is this doable. Thanks
I'm not 100% sure what you are asking, but Grbl is 3-axis only at this time. It will support a 4th motor as a rotary or dual gantry fairly soon. Until then, I also don't see it being an issue to hook up a dedicated Arduino with Grbl to just run the rotary axis only. You would connect to it as a separate serial connection.
Hey Sonny! Any word on when Grbl will make the leap to the Zero or Due? Thanks for all you hard work! Matt
*In a Mr. Burns voice* Excellent... Any hints on new features? uSD/LCD/independent Y Endtops? And Zero is the standard? It'll be nice to get back into electronics design this fall and winter. Thanks in advance, Matt
I've made a recent decision to not announce anything before it's ready. Mainly because I already have a huge backlog of promised features that I need to install. But the two main things that are just recently released or near completion are a parking motion and real-time overrides, which include rapid, feed, and spindle overrides (still not sure if it'll get crammed into the 328p, but Mega2560 works great). The parking motion works just like Grbl's real-time feed hold, but it retracts the spindle X amount, disables it, and moves to a park position near the top of Z. When resumed, it'll reverse order, repower the spindle, wait to spin up, and go on its merry way. I've gotten a ton of positive feedback from beta testers on this.
I just have a quick question. I'm running grbl .9h and having a bit of trouble with limit switches intermittently tripping the arduino. When it trips I just get a "Hard Limit" error message in the sender. Is it possible for grbl to send the error message on exactly what switch tripped ie; X Hard limit error ? I have 2 micro switches per axis in parallel on the X and Y and one single on the Z. Thanks in advance ! Gerald
Part of the problem is available flash space. Strings (used error reporting) take up a tremendous amount of flash space without being very useful. There has to be some trades between usability and function. Unfortunately, this means some things like which axis tripped has to be a bit vague. When Grbl moves on from the 328p and has more flash space, I'll make certain that reporting which axis tripped is in there. But, there is another solution though. A new '?' status report option can tell you the limit switch state. If you set $10=255, this will enable all status reports. Note that not many of the GUIs support these new status reports. So you may need to ask GUI writers to add this. See the Configuring Grbl v0.9 wiki on details on how these new reports work.
Thank you for the response, I understand now... I will try the new "?" status report option with the GUI senders i'm testing... Much appreciated !! Gerald
Sorry about all the false starts there I'm relatively new to the CNC world and finished assembling my c-beam machine last week. I got it working fine by following the 2 hour tutorial and was able to successfully cutout a couple of items I designed in Sketchup. The problems started when I installed my limit switches and tried to do a home cycle. The initial tutorial said that the software considers the front, left corner as the zero xyz point. When I enabled homing, it runs all motors in their positive direction which lands the router in the back right corner with the router up as high as it can go. When I tried to run those same files again, the alarm went off immediately as the machine hit its X limit immediately. Apparently the machine didn't get the memo that our new homing direction was the opposite corner. Any ideas on how to fix this?
You need to change the $23 setting in GRBL. https://github.com/grbl/grbl/wiki/Configuring-Grbl-v0.9 I am configured in the same way as you are, and have $23=3, which sets the homing travel for x and y in the opposite direction. $23=7 will reverse x, y, and z. -- John
Sonny, been fooling around with a through-hole PCB for GRBL + zero. https://drive.google.com/open?id=0B6yPgtXXa9tXTkpvdkt6eTZhWE0 I wish the zero had a smaller footprint...lots of wasted space at the moment. Not really happy with it, but it's a start.
Ah. That Zero. Thought you were talking about some small PCB mill called zero. There is also the Neutrino that is coming out that looks like a Teensy. I'm pretty sure that SparkFun and Adafruit will be releasing a mini-Zero soon as well.
Sonny, has there been any interest in factoring GRBL into layered libraries? Some of the lower level functionality could be useful in projects that don't require G-code. For example, GRBL's 30kHz step-frequency is really decent. The next best I can find in a library is AccelStepper's 4kHz and that doesn't control multiple steppers. It would be really useful to have GRBL's stepper and acceleration control without the G-code support, only because this would free up resources for other things. I'll use my current project as an example: I'm working on a camera slider with a single linear axis and two rotational axes (alt-azimuth for the camera). I'd like GRBL's efficient stepper and acceleration control, but would happily fore-go the higher-level G-code functionality if it would free up the resources to run a simple user interface. This would allow me to run the whole thing on a single Arduino Pro Mini. As is, I'm torn between writing only what I need (with inspiration from GRBL) or adding a Raspberry Pi to the project. In looking at the GRBL source code, I'm not really seeing a natural place to divide it into one or more libraries. It seems like doing so would be difficult at best. But perhaps someone more familiar with the code might have some ideas as to where to begin.
Sorry for the delay. Been incredibly busy with the day job. Yes, I plan on trying to make Grbl's code more portable, so you can do things like your camera slider. The main issue with doing this now is a lot of coding choices in Grbl's current source was made based on making the compiled flash size as small as possible to fit onto the Arduino Uno. Accessibility via the Arduino Uno has been one of Grbl's main tenants. However, at this point, Grbl needs to finally move onto a larger and more capable processor. When this happens, I plan on refactoring the entire source code and modularizing everything further. I plan to start working on this in earnest after the final v1.0 release for the Uno. Grbl v1.0 will also support the Mega2560 so users can have a 4th axis and other new features not possible on the Uno due to available room. What that next processor is, I can't say, but I have narrowed it down to two. As for dealing with the current code, you should be able to take out the g-code section and simply call the mc_line() routine directly. This is the gateway to the acceleration planner and stepper motion. There might be some dependencies with some gcode variables, but I can't tell you off hand what types of problems you'll run into.
Thanks for the reply Sonny. And let me express some shock that GRBL isn't your day job. I hope that your work on GRBL compensates you in a form other than thank-yous and good wishes. Pointing out mc-line() as a way around the G-code code is a huge help. Thanks you very much for that. Many of us will empathize with the necessity for GRBL to move to a new architecture to continue to progress. On the other hand, the fact that GRBL started on an architecture that is very cheap was important to its success. With Due clones available for under $20, which is more than I paid for most of my Unos a couple of years ago, it's time.
I spent the weekend pondering running GRBL on my Mega2560. I noticed that the pinouts are on 2 separate ports, PORTA and PORTC. I also noticed that the pins chosen are in a triangle, 24 25 26. after some googling and contemplation I changed them to be all the odd pins '25 27 29' IIRC. This means I can make a rudimentary shield with a single row of pins. Hope it works. A sideways question though, will the 5v coming off the mega board be able to run my 4xA4988 stepper drivers or should I be adding a separate regulator for them?
GRbl's MEGA build is user-supported and I have never checked how the pin layout was designed. I just know it's not compatible with existing shields, which I'm not a fan of. That said, I plan on taking a look at this and making an official pin layout for Grbl v1.0. So, it may change ( but you should be able to keep the old layout with a configuration file). If you mean power the logic side of four A4988 stepper drivers, it should be possible. I've built my own shield once with three A4988 stepper drivers and had an Arduino Uno powering them (I think). I would check the amps required for each A4988 and compare the sum to the maximum output of the Arduino 5V pin, just to be sure.
No problem. Up until this year, it was just thank-yous, a few companies sending me a machine or electronics here and there, and small donations through the site link. But, as of now, Grbl has sponsors! This includes OpenBuilds through their FairShare program. I'm forever grateful to Mark for doing that. It's allowed me to setup my "lab" with better equipment for the long haul.
I am starting a new project that is a saw stop. A simple one axis machine. I want to start from our production system that uses MS access as I will need to coordinate labels coming out along with the moves. My needs are pretty simple, Homing and moving to a X location. What I need is a way to send a single G code from access. I have looked at several gcode software programs for grbl but none have much in the way of documentation. Any suggestions would be appreciated.
Most of the documentation on how to interface with Grbl is written up on github.com/grbl/grbl/wiki. Basically, you'll need to connect to Grbl via a serial interface, which should be available on just about any programming language in some form. Grbl accepts a single line of g-code to execute and will reply when it's been parsed and planned to be executed. It has an internal buffer, so you just need to maintain a steady stream of g-code commands to keep it full. This is all explained in detail in the Wiki interfacing page. For one axis homing, you'll also need to tweak the config.h since Grbl defaults to 3-axis homing. It's fairly easy and well commented. Let me know if you have any problems.
Thanks, feel dumb for looking for documentation on loaders but not grbl itself. After looking at the grbl docs it seem rather straightforward. I have written an entire production system and postprocessor in access and managed not to learn VB. I just copy and mod code when I need it. Looks like its time to learn the basics of VB
Hey! I am wanting to make a cnc using the steppermotors of cd rom drives. I have done some research, and i found out that if you want to run GRBL on a raspberry pi, you still need an arduino to hook up the steppermotor drivers. I also saw someone controlling the steppermotor drivers directly with a raspberry pi (the steppermotor drivers where hooked up to the i/o pins on the raspberry) , but he made a python program in wich (when its running) he could set each motor (x, y and z) to a certain position. Is there anyway that you could run GRBL on the raspberry pi (with raspbian as os) and use GRBL to control the drivers that are directly hooked up to the raspberry pi?
Hi @finnj. Grbl only runs on an AVR micro controller unit (MCU) at this time, and will always run on a separate controller. Here's why. A micro controller is bare-metal programming. You have all of the attention of the MCU and have full control of what happens and when. So you can easily guarantee its operation. Plus they are very cheap. A Linux system like the Raspberry Pi or any modern OS isn't bare-metal programming. There are always system background tasks running that usually have a high priority than applications, and CNC programs like Mach3 and LinuxCNC have to heavily modify the OS, in some cases directly, to accommodate real-time step generation and everything else that goes along with it. In other words, OS background task cause a lot of jitter, or an un-smooth stream of step pulses. Jitter ends up causing problems with stepper motion and can cause loss of steps unpredictably, or more often limits how fast you can reliably run your stepper motors. So to answer your question, yes, you can run steppers with Python on the RPi through the IO pins for simple tasks, but don't expect it run very reliably for something high-performance. I don't plan on porting Grbl to run on an OS for the reasons above.
Thanks for you answer, luckily i have a arduino laying around that i can use, it wont be as compact, but it will do. If you are ever in the need of moderators or someone to help do some research or anything like that, then i would love to help.
