Thanks for the help so far David! I am guessing you mean this? Now what about the homing in the PP options? Leave them defaults or how do I set them?
One does not home at the beginning and end of a job. One homes when the machine is turned on, or after a crash. after that you set the Work Coordinate to your reference on your raw material. Then run the job. You should rather 'go home' after the job. there are several ways to do this but I like these 2 lines G53 G0 Z0 ; raise Z up for safety G53 G0 X0 Y0 ; return to home but this assumes that going to 0 will not hit a home switch and cause a limit error. That is what the -10s are for, to stop short of the switches to avoid errors. OR in my postprocessor set the gotoMCSatend to true NOTE this does assume that the preceding code raises Z to a safe height. what is a safe height? high enough that the end of the endmill will miss all the clamps/work between where it finishes cutting and the MCS home position. Usually this means all the way to the top of travel, ie G53 G0 Z0. so in fact my code should have an extra line.... Code: { // go to MCS home writeBlock(gAbsIncModal.format(90), gFormat.format(53), gMotionModal.format(0), "Z" + xyzFormat.format(0)); writeBlock(gAbsIncModal.format(90), gFormat.format(53), gMotionModal.format(0), "X" + xyzFormat.format(properties.machineHomeX), "Y" + xyzFormat.format(properties.machineHomeY)); // Return to home position }
No need to shout! I don't think there is a version that will run on a Leonardo. There was some discussion on it on Github a few years ago, but that was back at version 0.8 or 0.9. I couldn't find any downloadable code for Leonardo. Sorry. MG
For most parameters there is either a 0 or a 1 to disable or enable the function. For some such as directions there is a mask value which is again range bound. Apart from this most other values would be specific to your machine and hence range bound by that.
Except for the first two the rest are defined by the mechanical capabilities of your machine and the motors you’ve used. Take a look at config.h and default.h in the grbl folder. That should provide additional information. However I’m sure the software limits are far more than what a mechanical system is capable of.
one i know is the minimum feed speed. this is about 50mm/min due to math in the AMASS module. but, that is not a config setting. I believe most of those things will be documented in the code itself so read that first (-:
The Grbl wiki pages explains these values clearly. You don't have to mess with junction deviation or arc tolerance until you have a special application. Grbl doesn't provide feedback for value or settings limits because there isn't room to install them. There is literally a few dozen bytes of flash left in certain critical build configurations.
I don't think it will accept an illegal value. For instance, with steps/mm, and all of the other decimal values, it will only accept up to 999.999, you can't physically enter a larger number. The variables are assigned a binary memory space, if it's 8 bit you can go to 255, if its 16 bit you can go to 65,535, etc. I don't know why you are obsessing on these limits, your machine will cease to function long before you get there for most of the variables. The limitations are not in the software, but in the mechanical response of the machine. If you send it a value that is outside the machines capabilities, it will stop working. You are not going to break anything. MG
Hi! I've recently finished to make a mini CNC mill for PCB routing with GRBL 1.1f firmware version. Last week, I've installed an aluminium block on it for automated Z zero tool lenght. The block has two wire, one corresponding to the aluminium block (A5 probe pin in Arduino) and the other end, to GND in Arduino and motor chasis. I've tested continuity between the tool and motor chasis and all is ok! I tested the probe and all works well. The problem comes when I send M3 command to activate the 12V DC motor spindle throught the rele. All 3 steppers begin to rotate, with any signal sended by me. If I disconnect the GND wire on the motor chasis, all works fine. My question is? Must I disconnect every time I use the probe the GND wire attached to motor chasis? Is a way to leave the wire attached to DC motor chasis without these steppers movements? Must I connect something between A5 and GND on Arduino?? I hope you can help me with this. Thanks in advance!!
NEVER connect DC ground from your Arduino to the chassis or motor power supply grounds! The arduino is isolated from the motor supply by optocouplers in the stepper drivers. If you connect chassis ground to either motor power supply ground or arduino ground you are just asking for trouble. Chassis ( all moving parts thereof) must be connected together and grounded to the ground wire on the AC line cord. DO NOT connect power supply DC ground or Arduino ground to the chassis ground. The probe input ground should only connect to the bit on the router during a probe cycle, do not rely on chassis ground for this connection. Use an alligator clip for a temporary connection. The probe pad should be connected to the A5 input on the Arduino. MG
Thanks for your reply. I've maked two CNC machines, one big with PC+BOB+Mach3 and another one with Arduino+GRBL. In both machines, all the GNDs are shared by the same wire and works very well. That's the first time I read about isolate AC and low voltage ground. The problem is that my probe has a specific wire to attach motor chassis, and the manufacturer talks about connecting it the way that I do. Mach3, Auto Tool Zero Sensor, Connection Checker, Cnc Tool Change, Measurement. | eBay I think the wrong thing that I do is to use not shielded twisted wire to spindle
Hi Guys! I have had my sphinx router for a while now, It is set up with BCNC and a Phoenix cnc controller (Arduino). All along I have had an issue of the connection just randomly dropping out mid program, never in the same place, just randomly. I have found that turning off my wifi and all other programs on my computer helps sometimes, but not all the time. I have tried multiple computers, and using UGS instead of BCNC, and it still does the same thing. I have added 8 ferrite chokes on all the hot spots, which I thought helped, but now its back to not working. All I can do to get my connection back is to disconnect and reconnect, otherwise I can stop the program, but not get any movement out of the machine. Please, any advice would help, I am thinking my next option would be to order another control board and see if that fixes it. Thanks, Sam.
Can you reflash the firmware on the control board? This used to happen on my 3D printer (not running grbl but an Arduino nonetheless) and reflashing the firmware solved all the glitches. Make sure to note down your existing settings before you do this and wipe the EEPROM on your Arduino before reflashing. Without the EEPROM wipe you will retain all existing settings (and possibly any glitches as well).
look closely at the board and figure out what the USB to serial chip is. it should be a atmega16u2. if it is then the glitches can be fixed. if it is a CH340 then the glitches cannot be fixed. why? the actual Arduino Uno uses a 16u2 and that can be reprogrammed to fix the old glitches. newer Arduino's already have the fixes. the CH340 chip simply cannot handle the load and randomly disconnects. there is no available code with which to upgrade it. the cheap copy Uno's use this chip because it is cheaper. I have several of these boards and they even die sometimes during programming! someone else suggested reflashing GRBL itself. I agree, grab the latest code from github and flash it. one simply cannot debug an old version.
Funny, I've been using the Chinese Nano's with the CH340 for a while now and have not had any reported issues. I did have one guy that said his steps/mm value in the arduino kept resetting to the default 250, but seems unrelated. MG
I think I have found the problem, I had a cheap chinese water pump for cooling my spindle that came with it. Turns out if I unplug it, I only get a drop out every few hours, but I think thats to do with BCNC. Thanks guys!
The CH340 issue will only crop up when you are streaming very heavily, near the bandwidth limit of Grbl. The buffers are poorly managed and will lose data in this condition. Typical g-code jobs will not get near this limit, but in certain cases like complex curves with very short line lengths and at high feed rates will. However, this discovery was tested a couple of years ago, and the CH340 firmware may have been updated in newer versions.
I recommend using a good power filter to plug your computer and machine into, and plugging the router/spindle into a completely different circuit if possible. I use these. Plug anything that is not directly related to the electronics, like pumps, router, etc in somewhere else. I also usually put a couple of those ferrite "lumps" on the power cord and USB cable, or buy the USB cable with the ferrite already on it. MG
Problems like this one are usually related to buffer underruns somewhere in the stream or EMI issues causing data corruption. First, if you are using the character counting protocol, try reducing the expected size of the buffer size to 127, rather than 128. The one missing byte is due to the ring buffer (but it is 128 bytes in v1.1).
Hi. I am very new to CNC but an old hand at 3D Printing. I now have a C-Beam with Arduino DUO, Protoneer 3.51 CNC Shield, GRBL 1.1, and am using TB6600 as my Stepper Drivers. I have installed the limit switches and verified that the are electrically correct, and have plugged them in - ensuring I am using the new Z+ pin arrangement. Now my issue is - How does GRBL use the limit switches. From previous experience with 3D when the limit switch is activated then it will stop the axis movement but so far I cannot seem to do that. Can somebody explain how the G-Code/GRBL/Limit switch interaction works or are the limit switches just here for decoration. Many thanks Dave
Hard limits are disabled by default. Make sure you filter for electrical noise with a small capacitor. Otherwise, you will get a lot of false limit triggers.
Usually but EMI can be hard to diagnose. Often it’s coupled with certain motion or a spindle turning on, which is timed with your streaming or timed with the action. This could also be related to some of your setting. For the example, you are exceeding the 30kHz max step rate. Other than that, Grbl definitely shouldn’t be giving you weird responses. It’s been stable for quite some time and your particular issue hasn’t come up anytime recently. The only other things I would say is to possibly reflash Grbl, try a different Arduino, and remove all other variables/electronics and do a simple bench test with Grbl directly and add things one at a time to determine the culprit.
Not sure what else to tell you since you seem to be fine doing things on your own. Going over 30kHz will make Grbl unstable and behave unpredictably but you already knew that.
Hi Dave In the GRBL settings, you have to enable Hard Limits, $21=1. You may also have to use the Invert Limits $5 if your switches are normally closed. Also, you can enable homing using $22=1, and change the direction of homing with $23. Note that GRBL does not differentiate between left and right homing switches (or up/down, front/back) so you have to set the initial direction of the movement and thus the switch used. As Sonny said, a .1uF cap from each limit input to ground is a must, but I have found that limits are extremely prone to noise with an Arduino and may cause false triggers, halting your programs randomly. You may have to add an additional pullup resistor of 2-5K as well, since the inputs on the Arduino only rely on its internal weak pullup which is about 50K. This makes it extremely prone to noise. I really gave up on using limits with Arduino because it false triggers when the wind blows. Homing seems to work fine, since GRBL only pays attention to the switches when a homing cycle is actually happening, the rest of the time it ignores them. MG
