Hi all. Thanks for all the work on this branch. I have it installed on my CNC (although not a MPCNC) as I needed auto-squaring on my dual Y axis.
Everything works well (homing, squaring etc) but I discovered that the hard limits don’t trigger. I have set $21=1 but when my CNC hits the limits it just keeps going (an unwanted result). I have checked the state of the switches via the status info and all are triggering as expected. I then did a dive into the code and discovered this def in cpu_map.h:
#define DISABLE_HW_LIMITS
I tracked that down and discovered it effectively disables the hard limit logic in limit.c
When I comment it out, the code won’t compile and gives the error “HW limits are not implemented”. I assume this is there deliberately.
So, is there a reason the hard limits have been disabled or am I doing something wrong? Is this feature just waiting for development or is it not possible in this version of GRBL?
Hi, searching in GRBL wiki, hard limits function works with Max limit pins, because they say " If you want a limit for both ends of travel of one axes, just wire in two switches in parallel with the pin and ground, so if either one of them trips, it triggers the hard limit." if this function would works with Xmin and Xmax they wouldn´t say that, so try to connect your switches to Xmax and Ymax limit pins.
Looking for max limit pins in cpu_map.h I found :
#define MAX_LIMIT_BIT_0 3 // X Limit Max - Pin D57 #define MAX_LIMIT_BIT_1 4 // Y Limit Max - Pin D58 #define MAX_LIMIT_BIT_2 2 // Z Limit Max - Pin D19
D57 and D58 are in Aux-1 ( A3, A4), but I don´t know where is D19 in Ramps. [attachment file=110498]
I started taking a deeper dive into the code last night to see how it works.
I’ve got my limit switches set up as NC, so in that case it would be to place them in series.
But as it is, all switches are showing as up as triggered in the status when I test them individually, so it not a wiring/config issue as they are being correctly detected in the limits_get_state method in limits.c.
So I believe the actual problem is that there is an issue with how the interrupts/ports have been configured in the GRBL code. I think in the original version, the interrupts may only have be configured on the max pins hence the reason for “doubling up” the switches on these pins. I will investigate further and see if I can change the logic. I think the tricky part is that the interrupt should only be enabled after homing has been concluded otherwise it will fire off a system halt every time you try home. This may already be catered for, I ran out of time with my initial glance at the code.
Hi Brett, I think you’re right, if you put them in parallel it will interrupt in each homing. The solution you comment escapes my knowledge, anyway I think the really useful thing is to use the maximum limits per axis, if you do homing the machining should not move beyond zero. If you set correctly your cam program you won´t have any problem.
I don’t use 360. It looks like it’s not happy with the ‘:’ as a commenr character.grbl prefers comments to be wrapped in parenthesis (this is a comment).
I would really like to run grbl but don’t know the first thing about flashing it on a marlin ramps 1.4 so i’m gonna stick with it plus i can’t find and good post processors for mpcnc marlin its kinda got me frustrated a little my machine works but it dosen’t do the operations as shown in fusion 360 the look more like this and i don’t know why.
So managed to get the hardlimits working. Had to tweak the code a bit in cpu_map.h and limits.c.
Fortunately it did not affect the homing cycle as disabling of hard limits during homing was already taken care of.
The biggest issue is that the original limit pins
did not support the PCInt (Pin Change Interrupt) feature on the Mega. I remapped these pins to
X-MIN: pin D53
X-MAX: pin D51
Y-MIN: pin D52
Y-MAX: pin D50
all of which are on AUX3 and not being used in this application. These are all part of PORT B (if I recall correctly) and are on the same interrupt vector (PCINT0) which is a requirement. I made up a small adapter to that I wouldn’t have to change my 2-pin dupont plugs coming from each of the switches. So now I have a machine which stops when the limit are reached (both min and max limits)
This approach also means I don’t have to run the switches in series/parallel which also allowed me to extend the reporting a bit for debug purposes so I can see exactly which switch is triggering/faulty if needed. Only problem with this was it messed a bit with CNC.js’ console window so I had to disable it once I had debugged the mechanical bugs I had created.
I tested with Fusion 360. I used the Grbl/grbl post processor for generating the G-Code and it worked fine (uploading it to CNC.js)
FYI: Homing command is $H. $X is unlock but it messes with soft limits if you have not homed the machine properly first.
Note you must copy it into the libraries folder of the Arduino application once you have modified the files as described. Then open the grblUpload.ino file in Arduino and burn (after setting the target board to the Mega2560 family). The RAMPS 1.4 board is just a “HAT”, so the burning is rather aimed at the Mega board and not the RAMPS itself.
Will do. I’m just running full tests to ensure all is fine and also have to clean the code up a bit as I left markers through the code where I tweaked so I could go back to them. Also a bit embarrassed to admit that I have never pushed code back into Github. Use TFS for code change tracking, so it might take a bit of quick research to see how to do it without messing up the entire repo.
@brettlx maybe you could send your definitive code to @johnboiles, and he could upload it to his github file like a new or improved release. I think it is the easy way to do it. Because I haven’t uploaded anything to github either XD.
Github can be dainting at first, but it really is a great way to organize code changes, even if you don’t share them. It’s a worthwhile skill to have if you’re spending some time editing text files.
Hi Brett can you tell me what parameters have you changed in limits.c? I´m creating a new fork in Github to upload all the changes only for RAMPS boards. But before I publish it I have to know all the changes you have done.
