GRBL running on Ramps

New Home Forum Software / Firmware Development GRBL running on Ramps

This topic contains 138 replies, has 28 voices, and was last updated by  Jeffeb3 3 weeks, 4 days ago.

Viewing 19 posts - 121 through 139 (of 139 total)
  • Author
    Posts
  • #110409

    Brett Le Roux
    Participant

    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?

     

    #110497

    Pablo Casaña
    Participant

    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. RAMPS-Shield-1.3-overzicht-connectors-1024x670

    1 user thanked author for this post.
    #110521

    Brett Le Roux
    Participant

    Hi Pablo, thanks for coming back.

    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.

     

     

    #110589

    Pablo Casaña
    Participant

    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.

     

    #110641

    Ryan
    Participant

    Stupid question, but how do you install this code on a mega 2560? This does not appear to be arduino code.

    #110717

    Ryan
    Participant

    Ok, I figured out how to install it. Now I need to figure out the homing switches. It seems it needs to home before it will send gcode.

    #110729

    Jeffeb3
    Participant

    You can send a reset or unlock command to let it move without homing. I think it’s reset and it’s one of the $ commands.

    #110754

    Ryan
    Participant

    Hi Jeff,

    When I try to run gcode I get this error. I’m guessing the soft limit is related to homing.

     

     

    MSG:Caution: Unlocked]
    ok
    > ;Ramp5 (line=7)
    error:20 (Unsupported command)
    ALARM:2 (Soft limit)
    [MSG:Reset to continue]
    >

    #110756

    Ryan
    Participant

    OK, I turned off the soft limit with $20=0.

    It attempts to run the gcode but doesn’t like some commands.

    client> $X
    ok
    > $20=0
    ok
    > ;Ramp5 (line=7)
    error:20 (Unsupported command)

    The gcode was generated in Fusion360 with the MPCNC marlin post processor. I guess marlin uses commands that GRBL doesn’t understand.

     

     

     

     

    #110775

    Ryan
    Participant

    What fusion 360 post processor is recommended for the 5 axis ramps board?

    #110796

    Jeffeb3
    Participant

    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).

    #110797

    thomas downing
    Participant

     

    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.

    #110816

    Brett Le Roux
    Participant

    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

    (X-MIN: pin D3
    X-MAX: pin D2
    Y-MIN: pin D14
    Y-MAX: pin D15)

    and the modified allocation in this branch

    (X-MIN: pin D3
    X-MAX: pin D14
    Y-MIN: pin D57
    Y-MAX: pin D58)

    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.

     

     

    #110817

    Brett Le Roux
    Participant

    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.

    #110818

    Brett Le Roux
    Participant

    @ Thomas Flashing this Grbl branch onto the Mega2560 is not too complicated. There is a good guide here: https://alexpgh.github.io/foss-toolchain-mpcnc/zoom_1/

    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.

    #110879

    Pablo Casaña
    Participant

    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

    (X-MIN: pin D3

    X-MAX: pin D2

    Y-MIN: pin D14

    Y-MAX: pin D15)

    and the modified allocation in this branch

    (X-MIN: pin D3

    X-MAX: pin D14

    Y-MIN: pin D57

    Y-MAX: pin D58)

    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.

    Hi Brett, thankyou for your work. If all works well, could you upload your MPCNC version to the John’s Github file?

    Also you have to modify the wiring scheme.

    #111133

    Brett Le Roux
    Participant

    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

    (X-MIN: pin D3

    X-MAX: pin D2

    Y-MIN: pin D14

    Y-MAX: pin D15)

    and the modified allocation in this branch

    (X-MIN: pin D3

    X-MAX: pin D14

    Y-MIN: pin D57

    Y-MAX: pin D58)

    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.

    Hi Brett, thankyou for your work. If all works well, could you upload your MPCNC version to the John’s Github file?

    Also you have to modify the wiring scheme.

    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.

    #111136

    Pablo Casaña
    Participant

    @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.

    #111138

    Jeffeb3
    Participant

    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.

Viewing 19 posts - 121 through 139 (of 139 total)

You must be logged in to reply to this topic.