Hello guys. I'm hoping that you can help a newb out with another question/issue that I am having with my new machine. I have been working with mach3 for a while now and seem to have a handle on that. I have since purchased an openbuild OX 1500 x 1500 machine and got it all put together. Below is the list of everything that I have set up. OX 1500x1500 Machine Nema 23 Motors 48vDC Power Supply Panucatt Gradus M1 Pro with Bigfoot Controllers GRBL 1.1 Universal G-Code Sender Controller software. $h sends my machine to the top left corner and z all the way up with home switches. My understanding with GRBL and typical CNC machining is that everything is working in the negative plane rather than positive. I typically use vectric to make signs and whatnot which puts me in the positive plane. I have even tried using the gcode that is attached since it was made for this machine to build a box for this machine. Below are my $$ settings as well. What I am having a tough time understanding and getting the machine to work is that whatever gcode I send I receive an "alarm 2" error. Which to me means that it is sending it to the positive plane which will not work with GRBL. I have tried resetting the working coordinates to 0 on all planes but I still receive the error. I don't understand how to set it to 0 at the corner of my material and it will actually run properly. Do I have to home then basically job my machine to the opposite max corner to start? That just seems inefficient, but maybe that's it. Please any help would be greatly appreciated. and let me know if there is anything further I should provide to help identify what I'm doing wrong. $0=10 $1=10 $2=0 $3=1 $4=0 $5=0 $6=0 $10=19 $11=0.010 $12=0.002 $13=0 $20=1 $21=0 $22=1 $23=0 $24=50.000 $25=300.000 $26=250 $27=2.000 $30=12000 $31=4000 $32=0 $100=53.440 $101=53.440 $102=397.870 $110=7500.000 $111=7500.000 $112=500.000 $120=100.000 $121=100.000 $122=10.000 $130=1450.000 $131=1450.000 $132=60.100
Maybe I misunderstood you, but it sounds like your g code is "running the wrong direction." Looking at your G code in a simulator (see below), It would run just fine on my machine. However, You have $3 = 1. I have it as $3 =0. It appears you have inverted your X axis. From GRBL Wiki Grbl v1.1 Configuration · gnea/grbl Wiki · GitHub : $2 – Step port invert, mask This setting inverts the step pulse signal. By default, a step signal starts at normal-low and goes high upon a step pulse event. After a step pulse time set by $0, the pin resets to low, until the next step pulse event. When inverted, the step pulse behavior switches from normal-high, to low during the pulse, and back to high. Most users will not need to use this setting, but this can be useful for certain CNC-stepper drivers that have peculiar requirements. For example, an artificial delay between the direction pin and step pulse can be created by inverting the step pin. This invert mask setting is a value which stores the axes to invert as bit flags. You really don't need to completely understand how it works. You simply need to enter the settings value for the axes you want to invert. For example, if you want to invert the X and Z axes, you'd send $2=5 to Grbl and the setting should now read $2=5 (step port invert mask:00000101). Setting Value - Mask - Invert X - Invert Y - Invert Z 0 00000000 N N N 1 00000001 Y N N 2 00000010 N Y N 3 00000011 Y Y N 4 00000100 N N Y 5 00000101 Y N Y 6 00000110 N Y Y 7 00000111 Y Y Y $3 – Direction port invert, mask This setting inverts the direction signal for each axis. By default, Grbl assumes that the axes move in a positive direction when the direction pin signal is low, and a negative direction when the pin is high. Often, axes don't move this way with some machines. This setting will invert the direction pin signal for those axes that move the opposite way. This invert mask setting works exactly like the step port invert mask and stores which axes to invert as bit flags. To configure this setting, you simply need to send the value for the axes you want to invert. Use the table above. For example, if want to invert the Y axis direction only, you'd send $3=2 to Grbl and the setting should now read $3=2 (dir port invert mask:00000010) I start at the bottom left and my Z zero is the spoil board so everything I do is usually in the positive. Here is a picture from the simulator I used. Your code is zeroed at bottom left.
that is wrong. home is TOP/RIGHT/UP remember that axis directions are 'tool motion' X+ is tool to the right Y+ is tool away (or top as you put it) Z+ is tool up away from the work so if your home is X to the left it means that the X direction is incorrect. Turn homing off and get the directions correct before proceeding.
Just to be clear of what we are talking about. I just put together a cad image of what I'm working with. UGS won't let me jog in the positive direction at all whenever I set 0,0,0. Apologies on $3. I'm confident that I have that direction set properly as it homes to my home switches when I use $h. does this make sense as to how it is set up?
Here are the steps that I am taking to do this. 1. $h 2. Jog X - direction 20" 3. jog Y - direction 30" 4. Jog Z - Touching workpiece. 5. Select Reset X,Y,Z 6. Loading Gcode 7. Hit play. When I reset 0,0,0 in the correct spot with 1.09 it gives me and alarm 2. I am just clicking the reset x reset y, reset z buttons. In UGS 2.0 it presents these errors bottom error first, then top error.
GRBL doesn't support M6 (tool change) or G64. The prevailing philosophy is that the GUI (in your case UGS) should implement "work arounds" when things like M6 are encountered. I did a little bit of searching on CAMBAM and grbl post-processors and it looks like yours is a common issue. Here is one example thread that addresses it some: Grbl interpreting inches as mm · Issue #502 · grbl/grbl · GitHub (That thread is pretty old - you might want to search for others.) If you are not actually doing a tool change, you can remove the line T1 M6 from your code. In the thread linked above, one poster simply removed the G64 G40 codes from that line and reported success. The other stuff you are doing (your set-up) looks correct to me.
Ok. Sounds good. Thank you for your help and patience. I will give it a try tonight and see how it goes.
I got everything working tonight. I very much appreciate the help. I will be doing some more investigating and learning more as I go. I really appreciate all the help. I don't want to open a new thread, so thought I'd ask here. The controller has a probe slot. Does that mean that I can accurately 0 all axis' with a touch plate?
Glad you got it going! I'm not sure how the probe works on the Gradus. It's the controller I use, but I haven't tried a probe. You may have noticed that the documentation for the Gradus is pretty "sparse". If you try it, and get it working, please report back the details to the thread: Gradus M1 Pro - Information (Or at least please post a new thread with details of how you got it. The thread linked above is one I started to help document the poorly-documented Gradus M1 Pro.)
