Im running GRBL 0.9i on a scratch built machine Im having a couple of problems because im using standard measurement as opposed to metric and the machine setup readout stays in metric. Instead of writing a long novel im just going to bullet point my major problems. -I have $N0=G20F7.8 but the machine forgets to set itself to standard when I boot up and that screws up my homing process. it's dropping G20 for some reason. -The machine homes to the switches from where I start it but resets its zero once it hits them so it doesnt return to where I want it after it homes. It just reads "Alarm Lock" after it reports that it is OK - My workable area is 1054 in all axes but it keeps giving me a "soft limit" reached error. Any and all assistance is GREATLY appreciated as, at this point, I am clawing in the dark here. Thank you all. ~M
I've never been able to get soft limits to work on my machine, so I turned it off ($20=0). I have home pull-off set to 5mm ($27=5.000). I was having problems with no pull-off. I also found out that once I hit one of the limit switches, the machine reverts to metric and I have to reset it to metric, move one of the axes and set it back to inches.
Eww, imperial. Why'd ya wanna do that?! I only started looking at grbl a few days ago, but... $N0=G20 should work. Have you also tried setting $13=1? There may also be other imperial elements that probably ALL have to be changed to work together. I had a program randomly change G21 to G20 during its run, I'm still not entirely sure why. I was trying to test sub-mm motions and kept being very confused when it kept moving 5-12mm at a time! Possibly sounds like a debounce problem? Try changing $26. From the sounds of its description, $27 might be an issue in play as well. Do you have a real time DRO readout in your interface? Check what it's claiming as the work position when your machine starts complaining about soft limits. I'm not sure exactly how it could suddenly think it's past the limit, it seems like a prioritisation error, maybe: if you set safe distances from different points (eg. soft limits vs homing pull-off), one may say the machine's safe, the other may say it's out of bounds. Plus, there's a big difference between 1054" and 1054mm! Looks like grbl itself only accepts system settings in SI units, too, so make sure everything's converted appropriately (0.5" is a good $27, but 0.5mm might still engage switches!). I'm having a slightly hard time parsing the wording of the grbl GitHub wiki here, so I may have misunderstood something. I imagine @Sonny Jeon could be more specific.
Everything in Grbl's settings are in mm, steps, min, and sec. The units are given in the '$$' print out, next to the descriptions. The $N0=G20F7.8 should work after homing. Grbl will execute the startup lines immediately after homing completes. There was a problem with soft limits in a brief window of Grbl v0.9 versions, where the soft limit would pause the machine and not tell you. A '~' resume command would exit the pause and start the soft limit. That has since been fixed. Most problems with soft limits and homing are related to how Grbl sets its origin. When homing is complete, GRbl sets the machine space in all negative coordinates. Or the origin in back right corner of the machine (3d printers put it in the front left instead for different reasons!) This origin position is the standard operation of production CNC machines. Users often try to move to somewhere in positive space and get a soft limit error. Or their work coordinate (G54-G59) offsets are non-zero and not related to the homed position correctly. To set the machine in positive space or correct the offsets, you have to alter the G54 (-G59) work coordinate system(s). It's very simple to do. Just look at the G10L2 and G10L20 commands in the LinuxCNC gcode descriptions. Lastly, soft limits operate by looking at the MACHINE coordinates, not work coordinates. If they have a motion that moves the machine into positive machine space or (-) axis travel, it'll throw a soft limit alarm. Always look at the machine coordinates relative to your work coordinates. It will make more sense if you do.
This makes a lot of sense. Not having a complete machine and not yet testing limit switches, I haven't run into this yet, but I'll certainly try to bear this in mind. I've seen a lot of coordinate confusion on my travels, I'm hoping to avoid that myself, since I have to press it into commercial service in short order. Interesting. Haven't run into these yet at all (other than noticing the G54 etc. buttons in the bCNC GUI). Found the top level of the LinuxCNC guide, though: LinuxCNC "G-Code" Quick Reference Ah, good catch! I meant machine, not work. Not much use in using user-set parameters for absolute positioning!
from the GRBL-panel wiki so you do want to do a $13=1 to tell GRBL to default to inches. GRBL-panel will then display inches. Even so, Gcode can still be in inches or in mm, never assume the state of the machine is what you want, always put G20 or G21 in the header of the Gcode to make it absolutely clear what is going on. for the limit settings, you should read Configuring Grbl v0.9 · grbl/grbl Wiki · GitHub seems to me you either use soft limits OR you use hard limits.
Seems like there should be a Wiki page specifically on configuring a machine for permanent use in imperial measurements. Absolutely, I ran into this during testing. I'm assuming that despite working top-to-bottom in metric, one of my G-code or DXF conversions threw an imperial measurement in there for some reason. Pays to do a find-and-replace to check that you don't have any weird codes in there that you don't want. Unfortunately, machines just do what they're told! You may be right. "Hard limit work basically the same as soft limits, but use physical switches instead." I assumed, like everyone else, that the soft limits were there to avoid the hard limits being triggered and everything shutting down. But that implies that they're a replacement. I dunno, like I said before, it's a little difficult to parse the exact meanings of some parts of that Wiki. Shame, because it's otherwise one of the cleanest and most informative Wikis of any FOSS package I've ever come across!
Rob: You're unfortunately right that Grbl's Wiki could use more work, and I haven't had the time (or motivation) to update it in a while. However, it is a Wiki and users are encouraged to help, if possible. Could you possibly help in telling me what you'd like to add to the Wiki to help other users avoid the same problems you had? We could work together on this.
Haha, I totally get that. Once I'm actually building my machine (couple weeks, maybe?) and I'm looking harder at the limits and coordinate spaces stuff, I'll definitely get in touch and make some edit suggestions. I realised that grbl is more or less the "flash to an arduino and you're done" mass-market software that I was attempting to wend my way toward conceptualising and writing here: Open Software A-Z CAM | OpenBuilds - so instead of doing that, I'd rather just contribute a bit here and there to the grbl project.
Sonny, I'm having a hard time wrapping my head around these concepts. They just seem backwards to me from a coordinate system concept. If I place an object at the origin, that means the size of the object is -4" x -5" for example as opposed to 4" x 5". I have my machine set up so the origin is in the lower left corner. This could also be considered as the upper right corner, with me standing off of the upper edge of the machine. I have the coordinate system set up so that X and Y are both positive from the origin. I had to reverse the homing to get the X and Y to home towards the origin. It seems to me that this orientation makes more sense if the table moves instead of the tool, like on a milling machine. While the table moves in negative directions, the tool moves in positive directions. That being said, I have some questions. If I decide to keep the origin in the lower left corner, what other settings do I need to change? For instance, I know that I've never been able to get the soft limits to work. Would it be possible/beneficial to add a switch in the software that would reverse the entire coordinate system with one bit instead of having the need to make changes to many variables in nonconsecutive locations? Is there a benefit for me to change the origin so that it is an all negative coordinate system? Is the default to place the material in the upper left corner (lower left in my case) and route so that it comes out upside down? Or, am I supposed to figure out what the maximum X and Y dimensions are and use that as the origin and place the material there? I don't know of anyone who has the origin set in the upper right corner and stands at the bottom of the machine. I understand that GRBL is set up with the origin in the upper left corner because all commercial CNC machines are set up that way. I just can't figure out how to make it work with the machine I have in such a way that it makes sense to me. Thanks for your help, Steve Fox
A lot of questions. I'll try to answer most of them and make this clearer. If you search on the web, I've probably answered this question a few dozen times. It all comes down to a user needing to understand and start utilizing work coordinate systems, which are extremely useful and the main reason to have homing at all. Work coordinate systems allow you to pre-set locations all around your machine and repeatably come back to them within the error of your limit switches. How machine coordinates are situated should not effect you at all. Whether they are positive or all negative or a mix. As long as they are consistent, that's all that really matters. This is because Grbl and all CNC machines move in their work coordinate systems. Not machine coordinates. There are 6 work coordinate systems in Grbl (G54,G55,G56,G57,G58, and G59). They can all be set independently of each other to set a unique origin anywhere in the machine. For example, you can place a work coordinate origin in the front-left-top corner of the machine by doing this. Home the machine. Move the tool to the left-front-top corner. Set the work coordinate system here to [0,0,0] with the G10L20P0X0Y0Z0 command. It'll set the current work coordinate system to 0,0,0 and all motions from this point will be in positive space. A piece of stock is still all positive lengths. Not negative. Grbl's default origin just placed in the standard right-rear-top part of the machine. Again, the reason for this is mostly from historical reasons. The origin has always been placed in the right-rear-top corner of a milling machine. True it does make more sense if it's a CNC with moving table and the table would home to right in front of you. But most production CNC mills have moving tables, rather than a gantry. And doubly again, you can have Grbl set the origin wherever the homing cycle completes by uncommenting HOMING_FORCE_SET_ORIGIN in config.h, re-compile, and flash.
I thought the main reason for homing was so the software could determine where the hardware is. I saved your answer concerning work coordinate systems last week and I haven't had time to spend on it. I have some free time next week and plan on working on it then. I guess that GRBL was so easy to set up and get working, it wasn't necessary for me to go any further. And that's the rub. It's not true that a part is all positive lengths when making the right rear corner the origin. I use Aspire and if I set the origin to the right rear corner, all the dimensions are negative. That makes it doubly difficult to make computations because when going from left to right or bottom to top, for instance, the coordinates gets smaller, not larger. I know a part can't have a negative length, but try to tell that to Aspire. Very frustration and to me seems much more complicated than necessary, Steve Fox
In that case, allow grbl to home in the back right as it wants to and set machine position there, but set your G54 coordinates with jog+G10L20P1 (or, say, G10L2P1X-450Y-450 or whatever) to have 0,0,0 at the front left? Far as I can tell, grbl doesn't care where the machine vs work coordinates are at, as long as everything falls within your soft or hard limits. Aspire, I assume, doesn't care if your machine coordinates are offset as long as your work coordinates are telling it that it's in positive space. (Also, I assume it actually wouldn't care if you tried to cut a negative dimension, it's purely mathematical). So just use grbl to lie to Aspire?
Steve. Please understand that machine coordinates don't do much of anything in reality. It's completely arbitrary once you learn how to use work coordinates, which is how you're supposed to be using your machine with homing enabled. Also, please understand that CAM programs don't care about machine coordinates either. They almost always set a G54 work coordinate system at the start of a program and never use machine coordinates directly unless explicitly told to do so. So Aspire should work fine with Grbl once you get work coordinate systems figured out. There are ton of resources online explaining work coordinate systems and how they operate. Please take the time to do this and everything will make much more sense. I know that having machine coordinates in negative space is confusing as to why, but it's the way it is. So complaining about it won't change this. Believe me I've been trying to explain this to people for 5 years, since I first installed homing and work coordinate systems into Grbl. This is historical in nature, and Grbl follows the standard that have been set in place for decades. Again, if you find this behavior still too annoying to deal with, you can always uncomment HOMING_FORCE_SET_ORIGIN in Grbl's config.h source code, re-compile it, and flash.
BTW, this is what I get when I input "G10L2P1X-450Y-450". Nothing moves, nothing changes, just the work coordinates flick from saying I'm at 0,0,0 (eg. from homing) to what you see below. If I hit "Move to Origin", the machine moves into negative territory. (Or would, if I'd built it yet- for now, the steppers move correctly )
Le sigh. Panel is just giving me one trouble after the next. I "reinstalled" panel and it worked fine the first time, just like before. Every time it connects, I get an unhandled exception. I hit continue, that's when I see that my settings page is blank again... ************** Exception Text ************** System.Collections.Generic.KeyNotFoundException: The given key was not present in the dictionary. at System.Collections.Generic.Dictionary`2.get_Item(TKey key) at GrblPanel.GrblGui.GrblSettings.FillSettings(String data) at GrblPanel.GrblGui.showGrblStatus(String data) at GrblPanel.GrblIF.raiseAppSerialDataEvent(String data) at GrblPanel.GrblIF.VB$StateMachine_40__client_ComReadData.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.CompilerServices.AsyncMethodBuilderCore.<>c.<ThrowAsync>b__6_0(Object state)
After a great start, high expectations and a lot of time, I gave up on GRBL. Too many issues, too many things it just doesn't do, too many things it does in a non-standard way (to me anyway), lack of sufficient documentation and no real help were all nails in the coffin. I have to admit that part of the problems concerned the interface software. I tried GRBL Panel and UGS, both had issues, too. I purchased MACH3, one UC100 and one Smooth Stepper, haven't had any problems and haven't looked back. The difference is breathtaking.
This is a Grbl Panel issue. I'm not exactly sure what would cause that problem. I would post this question on the GrblPanel site.
Sorry that it didn't work out for you. There are tens of thousands of Grbl users that have been successful at using Grbl and it works for what they need. In fact, I often hear Mach3 and LinuxCNC users move over to Grbl due to the price point and being able to get the job done. There is also a very nice set of Wiki pages that walk you through everything. I'm not sure if you were aware of that. Keep in mind that Mach3 is a $175 program, rather than Grbl being free (as in beer), and requires a particular setup that typically costs a lot more money than Grbl systems. Your experience isn't that uncommon for those that are trying to DIY everything, especially if you don't have a lot of experience with DIY electronics. Next time I would opt for a more complete kit, as they already have debugged everything for you and the vendor can address your problems quickly. Like I said before, Grbl is open-source, free, and does not do any direct sales to fund the project. Your mileage can vary greatly depending on the route you go. Apparently you didn't choose one that fits your skill set.
I have two machines, one regular 3-axis that is an OX which is 24" x 40", and one a rotary OX that is 8" x 36". I had absolutely no issues with the hardware and read through the wiki many times trying to find answers to my issues. When i first connected the hardware to the electronics and loaded GRBL, to my surprise, everything worked as I thought it should and I was ecstatic.That was one of the few times in my life that a project went together with such few problems. I have run many jobs through the 3-axis and the problem is that some run perfectly and some don't. It appears to add steps sometimes and subtract them other times. It doesn't matter what speed I use, the results are similar. As an example, I made a batch of loom stands for a yarn shop. Of the 24 sides, there were six different heights, the total variations were a maximum of approximately 1/4", over 24". The width varied, too, though not as much, since they were narrow. The next was a batch of six using MACH3 and they varied in height by less than 1/16". For people making signs, this problem will never be apparent, but for someone making a batch of identical parts for an order, it can be a revenue killer. I could never find the issue, but I also couldn't afford to keep trying. When I went to MACH3, the problem disappeared. Maybe by your definition, I don't have a lot of experience with DIY electronics, I've only been working in that field for forty some odd years, but I really don't need to justify my experience to you. On my second machine, GRBL, as you know, wouldn't handle the rotary axis. Once I had to find something to run that, it only made sense to run the same software on both machines. To each his own. All I know is that I spent a lot of time, research and effort over almost a year trying to get it to work, it just wouldn't happen. Personally, I think Simen Svale Skogsrud did a great job, but tried to get too much from an UNO. In my experience, they don't work well once the memory is almost full. GRBL passed that point years ago. Of the people that are happy with it, I say "More power to them". I think a lot of them are happy because they don't know any better. I think they have problems and don't know it. Usually the owners who use their machines for profit pay for software. They, like me don't have time to troubleshoot software. Just because it's free doesn't mean it doesn't cost anything.. You have ABSOLUTELY no idea what my skillset is as I have no idea what your skillset is. I don't recall one time that you answered a question that I asked without telling me to look someplace else. It has been my experience that you are rude, arrogant and completely unresponsive to user input. Maybe GRBL isn't in my skillset, but It's not in yours, either.
Oh my bad. I accidentally posted here instead of the CBeam thread, but here would have definitely been a better place. Thank you.
Hi Steve, First off, each correspondence I've had with you has been loud, snarky, and about something that you thought didn't make any sense, which is fair. Each time, I've responded with an explaination to a common problem or a clarification that didn't seem to satisfy you. It goes both ways. A wise man once told me that if your attitude is horrible, no one will go out of their way to help you. Believe it or not, I've been the lead developer and only developer of Grbl since 2011 and Grbl v0.6. Simen has not done anything since then. In the past 6 years, I've seen a lot of issues and personally resolved hundreds of them. 99% of the time, the solution I suggest someone to try is the one experience has shown to be true. In the rare case that it isn't, I'm more than willing to help with anyone that is civil and are willing to do some work on their own. As for being unresponsive, I primarily and quickly respond to questions on the main Grbl site. I only come to the OpenBuilds site time to time and whenever I get an email notification. I do the same to 10 other sites that use or support Grbl. Since this isn't my full time job and have done this all in my free time, I can't invest a lot of time into responding to every single question at every single site. As Grbl has been getting increasingly popular, there has been less and less time to invest in user support (again in my free time) over development. I honestly can't read them all. Because of that, my responses can sometimes be brief and will often ask users to read and understand the Wiki, because they usually haven't and the answer is in there. As for keeping Grbl on the 328p Uno processor, yes. I'm fully aware that it's limited. It was clear all the way back in 2011. However, I think you've missed the point. Grbl was not intended to be a full solution for everyone. It's a project that intentionally kept things simple and to be extremely accessible for those new to CNCs since everyone has an Arduino Uno (or five). When you are severely constrained to a small space, you are forced to come up with creative solutions and will avoid writing slow, bloated software that always handicap larger projects later on. Now that real-time feed overrides have been installed in v1.1, that's the end of what I've always planned on putting in. Grbl is now finally done. The next project is moving onto ARM and processors 10-100x as fast. With Grbl being so small and efficient, early tests have shown that it's working extremely well and will scale very nicely. 4th axis, backlash comp, tool tables with cutter comp, etc are all planned and will be installed there. As far as assuming your skill set, I'm apologize, but your behavior hasn't made me think otherwise either. However, I have not seen a post from you about your step loss problem. I'm not exactly sure what would cause this. I take those types of potential bugs seriously and will help anyone to dig into it. That said, there are several companies that use Grbl, each with tens of thousands of CNC machines deployed, and have never reported a step loss problem. In fact, one regularly run jobs with several million lines of g-code (laser rasters or 3d profiling) without any issues. This leads me to believe that it's electrical/mechanical with your particular setup or your settings were too aggressive or improperly configured. From what you've said, it sounds like Mach3 still has a problem (your reported 1/16" drift), and it has not been resolved. It's more likely that Mach3's motion algorithms are slightly different enough to perform better on your particular machine. A CNC machine shouldn't have any drift at all. If you do, it's either electrical or mechanical. To prove it to yourself, you can directly measure the step pulses coming from either Grbl or Mach3 with a separate Arduino sketch to count position based on the step pulse and direction pins. This is a test I regularly do and never had position drift. Since you've shared your skill set, I'll share mine. I have a PhD in aerospace/mechanical engineering and do research and development on state-of-the-art deployable space structures at a DoD lab. I regularly design and prototype aerospace parts for my projects. This involves working very closely with our two machinists (who have 70 years combined experience between them) and making parts from all kinds of materials on several in-house large CNCs. Grbl has been designed around how our Haas CNC controllers work. I'll let you judge if I'm qualified to write and provide advise about Grbl.
Hey Sonny, Just want to say I've just completed my second GRBL controled CNC machine and had zero problems with GRBL (that i couldn't find an answer to online somewhere). For what i have into it ($15 for a real Arduino Uno) it's down right AMAZING! I really appreciate your efforts and hope you keep it up! I work in customer support (field service engineer) myself and understand what a downer it can be when all you hear and see are the problems people have. Can't wait to see the ARM software you come up with! Best Regards Gary
Hi, I'm new to GRBL. I have been running a Sherline mill using Mach 3 for the past seven years, drilling and routing printed circuit boards, which supports my hobby in electronics design. For this machine, I'm using Gecko G210 stepper drivers. Last year, after ignorantly installing Windows 10, and after Windows 10 did an upgrade that left my machine totally inoperable, I moved over to Linux Ubuntu. The replacement machine control software ended up being LinuxCNC. Linux CNC works and I though I was happy with it. This past March, I purchased an OpenBuilds 'C' frame XL router kit. It took a weekend to build. I also purchased the latest version of the GRBL based V-Pro controller. The machine control software I selected is bCNC. However, I am still using Gecko G210 drivers in step/direction configuration because the stepper motors I'm using require more current that the V-Pro can safely deliver. I suppose having 20 years experience fixing all kinds of industrial CNC machines such as G&L, Mach Merryweather, Pratt & Whitney, Kerny & Trecker, Gidding & Lewis, etc., much of the confusion and problems discussed here were resolved for me years ago. For anyone who has done their due diligence at researching GRBL and bCNC, it should blatantly obvious that these creations were never intended to produce an industrial or commercial grade machine. To think otherwise would be a huge misconception. The research I've done on both GRBL and bCNC, clearly indicates the fact that neither were ever meant to be on-par with industrial or commercial based CNC machines or controls. In other words... ---> CLEARLY <--- the authors of both of these works have stated from the beginning that the hope and goal was to produce something that was minimal and aimed at the hobbyist sector. So, as I ma a very happy camper, I am making plans to purchase another GRBL based V-Pro and move the Sherline mill over to the same bCNC/V-Pro configuration that is on the OpenBuilds 'C' frame XL router. Oh! I am excited to hear about an ARM based GRBL controller. Mark me down for two!!!
Please help ! How to modify the GRBL 1.1 firmware so that the "home" X, Y, Z terminals were connected in parallel to PIN D9, and the machine coordinates 0,0,0 were in the positive quadrant of the Cartesian system?
Alter the cpu_map.h file to place the axis limit switch onto pin 9, update config.h to run each axis in a separate homing cycle, and enable the HOMING_FORCE_ORIGIN option in config.h and place your limit switches in the negative side of each axis.
"Sonny Jeon" thank you very much for the reply! My switches are on axes: + X_HOME; + Y_HOME; | + Z_HOME. My CNC milling machine is controlled by Mach3. I'm doing a Mach3 / GRBL Spin Controller with PWM PIN11 laser . Please check if I made modifications to the file "cpu_map.h_?" I can not change the Config.h, I can not find the "HOMING_FORCE_ORIGIN" command to activate it ... nor how to put the switches in the + X axes; + Y, + Z. : ((
Today I found and commented on "HOMING_FORCE_ORIGIN" Very please if it is possible to check modified files and correct them. Please be very understanding (I am 61 years old and not very familiar with coding in Arduino IDE), thank you for kindness and sorry for my english, I use transate.google ....
