Don't forget that the EEPROM can only be written to so many times before it will eventually falter. I forget what the number of times is. It is quite large... Just to say you don't want to change those stored values without a good reason nor knowing it will eventually go gaga on you.
EEPROM can be rewritten 10,000 times, according to the AVR spec sheet. Realistically, users will never exceed this.
True. Changing once a day gives you a good 27 years, plenty as one is not likely to change one of these settings every day. However, building the change into a G-code file for a piece means it will be written over every time the job runs. Have a job for, say, a popular small badge. Run it the equivalent of 27 times a day and you are down to ~1 year. That's a lot of badges, mind you, but a year goes by real quick these days. Just to say don't code these changes inside G-code files you will be running often. These settings are not meant to be continuously changed. Once the machine is tweaked, the settings shouldn't have to change ... ever. Update the machine, update the parameters. Mirroring a pattern is likely best done at the source rather than by changing EEPROM stored parameters meant to be 'permanent'. That's what I was getting at.
My mistake: EEPROM can be re-written 100,000, not 10,000. The 10k is the flash memory rewrite cycles. So, for your example, re-writing 27 times/day would take 10 years to wear the EEPROM out. That said, I agree it's not a good idea to directly alter the EEPROM during a job, especially on a consistent basis. It's always better to preprocess the g-code before having Grbl execute it. But, along with the fact that AVR processors are supremely cheap to replace, it's not as bad of a problem as one may think.
They are not always in sockets to do easy swaps of the those ICs. Also, there seems to be a G code to mirror about any plane/center point (!?) : G50.1 and G15.1. Just need to be able to process those commands. Some machines have their own G code to achieve this as the HAAS uses G100/G101. Still, best to do the transform at a design stage - the source. There is also the G68 and G69 for axis rotation ... Not sure if GRBL can process any of those. Anyways, I had bumped into a G-code post processor which allows scalling, rotation, mirroring and other transforms. It would take a G-code file, process it according to some parameters to split, scale or whatnot into one or more resulting G code files. I didn't try it... I just have to dig in my ever growing list of links to find it again. I need to catalog those things ... I'll find it, just give me a bit of time.
Yes. If it's an integrated motion control board, replacing the AVR would be non-trivial. If you are using a shield arrangement, or made your own, it would be easy to replace. The mirroring and rotation g-codes are easy to implement and will be in the ARM version of Grbl. They are not in the AVR version due to available flash restrictions and possible computational limits. The AVR is pretty close to maxed out and adding any new (expensive) floating point calculations it has to do will likely hurt performance.
About Feed Hold: I have a 2 axis laser. I am trying to add buttons for hold and resume. My problem is that HOLD appears to stop stepper motion, but does not stop the spindle. That may make sense for a mill or router. The laser needs to be turned off when HOLD is hit and then set back to the previous on OR off state when RESUME is hit. I have been looking through the code to point to a specific modification, but I have not yet been able to follow where the spindle_stop() should be inserted. After getting it to stop, I will need to set it back to the previous state on RESUME. Any advice? Can this upgrade be made easily?
Hi, chances are that underneath the Arduino Nano Chip on your controller (I am assuming you have an EleksMaker 2 Axis controller), there may be a jumper that lets you select .08 or .09 GRBL compatibility. Carefully remove the Nano and change the jumper. Then you can use .09. If you do have the jumper, I will be happy to send you a .hex made for your controller. If you do have the jumper, this will also allow you to use PWM power control for the laser. The controller you have does not have limit switch connections. I have designed a small daughter card for the controller (again, assuming you have the one I think you do) that adds 2 limit switches and 3 buttons (pause, resume, and reset. The board is not completely ready now, but will be soon. If you are interested, let me know. I have 2 chinese solid state machines and have (with much work) upgraded them to reliable machines - they are a pain to get working in the first place though. I am happy to help you with yours if you like. Bob
I just saw Sonny's comment on the Git Hub about how to handle Hold as a Safety door pin. Thanks so much.
Here it is : G-code Ripper from www.scorchworks.com. It reads, scales, rotates, splits and wraps G-code. The last two were what I was most interested in at the time.
Sonny, thank you for your time and willingness to share on this forum. It is appreciated. I have a problem that I hope you can provide some insight on. I have had occasional problems with what looks like an origin shift during the execution of a job. To troubleshoot, I created a set of lines that would help me locate where the shift was occurring. I narrowed things done to at least one line that consistently causes problems, in the gcode below: G90 G20 G49 G17 M3 S15000 G00 Z0.1250 X0.5000 Y0.5000 G00 Z0.0200 G01 Z-0.0450 F10 X3.2500 F15 X0.5000 Y0.7500 X1.7500 X0.5000 Y1.0000 (<<<This line fails) X1.2500 X0.5000 Y1.2500 X1.0000 G00 Z0.1250 G00 X0 Y0 (home) M05 M30 Instead of moving smoothly from X=1.75, Y=0.75 to X=0.50, Y=1.00, the Y drive "stutters" during the -X motion, and the tool winds up at about Y=0.77. The rest of the lines execute normally, except they are now offset in the Y direction by -0.23 (=1.00 - 0.77). When the tool returns to home at the end of the program, it is at X=0.00, Y = -0.23. If the lines in the program are repeated, as in multiple passes at different depths, the error accumulates by the same amount each pass. That is to say, after three passes the error is 0.69. This failure is consistent over multiple runs of the code, and when using UGS and my "home brew" version of a GUI. Any insight you have will be greatly appreciated. Thank you, Gary
This is most likely a problem with your stepper acceleration and junction deviation '$' settings. These two parameters gauge how Grbl plans the motion path to prevent steppers from losing steps, which is that stuttering sound you have. First check your junction deviation value. It should be around 0.01-0.02mm for most CNC applications. Check your stepper acceleration settings. You may need to lower them or increase the current to your steppers on your stepper drivers (make sure you don't exceed your motor rated current though).
Wow, thanks for the quick response! You sent me on a path that lead to at least a workaround. I tested the effect of changes to the junction deviation and the stepper acceleration, but even significant changes to these had no effect on the problem. That made me wonder why the acceleration setting seemed not to matter in this case, and that lead me to looking at the feed rates. My stepper/driver combination seems to run pretty well at 650 mm/min, or about 25 inch/minute (F25). So it seemed to me that a feed rate of F15 should be OK (see line 7 in the snippet above). However, when I changed this to F10 or F20, things suddenly worked fine, and as expected. Setting the feed rate back to F15 caused the problem to reappear. ?!?!? I guess there are little areas in the X + Y feed rate space that just don't want to work for me (frowny face). Any idea why a line at a particular angle should be sensitive to the feed rate even when not using aggressive acceleration and step rate values? Later today I plan to abuse my CNC with a bunch of radial lines to see if I find any more of this kind of weirdness. Thanks again, Gary
Well, I have spent a lot more time on this than I want to admit to. The fundamental problem is that I cannot reliably route along a line that is at a small angle (about 10 degrees) to the X axis. Less that about 5 degrees is ok. More than 15 degrees is OK. These are approximations - I have not tried to find the exact angles, yet. There does not seem to be a problem with lines that are close to the Y axis. As a side effect of this problem, I can't reliable route a circle, since some of the segments can fall in the problem area, angle wise. When I try to route a circle the top and bottom is not round, but rather has a roughness to it that the sides don't have. By the way, I am not really routing during these test, but rather drawing on paper with a special made pen that is mounted in the spindle. I am 100% sure that this is not part of the problem. Also, it is not due to loose set screws, or other loose hardware. Things I have tried are: Three different GUI/front ends, Replaced the Arduino Uno R3 - both were real Arduinos Replaced the motor driver board and drivers - and verified the current settings Settings I have varied single and in combination: Junction deviation, from 0.001 to 1.000 in many increments - 0.015 seems best Acceleration, over a wide range - faster seems better to a point Max rate - over a wide range. Feed Rate, from 10 inches per second to 25. My test drawing starts as a set of radial lines between two circles, think wagon wheel. I have tried other simpler test drawings that include just the basics required to see working lines and failing lines. It seems that one combination of settings will work better for one angle, but a different set works better for a slightly different angle. "Better" is a relative term - I have not found a set of settings that works in all cases. My setup is dual lead screws for X, single lead screws for Y and Z. When the problem is happening (trying to draw a small angle line) I can see the Y axis lead screw jitter back and forth clockwise to counter-clockwise rather than turning smoothly like it does at other angles. This jitter is audible when you are used to how the machine sounds. I is also audible drawing a circle when the top and bottom segments are being drawn (the low angle areas). The problem happens along the length of the problem line, not just at the start. It can happen with a very short line, or with a line several inches long. The line drawn looks rough, and kind of wavy, and more horizontal than it should. When the problem happens, there is a lose of Y positioning, and this lose is cummulative. The problem only affects the Y axis positioning. The X axis always works out right. Before I ran across GRBL and all the products that support it (software like all the G-Code senders, and the Arduino/GRBL conpatible hardware) I wrote a set of algorithms that drew lines that ran on the Arduino, and also wrote a PC based GUI that interpreded G-Code into the "moves and draw" commands needed by the Arduino. My version was no where near as sofisticated as GRBL, but I did notice that there was a possibility of a sort of "resonance" between stepping in both the X and Y directions. Could there be something like that going on? Surely anything like that would have been seen before. There have probably been millions of low angle lines drawn with GRBL. I'm looking for any kind of answer. I'm running out of ideas. Anyway, If you have any suggestions of things I can try, I would really, really, like to hear them? Thanks, Gary
Gary: You're probably running into a resonance problem that is coupled with your CNC structure and stepper motors, which can happen if your CNC isn't as stiff as it should be. Or your stepper motors themselves are resonating, where the rotors can actually vibrate inside the housing. Resonance can make steppers lose steps or behave weird if its bad enough. Typically the solution is to increase the micro steps from something like 1/4th to 1/8th for example. Usually this will move the input disturbance away from the natural frequency that is causing the lost steps. Another is to increase motor driver voltage/amperage to close to the maximums. Or stiffening up your CNC, if its a structural issue. But, my guess is the y-steppers not being setup optimally. This a common issue for a gantry-style CNC with the Y axis oriented along two rails.
I agree that there could be problems with rigidity/resonance and so on, but I think that the fact that the problem is with low angle lines, where the Y axis is moving pretty slow, rules it out in this case. I will look at it more tomorrow, though. I forgot to mention that the lead screws I am (currently) using are 1/4-20 threaded rod. So, 20 turns of the stepper per inch of travel. I also am not using micro-stepping (no need, since the base resolution of the system is 0.00025 inch). Also, I am driving the motors at their rated current of 1.0 amp, from a 24V supply, and using the 8825 driver modules. The thing that really puzzles me in the way only the Y axis screw rotation jitters back and forth clockwise to counter-clockwise. Sometimes the problem is so bad that the Y axis jumps pretty quickly about 2-4 mm. That jump becomes part of the cumulative error for Y, as does the jitter. As for the jitter, if the desired direction requires clockwise rotation for Y, any jitter in the counter-clockwise direction becomes an error. Each jitter accumulates to the total Y error. Also, this jitter has every characteristic of being driven electrically, as in by the stepper drivers. I'm beginning to worry that I am just not smart enough for this hobby, hehe. Being an electrical engineer for 30 years was not preparation enough it seems. Once again, I appreciate your help. Thank you. Gary
When you move at a very low angle, the steppers have to pulse is in very non-uniform way. Grbl's stepper algorithm is based on a Bresenham line algorithm. Much like lines that are drawn at a very low angle, the steps on one of the axes becomes not very smooth. Grbl helps reduce it with its AMASS algorithm in v0.9, but it doesn't get rid of it completely. Again, with a step pulse that is odd, produced by low angles, can cause resonance problems.
Also, if Grbl is reporting the correct position, then it's doing its job, as position is directly tracked by the number of step pulses it generates. If you say it's electrical, I'd really look into analyzing the signals from Grbl onward. You can rule out mechanical causes if you remove the steppers from the machine and it behaves exactly the same.
ah, so the motors are full stepping! this is the worst possible setting for resonance. change to 2x (half stepping) or 4x for much better low speed resonance control. you will have to reset the GRBL mm/step to compensate for this change. This is typical low speed resonance
Is there any way I can buy you two dinner? I'd suggest Bar-B-Que in Austin, Texas, but that might not be real convenient for either of you. In any case you both have my respect and admiration. I did the 4X thing, did the settings thing, and all of a sudden the thing worked! Nice! Once again, I have to ask myself why ignorance is so hard to overcome, and why stupidity comes to me so naturally. Fortunately for me, it's the journey I am more interested in. The destination - not so important. I'm using my current CNC incarnation to make parts for the next one - how common is that? Thanks again - I will sleep better tonight. Gary
I'm building a Mostly Printed CNC machine, and it is going well. I have motion including homing working. Waiting on a router to arrive before doing any actual cutting tests. Using GRBL v 0.9 I have hard limit switches installed on X, Y and Z and they are all working well with homing and to trip when the hitting them. And I have soft limits set as well. That is if I turn off soft limits then the limit switches do exactly what they should. Even though the MPCNC tolerates banging into the frame I think it is better to NOT let it do that, hence the limit switches I'm currently using bCNC for my initial testing. I have a couple of questions: 1 - When I power up most of the time GRBL is reporting an alarm. I was thinking that this might be due to the capacitor(s) I added to deal with any noise causing false triggering. And that might still be a problem, but thought I would ask. The biggest annoyance with this is that bCNC will not "connect" until I can do $X but of course bCNC won't let me issue the $X command since it doesn't think it is connected. Of course this is mostly a bCNC issue. What I do to get around this is open up minicom and connect to GRBL and issue the $X command then close out of minicom and open the connection in bCNC and life is good. Has anyone else seen this kind of issue, and how did you resolve it? 2 - When testing the hard limits I find that when trying to reverse direction away from the limit (after clearing the alarm of course) that I get a secondary alarm when the micro switch opens. Note also that some times I cannot move away from the hard limit as I keep getting the alarm each time I try to move (again resetting the alarm before each move). I suspect that this is due to contact bounce in the micro switch. There is a setting for homing debounce, but I don't see a corresponding one for hard limit debounce. Any suggestions how how to resolve the issue (other than adding some more sophisticated HW debounce for the limit switches? Thanks, Burt
Is it possible to have the option to leave single axes powered? Like for a z-axis leadscrew, it probably needs to stay powered in order to stop the head from jogging the screw. But for x/y, at least on a laser cutter (probably on a 3D printer too?) it doesn't seem that important to maintain power across the plane, since nothing is torquing or precessing or whatever those axes around. Using bCNC for initial testing, if that's relevant.
1 - Grbl automatically alarms upon power-up, if you have homing enabled. This is because Grbl does not know or guarantee its position. (This is the same for all open-loop stepper-based controllers.) You have to re-home to set and find zero. If you always have a consistent, repeatable reference point that homing provides, this allows you to much more with your CNC machine. This alarm issue isn't a problem, but rather than a feature. If you still find it annoying, then you can disable the alarm by commenting an option in config.h called HOMING_INIT_LOCK to remove it. 2 - This is a very common and annoying issue with Grbl, but does not have a good alternative solution. Grbl has to read a hard limit pin in the most reliable manner to make sure it ALWAYS triggers an alarm. A software debouncing routine can sometimes not guarantee this (<0.1% chance, but not one I'm willing to risk). If you run into a hard limit and the switch bounces, yes, it'll re-trigger the hard limits. You'll have to go through a process of moving and unlocking or disabling the hard limits in '$' settings temporarily to move off them. However, the idea of hard limits is not to run into them often.
No, not at the moment. But for the most part, modern stepper drivers are very efficient in not producing a lot of excess heat. It's generally safe to leave the stepper drivers powered for a long period of time.
Thanks Sonny.. I didn't think that the alarm on power up is a problem at all with GRBL. I'm using bCNC right now for testing and for some reason bCNC opens the comm port OK but reports that it is not connected to GRBL and doesn't appear to let me issue the $X command to unlock. As a work around when this happens I close the port in bCNC and connect to GRBL with Minicom, then at the GRBL prompt I can issue $X close Minicom and open the port again in bCNC at which point bCNC happily reports that it is now connected and life is good. I've asked the bCNC developer about what I'm seeing but he indicated that bCNC should let me issue the $X command as long as the port opens, but that's not what I'm seeing so I'll have to add some debug code to bCNC to determine exactly what's happening there. I figured that there probably isn't much to do about the switch bounce, other than maybe move to optical sensors and add some plates to the gantry to trigger them, but that adds more complexity than it is worth. Like you say the idea is to avoid hitting the hard stops, and it's really only an annoyance if I have soft limits turned off. I was just wondering if there as any alternative to easily clean up the bounce issue. Thanks again, and I'm enjoyingi GRBL. It does a very good job and is getting better. The improvements from 0.8 to 0.9 really made a big difference in how smoothly things operate. I have one thing with soft limits that I'm working through. X and Y appear to work as expected and the soft limits are great because the keep from hitting the hard limits as they should. But I've had some issues with the Z axis soft limit where it appeared to trip when I didn't expect it to. But it is likely something that I didn't have set up quite right so I need to do some more testing. If I still have a problem I'll gather more information and make a fresh post with the details.
@Sonny Jeon hello , i need help please! can i control one axis using GRBL ?? i am using arduino uno and L297, L298 .........thanks
Hi Sonny, I have a question about the soft limits in v 0.9. Part of this may just be that I'm pretty new to CNC so I'm trying to work though all the variables involved. When I do $H to home the gantry on my MPCNC moves to the lower left corner and initially WPos as reported by bCNC was 0,0 (XY). With that configuration all my moves onto the work space had to be negative numbers. And anything that I generated for testing in bCNC was showing off the workspace. But in that configuration with soft limits enabled the soft stops worked as expected and are great. But to resolve what I was seeing with requiring negative moves to stay within the workspace I moved the gantry to my max position on the workspace of -300, -300. Then I set WPos XY to 0,0 in that position. Then all all my moves were OK except for one thing. Almost immediately I get a soft stop alarm. So to move or run GCode I had to turn off soft limits. It's probably something that I'm doing wrong with the configuration somewhere but I thought I'd ask to see if that is how the soft limits are supposed to work if you change the WPos. I'm hoping that is just my early lack of knowledge with CNC Thanks, Burt
