So I figured out the issue. I had two problems working against me. The first was that I used the same colored pair of wire for two of the axes. So i was looking at the wrong stepper driver board. once I figured this out, it quickly became apparent that the correct stepper driver board is bad. Thanks for taking the time to help me work through this noobish issue. Jake P.
I have been wrestling with homing for several days. I am able to modify and build the firmware (0.9j) and load it onto the board successfully. I am working with a 2 axis diode laser. After much debugging, I have discovered that the board I am using (Eleks Maker 3 Axis), while it has pins for Limit switches X+, X-, Y+, Y-, Z+, Z-, ALL of them are connected to D9. What I see is that X homes correctly and then the carriage moves toward the Y limit and just keeps going - presumably because the Y limit switch bit never gets changed. Is there a way to use the board for homing in this condition? Is it possible to have it do homing correctly if I tell it that both X and Y switches are on the same port? Thank you very much for any ideas and help. Bob
That's an interesting problem. I recall writing Grbl's homing cycle to be able to combine multiple axes to a single pin, as a way to save available pins. But, I can't remember exactly how I planned on doing it. First, you'll have to split up the homing cycle into separate cycles for each axis in config.h. By default, Grbl combines the x and y axes homing into one cycle. Next you'll probably need to re-define the pin mapping in the cpu_map header files, so that the y-limit is on pin 9. That should do it, but I can't guarantee it. Please let me know if it works out.
I'm very new to the world of CNC machines and I recently built a simple laser cutter that uses grbl on Arduino. It works great except the engravings are being mirror'd horizontally. Any idea why this is happening? My setup looks like this: Two steppers on the X-axis being controlled by two A4988s but through a single step and dir pin pair. A single stepper for the Y-axis. Am I correct in assuming that the two-stepper beam is indeed the X-axis? The step and dir pins for these are connected to the X-axis step and dir on the Arduino (pins 2 and 5). Also, I tried switching the step and dir pins with those of the Y-axis but that did not work.
It's most likely that you have one of your coordinate axes inverted. Make sure that your machine moves the correct direction when you command it to move. Typically, when an X-positive moving is executed, the tool will move to the right, relative to the part. Y-positive will move the tool away from the part. Google search for CNC coordinate system for more information. To fix it, set the invert direction setting in Grbl to reverse that particular direction.
It can also be your cam, depending on where you set the origin. I had one model that even though I had the top of the stock as Z=0, it decided that the safe plane was 3mm INTO the wood, and then lifted up to do the cuts.
Hey, it works!!! By setting the Y limit pin to the same as X: // try mapping the Y limit to the same as the X limit for the Eleks Maker 3X board to enable homing #define Y_LIMIT_BIT X_LIMIT_BIT // Uno Digital Pin 9 and setting the Homing Cycles as 2 steps: //#define HOMING_CYCLE_0 (1<<Z_AXIS) // REQUIRED: First move Z to clear workspace. #define HOMING_CYCLE_0 (1<<X_AXIS) // OPTIONAL: Then move X,Y at the same time. #define HOMING_CYCLE_1 (1<<Y_AXIS) // OPTIONAL: Then move X,Y at the same time. Homing on that board works! Thanks for the help.
Talk about perfect timing! I've spent the last day or so searching to see if there was a way to allow multiple home switches on a single pin with grbl My machine runs all N/C home switches connected in series ( currently under Linuxcnc with a Gecko G540). I've wanted to give grbl a try but didn't want to rewire and reconfigure things too much to do it. BlueHairBob did you also define the Z_AXIS for pin 9?
Combining all 3 axes to a single pin should work exactly the same. You'll need to add another homing cycle for the third axis, so it'll look something like this in your config.h. #define HOMING_CYCLE_0 (1<<Z_AXIS) #define HOMING_CYCLE_1 (1<<X_AXIS) #define HOMING_CYCLE_2 (1<<Y_AXIS)
I should have read your original post in more detail. I was just glad to find someone asking about the same issue I have (or had).
OK new issue: Homing does not work. I've wired 4 limit switches (2 on either side of X and Y axes). Both the X axis switches are connected to pins 9 and the Y axis switches to pin 10 of the Arduino and they both have a 560R pull-down resistor. I've enabled homing and hard limits within grbl and when I run $H, nothing moves and after some time I get the "ALARM: Homing failed" message. I checked the voltage on the limit pins on the Arduino and they show 5V. I tried inverting the limit pins ($5=1) but still no luck. What am I missing here?
By default, Grbl is setup for 3-axis homing and starts the homing process with the z-axis. If you haven't altered the config.h file to do only 2-axis homing, then Grbl is likely trying to home the z-axis and not finding the z-limit switch.
Oh I never thought of that. I've built a laser cutter with just the X and Y axis. I have not altered config.h yet. So would it work if I change the homing sequences from this: #define HOMING_CYCLE_0 (1<<Z_AXIS) // REQUIRED: First move Z to clear workspace. #define HOMING_CYCLE_1 ((1<<X_AXIS)|(1<<Y_AXIS)) // OPTIONAL: Then move X,Y at the same time. To this: #define HOMING_CYCLE_0 ((1<<X_AXIS)|(1<<Y_AXIS)) OR #define HOMING_CYCLE_0 ((1<<X_AXIS) #define HOMING_CYCLE_1 ((1<<Y_AXIS) EDIT: OK so I tried the above line and flashed the recompiled hex to Arduino. Also since I have pulldown resistors I inverted the limit pins by setting $5=1. Now the homing does not fail on screen and no alarms are triggered but it moves every so slightly and stops
Not sure about the pull-down resistor setup you have. Grbl, since v0.9, assumes the pin has its internal pull-up resistor enabled at all times. When you change $5=1, you only change whether Grbl reads the pin when high as triggered, rather than low. To disable the internal pull-up and use your pull-down resistors, you'll have to uncomment the line '#default DISABLE_LIMIT_PIN_PULL_UP.'
Ok. Let me try this. Thanks. Do the max travel default settings make any difference in the homing cycle? One time, homing did work. The axes moved till the travel limits (200 mm default) and then stopped. When I adjusted the travel limits more than the actual travel the laser assembly did hit the limit switch but it did not trigger a stop and tried to move beyond the physical limit.
Yes. Grbl will search for the limit switch for a distance of about 1.5 times the axes travel. If Grbl starts a homing cycle and does not stop when it hits a limit switch, then there is something wrong with your wiring or Arduino pin. Before a homing cycle starts, Grbl checks the limit to see if its triggered. If so, then it'll return a homing cycle error. Once homing begins, Grbl will actively check the state of the limit pin for the homing axes until it sees it triggered and will immediately stop motion. It will then go in a location cycle that pulls off the limit (based on pull-off distance) and re-triggers it at the homing feed rate.
I'm A NOOB on the CNC laser cutters, and have a problem similar to the one on this thread. My equipment is an A4 Eleks with Arduino (Windows 10), Board: "Arduino Duemilanove or Diecimila, ATmega328" ) I got it from GearBest in China, and they are a place I will never shop again. No support, no build instructions, (I made it work ANYHOW!), and the software they sent was virus infected. So no more of my money will go to them... I managed to get uninfected copies, and made it go. WAS working nicely. Re-flashing the EEPROM with the Arduino code didn't help. My X axis is flipped (rendering all MIRRORED images), The machine has NO limit switches, and I inadvertently loaded an image to cut that was WAY bigger than the range the cutter can actually go to, there was a lot of unhappy noises from the cutter, and after, it started mirroring all the time. I'm not a programmer in the Arduino environment and have hopes that someone has been in the same boat as me. I'm rather frustrated, as you might well guess. Help! Thanks for any help in advance, John
first you should read this https://github.com/grbl/grbl/wiki/Configuring-Grbl-v0.9 where you will learn that flipping an axis is just a setting away (-: the value for $3 is the one you will want to change. this can also be done in hardware by flipping 2 wires (on the same coil of course) on the stepper motor, but since you loaded something that caused this, my guess is a software fix is better. also, you should set the softlimits so that grbl knows when something is too big for the machine which will prevent it running into the end stops. have fun
GRBL 0.9 DOES NOT WORK on my machine, so I re-flashed. to 0.8c. Tips on 0.9x won't help me since I am on 0.8c. Sorry if I wasn't clear. My X axis is flipped horizontally. It is a CHEAP Chinese made bit of hardware with no limiter switches, and no way (I know of) to tell it to swap the horizontal (X axis). I tried using Universal GRBL sender (Java) and asked to switch the X Axis, no joy. I tried GRBL Controller 3.X and it didn't help with the X Axis "flip" either. I am at a loss. I will try changing the $3 value. What value should I see, and what value should I change to it, if 0.8c even allows this bit to be set? I am enough of a NOOB to ask, how do I set this $3 value? I have one sender that has a console mode, and I am guessing that it will be the one to use, how does one format a request for the current value of a $3 bit, and how does one format a value change at the console? Thanks very much for the reply. I appreciate it, but I'm STUCK on 0.8c, as 0.9x won't work with the Chinese hardware I have. I have already bought a different machine which is to arrive today - and am trying to salvage what I can with the Eleks A5 Unit I have. Again, thanks! John
Tried several values for the $3 setting, made no difference at all. It will not obey the flip X axis command from GRBL Controller 3.6.1 either.
Look at he wiring for he X stepper to the controller you have. There should be two pairs of colored wires between the two. Given the other issues with your machine, who knows if the colouring scheme is 'standard'. Nonetheless, all you need to do to invert the X is to invert ONE of the two pairs - left wire of pair becomes right and vice versa. This should get your stepper going in the right direction.
I found the step port inversion mask was $6, and the value of 100 worked saved to my machine's EEPROM. $6=100 $3 had no apparent effect. The problem seems solved. Thanks for pointing me in the direction I needed to go. The reference that helped was at: Grbl Controller Options | zapmaker Problem fixed! Sign me happy. John
It could be handy to be able to "Flip" horizontally (mirroring), the value that has somehow gotten written had been $6=200. This value could be used when making an applique or sticker for putting on the inside of a window or the cutting of the back of a mirror to create a design on the front. $6=100 goes back to normal. You can flip the Y axis too, but I wasn't interested in doing that so I didn't use that value. I think it was $6=160 which flipped both x and Y axes. Experiment away... Some values won't save to the ROM, I think because they are invalid values.
For Grbl v0.8, see the Wiki on configuring that version. The bit masks to set the stepper directions are a bit convoluted in that version and prior.
Can GRBL handle a 4th rotary axis? I've seen some references online saying it will work for a 4 axis machine, and other places say it will only work for 3 axis.
It's strictly 3-axis at the moment. Most people run 4 motors with two on the y-axis for gantry type CNCs. I'm working on a 4-axis extension with an Arduino Mega fork right now. Should be out soonish. (The little 328p Arduino doesn't have room for the 4-axis code)
