Homing set up problems

[MarkEMark2]

I have struggled to get the homing working on my system. I am sure it is due to not understanding some of the settings in the config.h file, as well as the $flags in the GRBL system. I am trying to get the homing to work in my set up. I am using Normally Closed switches, one on each end of the respective axis (2 per axis) and they are wired correctly. I am using GrblGru as a front end for GRBL, and am using a Mega 2560 board with the GRBL-Mega system. It uploads perfectly when I first upload it to the Arduino. When I type $$ into the console to verify the settings I get the proper response and the settings are reflected. (This was a second installation as I deleted the first after messing with it a while. Interestingly, I see some older settings show up when typing the $$ even though I had deleted all of the original installation... noted here in case that's significant).

The problems: When trying to run the homing feature ($H) I immediately get Alarm errors even though the parameters in the settings appear to be correct, including the $20=1, $22=1. Thinking there may be something I am missing in the config.h file, I opened it to see what needed to be adjusted. There is a setting for use with NC switches in pairs, and I have removed the // comment marks to make it active. When compiling it to reload the changes to the Mega board, I am getting the following errors:

I found this earlier in the config file:

#define DEFAULTS_GENERIC
#define CPU_MAP_2560_INITIAL

// To use with RAMPS 1.4 Board, comment out the above defines and uncomment the next two defines
// #define DEFAULTS_RAMPS_BOARD
// #define CPU_MAP_2560_RAMPS_BOARD

This seems to indicate that the DEFAULTS_GENERIC is what is defined, not the DEFAULTS_RAMPS_BOARD which is commented out.

In the homing part of the config file further down I saw this line and it appears (as first installed - I did no modification to this part):

#ifdef DEFAULTS_RAMPS_BOARD
#define HOMING_CYCLE_0 (1<<X_AXIS) // Home X axis
#define HOMING_CYCLE_1 (1<<Y_AXIS) // Home Y axis
#define HOMING_CYCLE_2 (1<<Z_AXIS) // OPTIONAL: Home Z axis
#else
#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.
// #define HOMING_CYCLE_2 // OPTIONAL: Uncomment and add axes mask to enable
#endif // DEFAULTS_RAMPS_BOARD

This is the way it is listed in the config file without any adjustments on my part. Since I am having trouble with the homing, I am wondering if this could be causing the problem. Perhaps I should change this to read:

// NOTE: Defaults are set for a traditional 3-axis CNC machine. Z-axis first to clear, followed by X & Y.
#ifdef DEFAULTS_GENERIC
#define HOMING_CYCLE_0 (1<<X_AXIS) // Home X axis
#define HOMING_CYCLE_1 (1<<Y_AXIS) // Home Y axis
#define HOMING_CYCLE_2 (1<<Z_AXIS) // OPTIONAL: Home Z axis
#else
#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.
// #define HOMING_CYCLE_2 // OPTIONAL: Uncomment and add axes mask to enable
#endif // DEFAULTS_GENERIC

Would that be correct? Would this prevent the "Required HOMING_CYCLE_0 not defined" problem?

Also, What is the "WCO refresh must be greater than one" error that appears after this as well? Is it related?

I have spent the better part of 2 weekends trying to trouble shoot this issue. Thanks for the advice.

[fra589]

The screenshot with the error message shows that you are not using the correct procedure to compile and upload Grbl to your Arduino Mega board:
https://github.com/gnea/grbl/wiki/Compiling-Grbl
https://github.com/fra589/grbl-Mega-5X/issues/245

[MarkEMark2]

Thank you for the reply. I have done exactly as this page suggested several times as I had it open while doing the edits and saving of the config file. This is why I am posting here as I don't know where I might be going wrong. I really have followed the process listed including deleting all from my Arduino folder first. Then a fresh install and THEN editing the config file in the Arduino folder, and reflashing the Arduino.

How do you re-upload the changed config file? It says in the instructions on the wiki to change the file in the Arduino folder and upload that so that's what I did.

[fra589]

As I can see on your picture, many includes seams to have been added in your grblUpload.ino file: config.h, coolant_control.h, cpu_map.h, default.h and perhaps more...
So, it's not the good procedure describe in the WiKi!
The standard grblUpload.ino only contain:
#include <grbl.h>
So, erase all other old Grbl files on your system and restart with a clean procedure.

[MarkEMark2]

YES! I see where I was making my mistake before. I tried earlier today (before I left for work) and compiled it by changing the config file and uploading it from a fresh install worked at least in compiling (where I was having the issue). So I will try to do all of this and install it later today. Many thanks for the verification of the problem!

[MarkEMark2]

Attached is a screen shot of the alarm and the GRBL settings as revealed in UGS. Anyone know what we may be facing here? All motors and axis work when running the setup wizard, and I have successfully calibrated the movement. But as soon as I enable the homing and limit switches, I get the Alarm 1 or alarm 8 limit switch alarm. All the switches are checked (they are NC switches) and all are functioning and wired correctly. I traced the wiring all the way to the circuit board and all of the wiring is functional. The switches work, but the Z axis is flagging an immediate error upon enabling them. Triggering x and y work as planned. And, as you see in the picture, the x and y axis are green with the same wiring set up as the z axis.

Attached are the config.h file as I have attempted to look there for answers and have made the changes along the way when things didn't work on first blush. You can see my GRBL settings in the graphic attached as well. Any help for this would be greatly appreciated as the machine is finally ready to use, but the software set up is throwing this error. I am using:

• HobbyCNC 3 axis driver - new board.
• GRBL 1.1
• Arduino Uno R3 (also tried the Mega 2650 first and had the same issue
• Latest version of UGS and GrblGru (both seeing the same error)
• I installed a limit switch filter in line with the switches to minimize noise. I have wondered if there may be an issue with this board as the wiring all tests positive when checking them from the switches to this Opto board, and from the opto board to the driver board. All wires are good. power to the opto board and to the driver board on both sides of the opto couplers tests 5 volts.

In summary, all motors work and control properly until I try to use the limit switches, THEN I get an immediate z axis alarm saying I hit a limit switch - but none are active.

I normally use the Mega board and prefer it. BUT, I thought I would try the Uno board to see if there was an issue there. I get the SAME error in both boards, and since the Uno is connected now and I can grab the screenshots, I am attaching them to this.

Thanks for the help! I am really stuck. The Z axis constantly Alarms, and the switches check out properly, the hardward wiring is confirmed, and the boards operate when not running the homing routine. Homing immediately flags errors and I'm stumped. Is there a config issue somewhere I need to use?

[MarkEMark2]

The positions in x,y, and z, are all withing limits and not triggering the switches... Just want to confirm this as it might be a question as to my competency! :)

[MarkEMark2]

config.h.txt
And my config file

[MarkEMark2]

Sorry for the many posts but I am trying to cover all of my data because of the time delays :) Here is the screen shot of my current GRBL settings (that survived a complete new installation for some reason - I had installed this from total scratch. I was surprised the GRBL settings survived the install which seems suspect to me...) Posted here to show the error message I am getting showing 2 errors, one undefined. THANK YOU

