Thanks Sonny, I am trying to trobleshooting my system to remove the homing fail problem. >> could you please indicate to me the procedue to remove Z axe from homing cycles ? ( or could you send the config file to replace the existing one ? ) I would like to remove that axe and then proceed .... At the moment I do have the homing fail as soon as the Z cycle has completed : x and y move a little bit and then I get the message. Thanks for helping. Ambrogio
It is me again: This is my console reply... Grbl 0.9j ['$' for help] ['$H'|'$X' to unlock] [Caution: Unlocked] ok ok $0=30 (step pulse, usec) $1=30 (step idle delay, msec) $2=0 (step port invert mask:00000000) $3=192 (dir port invert mask:11000000) $4=0 (step enable invert, bool) $5=0 (limit pins invert, bool) $6=1 (probe pin invert, bool) $10=3 (status report mask:00000011) $11=0.020 (junction deviation, mm) $12=3.000 (arc tolerance, mm) $13=1 (report inches, bool) $20=0 (soft limits, bool) $21=1 (hard limits, bool) $22=1 (homing cycle, bool) $23=0 (homing dir invert mask:00000000) $24=50.000 (homing feed, mm/min) $25=500.000 (homing seek, mm/min) $26=250 (homing debounce, msec) $27=8.000 (homing pull-off, mm) $100=22.850 (x, step/mm) $101=22.850 (y, step/mm) $102=220.000 (z, step/mm) $110=1000.000 (x max rate, mm/min) $111=1000.000 (y max rate, mm/min) $112=200.000 (z max rate, mm/min) $120=50.000 (x accel, mm/sec^2) $121=50.000 (y accel, mm/sec^2) $122=2.000 (z accel, mm/sec^2) $130=1.000 (x max travel, mm) $131=1.000 (y max travel, mm) $132=1.000 (z max travel, mm) ok ok ok ok
Open the config.h file with wordpad. Do a FIND using the terms "Define the homing cycle search patterns with bitmasks". Down towards the bottom of the section that comes up with the search, there are two lines concerning Homing Search Cycle. The first (cycle 0) is the Z-Axis, the second (cycle 1) is for the X and Y axes. I have never changed these, but I assume you comment out the first to get rid of Z-Axis homing. You may also need to change the cycle 1 to cycle 0 in the second. You probably also need to delete the 1<<Z_AXIS from the #define HOMING_LOCATE_CYCLE entry. Here is the text from config.h: // Define the homing cycle search patterns with bitmasks. The homing cycle first performs a search // to engage the limit switches. HOMING_SEARCH_CYCLE_x are executed in order starting with suffix 0 // and searches the enabled axes in the bitmask. This allows for users with non-standard cartesian // machines, such as a lathe (x then z), to configure the homing cycle behavior to their needs. // Search cycle 0 is required, but cycles 1 and 2 are both optional and may be commented to disable. // After the search cycle, homing then performs a series of locating about the limit switches to hone // in on machine zero, followed by a pull-off maneuver. HOMING_LOCATE_CYCLE governs these final moves, // and this mask must contain all axes in the search. // NOTE: Later versions may have this installed in settings. #define HOMING_SEARCH_CYCLE_0 (1<<Z_AXIS) // First move Z to clear workspace. #define HOMING_SEARCH_CYCLE_1 ((1<<X_AXIS)|(1<<Y_AXIS)) // Then move X,Y at the same time. // #define HOMING_SEARCH_CYCLE_2 // Uncomment and add axes mask to enable #define HOMING_LOCATE_CYCLE ((1<<X_AXIS)|(1<<Y_AXIS)|(1<<Z_AXIS)) // Must contain ALL search axes Hope this helps, Steve Fox
Thanks Steve, Do I have just to " save" in wordpad ? How to create a file to send to Arduino please ? Where should I have to connect the Laser ON OFF control ? ( which arduino pin ?) It is a great help: thanks again Bye
Yes, save the file in wordpad. Once you have made all the changes that you want to all of the associated files, you have to compile GRBL in the Arduino IDE. If you don't have it, the current version is 1.6.9. It is free to download, just do a search on Arduino IDE. There are lots of links on how to use the Arduino software, if you don't have any experience with it, it would be beneficial for you to read up on some of them. The two settings you have to change are the board type and USB Port. There is also a good WIKI on GRBL, it would also be beneficial for you to read up on that. After reading a little, it should begin to "click" for you. I've been using GRBL for two years and Arduino for closer to six years and I still have a long way to go, but I have most of the basics down. I haven't built a laser that uses Arduino, only an OX, so I'm not the correct person to answer your questions concerning connections. You should probably ask those questions in the laser forum. From what I have seen, those people are really helpful. Steve Fox
Hi, I modified the config relevant to the v 0.9J but the Z still moves at the beginning of the homing cycle and then the fail message comes on. I am not finding the #define HOMING_LOCATE_CYCLE ((1<<X_AXIS)|(1<<Y_AXIS)|(1<<Z_AXIS)) exactly on my config.h (0.9j). I did flash the Arduino using its IDE and had the good report as usually. >> Could you please attach the piece of modified file for me ? I did some troubleshooting last night : the directions of the three axes are correct, The six NO switches , if activated by hand, lock the system immediately. Could you suggest additional tests to troubleshoot the homing problem?. Thanks for helping. Ambro
I just wrote up how to do this in the Grbl FAQ. Here's the direct link: Frequently Asked Questions · grbl/grbl Wiki · GitHub You don't have to modify the HOMING_LOCATE_CYCLE in the most recent version of Grbl v0.9j.
I'm afraid I'm not going to be much help. I tried modifying the config.h file as discussed in this FAQ: Homing with 2 Axis Machine · Issue #224 · grbl/grbl · GitHub When I compile it, it gives me an error in a different file, concerning the Tool_Length_Offset_Axis. I don't know what to do to fix that and I don't have an Uno board where I am now to test in more depth. Sorry I can't be more help, maybe someone with a two-axis machine will answer. Sorry, Steve Fox
I just compiled Grbl v0.9j with the two lines altered in config.h to set two-axis homing. I get no errors. Tool_Length_Offset_Axis is not related to homing at all, but it's likely you changed something else to cause the error.
Thanks for all the assistance, I did follow step by step the procedure. Now the Z is not activated at $H. As soon as the X moves ( few millimeters ) the homing fail comes on . Ambro
I disconnected all the switch wiring from the board but still have the message: ALARM: Homing fail. Ambro
Homing fail occurs if the limit switch is not cleared after touching-off it or if it fails to find the switch. Make sure your settings for max-travel are close to accurate and your pull-off distance setting is large enough to clear the limit switch. Homing will fail if you do not have any switch connected to your limit pins or if they are wired incorrectly.
I have 5 Vdc on each of the board input switch and I have 0 Vdc when the switch is pushed. On my schematics I have D_10 X_limit, D_9 Y_limit, and D_12 Z_limit. The schematic is " arduino nano v3.0 GRBL Pinout " : Is this OK ? Ambro
Found !!! there is a mistake in the pinout diagram in my hands. D_10 is Y and D_9 is X limit !!! >> Could someone post the correct pinout applicable to the Nano please ? My system works well now ! Good GRBL ! A great assistance from this forum, good work ". Thanks to everybody. Ambrogio , IW2FVO North Italy.
The pin diagram for Grbl on the Arduino Uno is exactly the same as the Arduino Nano. Each pin maps to the same Dx and Ax pin on either board.
Hello. This is probably a very silly question, but I wasn't able to find a definitive answer. I am running GRBL 9.0i, and have noticed that steps per mm ($100,$101, $102) settings are not defined. Neither are the maximum feed rates for the axes ($110,$111,$112). They don't appear at all on $$. Despite all that, the machine runs correctly, traveling the appropriate 1mm per (200 step) rotation, and at comfortable speeds (on rapid). So, I am assuming, there are some hard-coded default values to fall back on, when those settings are not defined. If this is the case, it'd be nice to know them, since they work quite well, and I would prefer an option of returning to them, if I muck around with the settings (defining them to some value). Thanks!
Hi to all in this forum, I am still running v 0.9j; I have a question on the $5 "limit pins invert , bool ". $5=0: I am using Normally Open switches and so I have 0 VDC ( LOW state ) at the input pin when the table hits the limit switch and 5Vdc ( HI state) in normal condition ( no limitation ). I do assume this operation is correct and I have the Hard Limit message when the table hits just one of the six switches. $5=1: I do suppose the operation is inverted: LOW state is normal operation and HI state is limiting . I found that if the pin is in HI state ( limiting ) I can still jog the table and no message is provided. It is not clear to me ! I will appreciate any comment . Thanks in advance Ambro
Hard limits in Grbl detects a pin change, rather than state, using the AVR's built-in pin change interrupt. If you try to check for pin state and the switch is bouncing, the check has a very small chance of reading the incorrect state. But, you're right to be confused about why it's not being read at all when you alter the setting. I may add that in v1.0. FWIW, the homing cycle shouldn't work with the limit pin inverted.
Hey Sonny and company! First, thanks for answering all these questions and providing some awesome support for the GRBL community. Second, I have a problem! I run GRBL 0.9g and it runs perfectly smooth. I am having a big struggle with setting up a macro on UGS for z probing. My macro is as follows: I laid it out with comments so you can follow my logic G91; //Ensures I'm in relative mode G21; //Ensures I'm in mm's G38.2 Z-50 F150; //Probe the z axis down by 50mm at a rate of 150mm/min G92 Z0; //Zero my z axis G90 Z+5; //Switches me to coordinate mode and moves me to +5mm G91; //Puts me back into relative mode G92 Z0; //Zeros my z axis at this current location The problem I'm having is that when I run the G38.2 command line, it triggers an alarm the moment the probe touches. Once this happens, it stops and does not go beyond the g38.2 command. It tells me: .... Alarm: Probe Failed [Reset to Continue] ....When I reset, it does not pick up from where it left off in the macro. It acts as if nothing happened. (-_-) *Sigh* My probe is connected directly from A5 to GND on the arduino uno. No resistors or capacitors have been added to this setup. I am not wired for limit/home switches. I'm only interested in probing. So my soft limits and hard limits are turned off. Any clues on what the problem is? Thanks!! Edit: I will post my $$ settings when I get home. Just wanted to know if there is an obvious solution to this frustrating problem.
A probe failure occurs when two things happen. First, if the probe fails to trigger when it reaches its probe destination (and the probe cycle allows this error, i.e. G38.3 does not.) In other words, the probe must touch and trigger well before the probe travel expires. Second, if the probing cycle detects the probe state is triggered BEFORE it initiates the commanded probing cycle. That's the only times when you get a probe fail alarm. Check your logic and wiring to make sure that these two scenarios don't occur.
For any of you who are interested, I have launched my Kickstarter to upgrade the popular diode laser engravers. It adds limit switches, the ability to run GRBL 0.9, PWM power, Pause, Resume, Cancel buttons, automatic homing, and more. All of that is supported by GRBL and big thanks to Sonny and all of you. Here is a link: Big Blue Sparx Diode Laser Upgrades I hope no one minds the self promotion. I do think some of you will be very interested.
Wow, thanks for the quick reply Sonny! I will recheck the logic and wiring when I get back home! Here is a silly question but I think it needs to be asked to be sure: Is there an enable probe setting in the $$ menu that I need to turn on? Also, is it possible to probe using momentary switches setup as Normally Open (NO) and connected to the same A5 to GND pins? Thanks for clearing all that up! I was thinking that I needed a special override to disable the alarm, haha.
CNC XPro v2 Z Axis Pull-Off Incorrect When I home my machine using Universal GCode Sender the X and Y axis home and pull off 10 mm as set in GRBL v0.9 The Z axis also home's just fine and also will pull off 10mm but on the screen for Universal GCode Sender it shows -60mm instead of -10mm as for X axis and Y Axis. Has anyone had this problem before?
I think that I figured out the issue I posted above. My Z axis homes in the UP direction and my Z Max Travel ($132=70) is set to 70mm. My pull off is ($27=10) is set to 10mm. The Z axis homes UP and this is 70 and the pull off is 10 which equals 60. Is this correct? Any input is always appreciated....
Hi sonny jeon and Everyone out there .. I am new to grbl and am planning to build my 2 axis or 3 axis CNC plotter. Just have some confussions so need help from you guys. first of all how X and Y axis are determined for grbl setup ? i mean the forward and backward moment of table is which axis ??? left and right movement is which axis ( the one on which spindle etc is mounted)??? Next thing which " does and don't " things i must know before i start my build .. i am planning to use version 0.8 of grbl. Thanks in advance waiting for your reply
Table-type (ie. gantry) builds are viewed like a mill, from the top down. So left is -X, right is +X, away is +Y, and towards you is -Y. Dos and don'ts can really only be solved by you, every build is different; read this entire thread, read the grbl Github documentation, read any builds that are similar, etc etc. Research is the key to a smooth build process.
do not use version 0.8, 0.9j is MUCH better Motion directions as in the image below (what Mark said) are 'tool motion' so in the image below for +X the table moves left but that is the tool moving right for +X
