I recently implemented a Z-zero plate on my SO2 CNC. I'm using the Macro page in UGS to hold the commands. My first macro is G20 G38.2 Z-0.5 F2; G92 Z0.5. For simplicity, I'd like to add another command to raise Z another .25" while leaving the reference point at 0.5", the thickness of my plate. So far, whatever I do causes an error, unless I unplug the Z-zero plate. Ideally, I'd like to add to the one macro; i.e., G20 G38.2 Z-.5 F2; G92 Z0.5; ______ Z0.75. Is this possible?
Do a G91 (relative distance mode) and then G0 z0.25. That will retract an additional .25". Finish off with a G90 to put back in absolute mode.
John, thank you for your help. Using the commands you mentioned works like I want. My macro now reads G20 G38.2 Z-.5 F2; G92 Z.5; G91; G0 Z0.25; G90. That's so much easier than hand-cranking to a piece of paper! Thanks again!
You should also take a look at bCNC and cnc.js. They both have built in probing support and are pretty feature rich. I run both on Raspberry Pi 2 with no performance issues.
I've seen posts about bCNC on other forums. I'll take a look at both. UGS has been working fine for me so far but I've heard of some people having issues with it.
Hey Sonny, will there be anything for manual tool changes? Like, run a part of the code, go to home, and pause. User changes the bit, re-does a Z set with a plate or manually, then it resumes the operation?
bCNC is the only GUI with manual tool change that I know of at the moment. Grbl provides all of the tools to support tool changes, but doesn't incorporate the process into itself. There lots of reasons for this, but I won't get into explaining why it's this way. Other than saying that machines are all different and there are a number of unique ways of doing a tool change. It's better to give GUIs the interface to do this, than to have Grbl manage every scenario. At some point though, I do need to write up a recommended methodology for GUI writers on how to properly do this. This should help get GUIs supporting it quicker.
Ok cool. Very nice to see it IS a part of it though, since my friend is complaining how it isn't and he basically has 3 different g code files, one for each tool and has to run them back to back in UGS.
I added tool change support to SketchUcam a couple of releases ago. This adds a tool change (standard T1 M6 type or a custom macro you write) to the start of every file. You can then use the Gcode joiner function to join the files together to run as one. Both methods allows you to add a tool offset, so if you know how long your tools are you need only measure them once and can simple supply the tool offset when changing tools. This does require that initial Z zero be set with the correct 'baseline' tool, or a standard spacer that is longer than all your tools. Example macro: you need to set the G59 0,0,0 co-ordinate system to where you want to change tools. Code: M5 G49 ; turn offset off G59 ; go to coordinate system G59, where you have already set 0,0,0 to be your tool change position G0 X0 Y0 Z0 ; go there M0 ; pause G43.1 Z%s ; set offset, notice the %s, the offset number will be inserted there G54 ; back to regular co-ordinates Note that using a macro like this cannot make use of a tool height sensor since we don't have a way to get the length back from GRBL. But bCNC can do that.
Having a heck of a time trying to get my machine properly homing. Is there somewhere on these forums where we can get a list of typical grbl values for the ox cnc? (to play nice with the nema stepper motors and the pulley and belt that openbuilds uses for these guys?)
The first thing to do is make sure your machine coordinate system is correct. X+ moves in X+ and Y+ moves in Y+. Alter the direction invert settings if they aren't. Then use the homing direction invert setting only to tell Grbl which direction your limit switch is. If you are having problems related to failed homing, it's most likely noise in your limit switch lines, falsely triggering the pin. In this case, add shielding, move your cables away from noise sources, and wire in a low-pass filter with a small capacitor across the limit switch pin and ground.
Hey Sonny Is it possible to do a homing cycle or something to find 0,0 of only X/Y and set Z manually, either by paper or a probe? My Z has 6" of travel but only 2" to the bed so I'd rather not have it crash every time I need to use my machine lol. I'll be using limit switches if that matters at all. My friend suggested running Pin 12 straight to ground to short it out for the homing cycle because Im setting it after the fact. Can I just copy the Z probe macro but use it for x/y with the limit switches or is there no circuit to complete? Cheers!
it is normal to home Z in the UP direction, so it never goes near the part or table during the homing cycle, it goes UP. so put that limit switch at the top of the travel and let it home there.
I have installed everything but my mk2/4 does not connect. Wen i connect the usb and wait nothing shows up in the grbl panel com box, when I rescan still nothing.Can you help? I am a newbie. Thanks
Planet CNC mk2/4 does not run grbl, so you can't use grbl-panel. You will need to use the Planet CNC USB controller.
Yes! (Sort of) You can have Grbl only home two axes for 2-axis machines. In your case, just the x and y axes. To do this, you'll need to alter the homing cycle defines in config.h. There are comments to tell you how to do it. It'll leave the z-axis undefined as the current value. Meaning it won't change it. As far as the 'sort of', Grbl doesn't allow the user to specify a machine coordinate. It's only done by the homing cycle. This is intentional to prevent users from messing with the machine coordinate system, because it can also mess up work coordinates badly. Since you are using a 3-axis machine and homing only 2-axes, this kinda breaks the intent of how the machine coordinates are supposed to work. To get around this, you could try remembering to zero the z-axis manually with work coordinates, but this would get tedious and is a high risk for a crash at some point. I would recommend to setup your machine to home all three axes. This will be easiest and best thing to do.
Hi Sonny, I'm having a strange problem with getting my Y-Axis working properly using GRBL. The Y-Direction pin is always high, so the Y-Axis only moves in one direction, despite trying to move it both directions. I metered the arduino and the stepper drover board. With the arduino connected I always see 5v on the direction input of the stepper controller, and it drops to zero when disconnected, while the arduino pin is always at 5v. I have tried inverting the Y-Axis direction but the problem still persists. Any help would be greatly appreciated. Jake P.
Do you have another board that you could hook up to see if it does the same thing? Sounds like a bad output.
I have another board, but the serial connection is not very reliable on it. the one I'm currently using is brand new. I will try flashing my backup board tonight, and checking the state of the Y-Direction pin.
If you have any experience with Arduinos and you want to find out if it is the board, you can hook an LED and a current limiting resistor between the pin and ground and write a short program through the Arduino interface to turn it off and on. If you have programmed an Arduino before, it takes a couple of minutes to do. If you don't have the experience, it probably isn't worth the trouble to learn.
I tested my board with the basic blink example supplied in the arduino ide. I modified it to use pin 6. With my DMM attached I could see the pin going back forth from high to low. Afterwards I flashed GRBL back onto the board and the Y-Axis is still only moving in one direction. One odd thing to note: The first attempt to move the Y-Axis it began moving in the opposite direction first, for about 1/2 second before it reversed itself and was stuck moving in only one direction.
Good work. I agree with David. Next thing to try would be to change the X and Y driver boards to see if the other one does the same thing. One question that doesn't have anything to do with your current issue. Did you flash the Arduino board with the Arduino interface or did you load one of the compiled versions? I'm guessing that you used the Arduino interface, which is a good thing. It gives you more options.
From my previous tests, when i disconnected the y direction pin from the driver board, the corresponding pin on the driver board went low. this leads me to think that the problem is elsewhere. Tonight I'll do some more troubleshooting focused on the driver board itself. Ill try controlling the direction pin manually with some extra bits of wire on my breadboard. But even with the arduino y direction pin dissconnected from the driver board I was still seeing arduino pin stick in a high state. In regards to what David said, physically the arduino seems to be working fine, but when I load GRBL on it, that one pin seems to get stuck in a high state. If toggling the direction pin manually works as expected, I'll then try to swap the driver boards and see what happens. Thanks for all the advice and feedback. Jake P.
I haven't done any Arduino programming in six months or so, but I believe there is a setting to enable a pull-up resistor on each pin. I can't remember if the GRBL software has that enabled or not. I do know there are a lot of variables in several files in the GRBL library. I would look it up, but I installed Windows 10 and for some reason, it won't let me choose the program I use to view the .h files.
Sorry about the late reply. Your problem is indeed unusual. Can you describe your wiring scheme, commands you are sending to Grbl, and your Grbl settings? This occasionally helps diagnose if it's a problem with Grbl or something external.