!

[fra589]

You used the parameter $5=1, which means that you have normally closed limit switches.
Your Z limit switch seems to be triggered.
Either he is not normally closed, either you have another hardware problem.

[MarkEMark2]

Thank you. I am using Normally Closed switches. Therefore I will now look at the circuit board. Perhaps there is a short I missed somewhere. I just needed to make sure it was not something in the settings that I was changing and working with. I have tested the switches and the wiring to the board and it all checks out as proper and working. I have not gone to the board to test it yet. Thank you for the advice. I will let you know when I find the problem in case others have it as well.

[ccwtruck]

Thank you. I am using Normally Closed switches. Therefore I will now look at the circuit board. Perhaps there is a short I missed somewhere. I just needed to make sure it was not something in the settings that I was changing and working with. I have tested the switches and the wiring to the board and it all checks out as proper and working. I have not gone to the board to test it yet. Thank you for the advice. I will let you know when I find the problem in case others have it as well.

Please allow me to give you a little advice about limit switches, based on my own experience.

Ditch the mechanical switches -- they are too susceptible to noise & bounce; proximity switches run through a multi-relay opto-isolator board are much more reliable and fast acting. Basically, you run the "trigger wire" from each proximity switch to one input on the relay board. The relay side of the board is set up so that all "common" pins are connected to the Mega ground. Then, connect each "NO" pin from each relay to the corresponding Mega limit pin; if you are configured as a RAMPS board, then you can have both MIN and MAX switches on each axis that trigger individually (not in series or parallel).

The advantages to this configuration is that there is ZERO noise passed through to the Mega, the proximity switches have close to zero ms bounce, and you can have the reliability of NC switching outside the Mega while not having to go through the hoops of using a Grbl buffer board.