Hi Burt Your fundamental problem is that you have your axes reversed. All Gcode is generated according to a convention that if bottom left is 0,0, then tool moving positive Y is away from you, and tool moving positive X is to the right. tool moving positive Z is UP away from the work. Cartesian Right-Hand Rule - CNCexpo.com So I think you need to correct that before you can correct soft limit directions.
Simply generate G-Code for the X-axis only, and only use one stepper driver in your shield. Just like if you were testing your driver boards one at a time. Nothing about G-Code or the machining environment means you MUST use all axes simultaneously.
@Rob Taylor so you mean that i can run the GRBL with only one axe connected ? i don't have to connect all the axis ? thanks for answering
thanks, but that is a very long commute from South Africa (-: my sister is in Fort Worth though, but she won't have a clue what you are talking about... awesome!
Hello, hope this is the right thread for my question: Does someone know the command to set all axes to zero?
Assuming you mean "set current work position to zero" and not "reset position to origin", that's a G10 command. There are multiple options here: L2 vs L20: L2 sets an offset from machine position. If you put in your current machine position coordinates, it'll set your work position to the new origin. L20 calculates the offset for you, and you simply set the work coordinates that you want the current machine position to be. The convenience of having both of these is that it's easier to use L20 to set your new origin, and then use L2 to re-set your original origin. In either case you end up using X0Y0Z0. P0-9: P sets the coordinate system. P0 should mean "active", and theoretically you can use this in all cases you don't want to change the system. I've found that it's better to specifically use the number that relates to the workspace you're in. P1 is G54, which is probably what you're using if you're not setting a bunch of hot-swappable offsets. P2 through P9 reference the other 8 coordinate systems in turn. Then you just put in the axes you want to zero, as you would normally. TLDR: G10L20P1X0Y0Z0, probably
easiest is to use one of the GUI programs and just click the '0' button for each axis as needed. Using Grbl · grbl/grbl Wiki · GitHub or use homing less easy is to use the G10 command sequences by typing them in Home · grbl/grbl Wiki · GitHub G10 L2, G10 L20: Set Work Coordinate Offsets http://linuxcnc.org/docs/html/gcode/g-code.html#gcode:g10-l2
Thanks David, I've been tied up for a few days chasing some 3D printer gremlins, so just had a chance to get back to check the forum. Are you saying reversed as in travel direction, or reversed as in X and Y? I've tried reversing the steppers for X and Y but that just moved the corner that the machine homes to (obviously I had to swap the X and Y limit switches too). And I had tried swapping my X and Y during one test but that again just changed the corner that is homed to. It didn't change the fact that all movement in the work space was negative. A few more details. In my case the machine is square, with X and Y axis the same length. I had read somewhere that the machine movements are negative (but there are so many sources on the web that are contradictory that it's hard to know which is correct if you haven't dealt with CNC before). There is, or course Machine Position, and Workspace position. With my machine when GRBL homes it I have to move negative X / Y to be on the work space. If I move to the opposite corner of the workspace from the Machine home and set the Workspace positions to 0 for X/Y then all moves are positive on the workspace. So here's what I have currently: With Workspace X/Y zero set to the opposite corner from the "lower left" corner that is homed that is now the lower left for reference to the workspace and movements are positive relative to that position. My Z is definitely up for positive and down toward the work surface for negative, so that is fine. So I'm back to scratching my head a bit. Regardless of how I have the motors plugged in GRBL doesn't know, or care about the motor direction being reversed as long as both X and Y are reversed, so that is of course why I see the homing corner change. But GRBL still is reporting negative movement. At the moment I'm playing with Chilipeppr and when I issue $H GRBL moves to the lower left corner of the machine. Chilipeppr shows X and Y of -5mm "I have my home pull-off set to 5mm". So $H took it to 0,0 in the lower left corner, but when GRBL does the home pull-off it moves to -5mm, and all movements on the work surface are in the negative direction from the machine zero. Like I said I was able to set G54 with a workspace zero that is at my max negative locations for X / Y and then all movement is positive on the work space. But I don't see any way to reverse either the axis or the motor direction to make any difference on what GRBL is reporting for the machine position and movement from machine home. Or is there a GRBL setting that I missed? For grins and giggles I tried $3 the direction port invert mask but all that did was just move the home corner, just like reversing the stepper plugs and that was what I expected. Next I tried the Homing dir invert mask $23 that homed to the opposite corner and in my case machine position is reported as -295 (X and Y) That is my max 300mm - the homing pull-off of 5mm. But everything on the work space from the perspective of the machine home is in negative space. So am I still missing something with the machine configuration and / or GRBL setup or is it just my confusion over machine space vs work space? If it's the machine vs work space issue then I need to do some more testing with the soft limits to see if I still have the problem I was seeing the other day. Thanks again, Burt So
I am saying that before you can sort out where home is, you need to make sure that the machine is moving in the correct direction according to the standard/convention, otherwise normal Gcode will not work correctly. So turn homing off in GRBL for now. So, back to a drawing Cartesian Right-Hand Rule - CNCexpo.com Make sure that with 0,0 set at close/left, X axis left to right, Y axis toward/away positive Y tool motion is away from you positive X tool motion is to the right Note I said 'tool motion'. In the complexity of moving gantry/moving table/ other combinations of things that move, the only way to really define direction is in tool motion. Once you have those directions correct, you can set the homing direction mask to make it home in the correct place (opinions differ on this, as you noted). To me that is Z at the top of travel (SAFE) and XY at close/left. This is 'machine position'. Now when you set up a part and set 0,0,0 on the part, you are setting a workspace position, G54 by default. This does not change the direction of anything, only the 0,0,0 point. What I would do is set all GRBL reversing to 'off'. then swap motor wires to get the correct directions. Now homing dir invert mask should also be all 0 and it will home to bottom left giving positive movement out into the cutting area. So, get the basic directions correct first, then make homing work within that framework.
FYI, Grbl sets home/origin in the back right-top corner of the machine, rather than the front left-bottom corner that 3d printers do. One of the main reasons is 3d printers have a fixed tool tip (extruder nozzle) and it makes sense to set the origin there, so everything is positive. Milling machines or CNC routers have a tool that can vary greatly in length, depending on the tool and the spindle, so you don't have a repeatable reference point to set the origin like a 3d printer. The common practice is to set it in the opposite corner, so that all of your machine coordinates exist in negative space, rather than positive.
Could you expand on that? I'm not sure I understand the relationship between vertical tool length and X-Y positioning? I'm also confused as to why back-right would lead to positive workspace, if the mathematical positive quadrant is the top right one (ie. behind the machine enclosure!). Actually retrieving the workpiece from a fully enclosed space without hitting the toolhead makes more sense to me.
Thanks David and Sonny, So Sonny from what you are saying what I was viewing as the lower left corner is really the upper right that GRBL is homing to. That makes sense based on what I see. My initial machine build is 24" square for the frame so I don't have one axis that is longer than the other. Based on other things I'd read I was calling where it homes the "lower left" which it is if I move to that side of the machine. And in machine coordinates I see all negative moves into the workspace, and any GCode that is expecting positive work space moves of course would attempt to move off the work space in this case. So what I do is move the gantry to where I want the 0,0 point to be and set that in the work space coordinates as the 0,0 point and from there GCode that expects positive work space movement works correctly. That's the point I was missing. Before I turned on homing in GRBL I actually verified that from what is actually the lower left corner my moves were indeed positive into the work space. It was just that I was thinking that it was homing to the lower left corner for the machine and then I was seeing negative moves back into the work space. So unless I'm still missing something I'm good to go, other than I need to test with soft limits again to see if it was just something I didn't have set up or if setting the work space 0,0 causes some consternation with soft limits. Thanks again for your assistance, Burt
The back right would result in an all negative workspace. It's the standard origin and operation of most production CNC mills. This is the correct way to set up coordinate systems. Machine coordinates should always stay the same and remain independent of use from any g-code program. Always use work coordinate system to set your work origin, based on your tool tip and starting point of your g-code program. With homing, you'll first have to make sure your machine itself moves properly in the correct coordinate directions. i.e. X+ move X+. With the Grbl homing direction mask, a '0' will search for a limit switch in all positive directions and set the origin to (-) pull of distance. If you invert a homing direction, Grbl will search for that limit switch in the negative direction and still set the origin to the back right top corner, so you'll see (-max_travel + pull_off_travel) for that axis when complete. You can have Grbl set the origin wherever it completes the homing cycle by uncommenting HOMING_FORCE_SET_ORIGIN in config.h. Re-compile and flash.
I think part of my confusion was missing the exact wording of this rather vital clause: So never mind, my understanding is entirely correct, I just misread. ...Though I am still wondering why the tool variation suggests a different home, but maybe Google can help there.
Ok, I definitely found a questionable thing, @Sonny Jeon. M04 to turn on, M03 to turn off. 0.9j. What?! Ignores M05 altogether in either state, and also pays no attention to any value of S-address after either M03 or M04, yet I just checked the config file (the one I used to build it in Arduino IDE) and variable spindle on D11 is active. Using a knock-off Protoneer CNC Shield, but Spindle Dir pins have continuity to D11 and GND, so the hardware is intact enough for my purposes, as far as I can tell. I have no idea what might be going on, though I at least have enough control now to modify G-code files to function, for the time being.
um, it is supposed to be: M03 is 'spindle on clockwise' M04 is 'spindle on anticlockwise' M05 is 'spindle off' ignoring S words is a function of whether or not you have spindle PWM control on or off. PWM on does change the spindle control pin!
The behavior you are describing looks like the spindle direction pin on D13, not spindle enable/PWM on D11/D12. This pin only goes high or low, depending on if the spindle was commanded to go CW or CCW. M5 has no effect on it, since it always retains the last change.
Looks like you're right. SpinDir also has continuity to D13, and D11 is grounded, for some reason. I'll have to take it apart and check what's actually coming from the pins themselves, and I probably need to cut some traces and circumvent the CNC Shield outputs. Thanks!
Update: Yeah, the bare Uno (also knockoff, for reasons explained later) is outputting the correct signals from the correct pins. So it's a shield problem. Thanks for the assist!
im having trouble up loading v.9j to my arduino uno . im able to upload .8c through ardhuino ide with the sketch. when i try 9j i get avrdude: stk500_recv(): programmer is not responding. also dont minf the png i some how attached lol.
I sometimes have this issue and don't know exactly where the problem is coming from. Resetting the Arduino a second after clicking upload helps a little, but most often, I would re-burn the bootloader onto the Arduino. The latter would almost always fix it.
I'll have to learn how to burn a bootloader. I know there's a way to use one arduino to burn it on another but looking at the sketch and looking up how to connect the two uno boards I have I got really confused last night when I attempted todo this to see if that was the problem cause I read some where that it didn't allways work with arduino UNOs that had a older bootloader . Is there a idiot proof guide how todo this? Looking at the sketch in the example I found confusing and the photos I was able to find of how to wire didn't seem to match at all .
i was able to get to burn the boot loader and upload 9j from the ide. thanks alot. turned out i was just getting confused by the notes in the example library for arduinoisp
Can anyone give me some assistance please, I've been in and altered my config.h file i.e. the part that sets the max rpm in the variable spindle section. When I try to 'verify' in the 'Arduino IDE' before uploading I get the following error msg. Ardu_up_error by RichGMD61 posted May 8, 2016 at 1:29 PM I've made sure that all the relevant files needed for the 'grblUpload.ino' file are in the same folder and yet I'm getting an error msg. Am I doing something fundamentally wrong. If I've posted in the wrong thread please accept my apologies. Forgot my set-up details, Oozenest OX 750 x 500 Cnc xpro V2 (as purchased from oozenest with 0.9j grbl preloaded) 1.5kw VFD, 0.8w spindle
Please follow the instructions on the Grbl wiki exactly. If you don't, you'll run into problems like this. From what I can tell on your error screen, you did not import the Grbl library or you're accessing the downloaded copy, not the library one.
Many thanks for reminding me, looks like old age and stupidity are beginning to get the better of me. Tried it the second time works like a charm. Richard
I went to this link . For arduino as isp Arduino - ArduinoISP I uploaded the sketch to the uno I was using asthe Isp device . No changes made to sketch . Wired it up as the drawing with the captictor . After that when up loaded the grbl sketch to the uno board I rebutted the bootloader on , I had to hit reset right after I clicked upload .
