Ramps 1.4

[Gummibaer]

Please add Support for Ramps 1.4.

[MoonshineSG]

after one month no reply... Ramps support would be great.

[chamnit]

@MoonshineSG : No need to be snarky. This thread starts with a statement. Not a question. I've also answered the question of adding RAMPs several times on Grbl's main site. Right now, I have no plans to add RAMPs support. It's very low on my priority to do list but it's on there. That's why this issue is still open.

[Gummibaer]

Thx for response.

[MoonshineSG]

Didn't meant to offend anyone but I couldn't find any reference to do more reading. Sad to see that there's no intention to supper this in the near future. It actually compiles ok and the firmware can be uploaded (on an MKS Gen v1.4 which is ramps compatible) just the pin definition is wrong...

Again, apologies.

[chamnit]

@MoonshineSG : I welcome any help with adding RAMPs support and making sure it's well tested. Right now I'm busy with the ARM version, which is significantly more important than supporting old hardware.

[MoonshineSG]

It may well be old, but it is very popular and like it or not, here to stay... I am doing some reading and it seams like indeed the pin is the main /only issue and smarter people than me have tried to tackle it... I haven't seen a solution yet although slightly older versions of grbl work on ramps (see grblForCyclone)

[chamnit]

@MoonshineSG : Then it should be easy to find someone to help and submit a pull request! I don't have a RAMPs board to test with and don't have the time to open that can of worms. Please try to understand that the future ARM version is a millions times more important.

[MoonshineSG]

@chamnit : I am attempting to do a conversion of the pins to ramps, but I am more of high level programming kinda guy... Microprocessors are strange beats ...

If you have time maybe once in a while a question... stating with a probably stupid one:

In the CPU_MAP there are some pin definitions like :

#define STEP_DDR      DDRA
#define STEP_PORT     PORTA
#define STEP_PIN      PINA
#define X_STEP_BIT    2 // MEGA2560 Digital Pin 24
#define Y_STEP_BIT    3 // MEGA2560 Digital Pin 25
#define Z_STEP_BIT    4 // MEGA2560 Digital Pin 26
#define STEP_MASK ((1<<X_STEP_BIT)|(1<<Y_STEP_BIT)|(1<<Z_STEP_BIT)) // All step bits

While others, like "COOLANTMIST", "COOLANTFLOOD" or "SPINDLEPWM" definitions, do not contain PIN. The STEP_PIN doesn't seams to be used anywhere in the rest of the codes...

What am i missing ?

[electrokean]

Yeah, STEP_PIN doesn't appear to be used. Typically the PINA hardware register is for reading the pin inputs (and PORTA is used for writing), so it probably was defined there just in case but never got used.

Porting to RAMPS hardware requires some rather complex changes due to the fact that the STEP and DIR pins for the Z axis are on PORTL, and X an Y axis are on PORTF. grbl code expects all STEP pins on the same port, and all DIR on the same port. This change will impact maximum step rate, especially if you want to drive more than the 3 axes for extruders.

I suggest you begin by looking at one of the older grbl ports for RAMPS, something like https://github.com/CarlosGS/grblForCyclone Although this implementation may not be the best speed wise, it isn't too hard to follow In particular look at https://github.com/CarlosGS/grblForCyclone/blob/grblForCyclone/stepper.c https://github.com/CarlosGS/grblForCyclone/blob/grblForCyclone/ramps.h Note that the definitions in cpu_map.h for RAMPS are towards the end, and use Arduino pin numbering (rather than the hardware registers, and thus a bit slow)

[MoonshineSG]

Thanks. I did more reading about arduino pins and came to the same conclusion. The PIN is there so the definition is complete although not used.

As for porting, I will not follow Cyclone but using a different approach. Once I have smth working I'll post it for "review"... It will take me a while but so far managed to separate the 3 axes and put them on the right pins...

[chamnit]

@MoonshineSG : Thanks for looking into this. Grbl places all of the stepper pins (+ limit and control input pins) on a single port so it can set them in one go. I think RAMPs has them all over the place, on different ports. The path of least resistance and recommended way to do this without having to change much is to setup the port masks for each axis in the stepper ISR routine. So at the start of the main stepper ISR, you just write the port masks.

[jekhor]

Hi. I am working for this also and will show my first approach soon, in one-two days.

[MoonshineSG]

@jekhor glad to hear there's someone else working on it, coz I am stuck. The limits seams to be too much for me.

[jekhor]

After some digging: RAMPS sucks. It's more easy to drop it into waste bin than create good-looking and fast code for it because this board was created by Arduino funs who don't know anything about speed and optimal code. I still intend to complete grbl port to it without of big perfomance impact, but it may look terrible...

[MoonshineSG]

@jekhor, from what I understand, RAMPS was build with hardware and less with software optimisation in mind. That being said, and not know much about other firmwares, Marlin runs pretty well on the board.

Porting grbl to RAMPS has it's challenges because grbl was build to run on less powerful boards, where every bit counts and work around those "restrictions" proves to be a little complicated (especially if not fully familiar with how grbl works) I'm sure that it would be simple for the original developer, but sadly there are other priorities.

I've temporarily gave up, but intend to relook into it when I get some more time. In the meantime, if anyone else does the porting I'd be glad to do testing :D

[jekhor]

I have got grbl-Mega running on K40 CO2 lasercutter with RAMPS controller. Commit is here: https://github.com/minsk-hackerspace/lasercutter-grbl-Mega-RAMPS/commit/94a7df3054ff023d7fca33de03ddc97901b59591 I just converted any pin masks to per-axis masks, without changing of logic (except of limits).

It contains some configuration changes specific for our hardware (including of PWM frequency and pin mapping) but code is generic. Hardware limits are disabled in code, RAMPS uses 5 interrupts (4 INTx and one PCINT) for 6 limit input pins, it is hard to make generic implementation for such pinout, and we don't need hardware limits support.

[jekhor]

I observe that grbl on my RAMPS hangs at hi-speed movements (near of 25000 mm/min, which requires 32.5 kHz step signals) and still not checked if this is hardware or software issue.

[chamnit]

@jekhor : The max step frequency for Grbl is 30kHz. Above this, Grbl will start to become unstable, because the interrupts begin to use the majority of the available CPU cycles.

[MoonshineSG]

@jekhor I used your code with minor port changes, configured the DEFAULT_DIRECTION_INVERT_MASK and DEFAULT_HOMING_DIR_MASK to match my config. I use a 3D printer converted (temporarily) to CNC and my 0,0 is at left lower corner, limit switches at min positions.

It woks ok, with only 2 problems: if I set DEFAULT_HOMING_PULLOFF > 0, homing it fails with Alarm Code 8 so I changed that to 0. Then when performing homing, it does a reset :(

Any ideas ?

if it helps...

#ifdef DEFAULTS_MKS_GEN_1_4
  // Grbl generic default settings. Should work across different machines.
  #define DEFAULT_X_STEPS_PER_MM 40
  #define DEFAULT_Y_STEPS_PER_MM 40
  #define DEFAULT_Z_STEPS_PER_MM 200
  #define DEFAULT_X_MAX_RATE 5000.0 // mm/min
  #define DEFAULT_Y_MAX_RATE 5000.0 // mm/min
  #define DEFAULT_Z_MAX_RATE 300.0 // mm/min
  #define DEFAULT_X_ACCELERATION (20.0*60*60) // 10*60*60 mm/min^2 = 10 mm/sec^2
  #define DEFAULT_Y_ACCELERATION (20.0*60*60) // 10*60*60 mm/min^2 = 10 mm/sec^2
  #define DEFAULT_Z_ACCELERATION (20.0*60*60) // 10*60*60 mm/min^2 = 10 mm/sec^2
  #define DEFAULT_X_MAX_TRAVEL 210.0 // mm
  #define DEFAULT_Y_MAX_TRAVEL 210.0 // mm
  #define DEFAULT_Z_MAX_TRAVEL 100.0 // mm
  #define DEFAULT_SPINDLE_RPM_MAX 1000.0 // rpm
  #define DEFAULT_SPINDLE_RPM_MIN 0.0 // rpm
  #define DEFAULT_STEP_PULSE_MICROSECONDS 10
  #define DEFAULT_STEPPING_INVERT_MASK 0
  #define DEFAULT_DIRECTION_INVERT_MASK ((0<<X_AXIS)|(1<<Y_AXIS))
  #define DEFAULT_STEPPER_IDLE_LOCK_TIME 254 // msec (0-254, 255 keeps steppers enabled)
  #define DEFAULT_STATUS_REPORT_MASK 1 // MPos enabled
  #define DEFAULT_JUNCTION_DEVIATION 0.01 // mm
  #define DEFAULT_ARC_TOLERANCE 0.002 // mm
  #define DEFAULT_REPORT_INCHES 0 // false
  #define DEFAULT_INVERT_ST_ENABLE 0 // false
  #define DEFAULT_INVERT_LIMIT_PINS 0 // invert X&Y limit switches
  #define DEFAULT_SOFT_LIMIT_ENABLE 1 // false
  #define DEFAULT_HARD_LIMIT_ENABLE 0  // false
  #define DEFAULT_INVERT_PROBE_PIN 0 // false
  #define DEFAULT_LASER_MODE 0 // false
  #define DEFAULT_HOMING_ENABLE 1  // false
  #define DEFAULT_HOMING_DIR_MASK ((1<<X_AXIS)|(1<<Y_AXIS))
  #define DEFAULT_HOMING_FEED_RATE 100.0 // mm/min
  #define DEFAULT_HOMING_SEEK_RATE 1000.0 // mm/min
  #define DEFAULT_HOMING_DEBOUNCE_DELAY 250 // msec (0-65k)
  #define DEFAULT_HOMING_PULLOFF 0 // mm
#endif

[jekhor]

Check limit switches invert parameters. RAMPS has separated signals for max and min limit switches. If you have switches which connect signal to ground, you don't need to do anything and comment out INVERT_{MAX,MIN}_PIN_MASK in grbl/config.h (they are not zero for my setup). If you use normally-closed switches, set corresponding bits here. And check that $5=0.

[MoonshineSG]

@jekhor that helped a bit.. Now it homes and then resets. If it's at 0,0 and you home, it freezes... Haven't had enough time to run full test, but I guess it's almost alright...

[jekhor]

Hmm... I observed similar behaviour but cannot remember how I fixed this. Maybe it was eliminated after soldering 0,1uF capacitor between limit switch signal and ground, maybe after increasing of homing pull-off distance... In any case, reset without any error/alarm message is not planned behaviour of grbl.

[MoonshineSG]

increasing the pull off (to 3) seams to have helped...

[MoonshineSG]

can grbl be configured so that it allows Z to move up even if it was not homed? I don't have an endstop on Z, only a probe, and currently it only allows to move down (z-), so whatever the height is when grbl starts is the 0 and no way to move the head up

[MoonshineSG]

my above question has been self answered. only achievable by (minor) code change

[Silly105]

This thread took an interesting turn. :) I recently got RAMPS 1.4 hardware as an upgrade for my lasercutter, planning to use Marlin firmware. Then I discovered the actual grbl version with its laser mode. Now I am thinking of staying with grbl, and if thats possible with RAMPS hardware, I would be very happy.

I will give @jekhor s code a try, but probably not before next week.

[chamnit]

@jekhor : I was told by some LaserWeb folks that your Grbl-Mega repo works with RAMPs. I looked at your code, and it looks great! Do you have any time to make it work with the standard build? Maybe a macro to control the build type? I'd like to integrate it into the main repo. Thanks!

[jekhor]

I didn't plan to develop it further but if there is chance to be integrated into upstream – I will try to do this :) Maybe in February.

[langwadt]

if setting and clearing stepper pins in stepper.c was a macro, you could put that macro in the cpu_map.h so the hardware specifics are all in one place

[docwelch]

@jekhor : I have taken your code changes and made them more "generic" for the Ramps 1.4 board. I also changed the spindle to work on digital pin 8 as this has a 12v output that can be PWM controlled. I see others are using Ramps boards (with Marlin firmware) to control laser diode modules. Most of the time they are using D9 but I chose D8 as it has a heat sink on the MOSFET whereas D9 does not. I have done some bench testing and everything seems to be in working order.
Your last message in January indicated you might try to make these changes as @chamnit had requested. I have a current need to use a Ramps board with GRBL so I figured incorporating your changes was a great place to start. I certainly do not want to take credit for your superb work but would offer to submit my changes based on your work as a pull request if you would not be offended.

[chamnit]

@docwelch : Sure. Submit a pull request and I'll take a look. If it works out, I'll add it. Thanks for taking the initiative and sharing!

[docwelch]

Pull request has been submitted.

[jekhor]

@docwelch I don't have time for preparing my code for upstream unfortunately, so feel free to do this and use my code as you like :)

We used RAMPS-compatibe board, not RAMPS itself for lasercutter in our hackerspace, so pin selection was based on this.

[chamnit]

@docwelch : Thanks for the pull request. I'll review likely tonight.

@jekhor : No problem. I do like how you abstracted the pin configuration. I'm pulling in some of your concepts into the next major Grbl version. Thanks for sharing. In the meantime, we'll get this Mega version updated with some cpu mappings that will be RAMPS compatible.

[urishab]

Thanks for the RAMPS support. I also opened another issue but perhaps the right thing was to add the info here so I'll copy-paste it here as well.

Z-Enable pin on RAMPS 1.4 collides with CONTROL_RESET pin

I'm trying to run the GRBL-Mega firmware on a RAMPS 1.4 compatible board. X and Y are running well but Z does not.

I've found both Z-Enable PIN and CONTROL_RESET PIN are set to the same PIN: PK0 (digital 62 I think) and this prevents the Z from working.

If I change the CONTROL_RESET pin to PK1 the Z axis works. I'm guessing that I missed something that's supposed to disable the CONTROL_RESET, am I right?

In any case it seems that whatever it is, the pin should be disabled in RAMPS configuration

[sergioausrio]

How to wire Limit Switches and Probe Wire on Ramps 1.4 ? I have normally open Switches on X-Min and Y-Min and a Croco-Clamp on Z-Min (all on Signal & Ground) but it doesnt works for me. Any special Settings in config.h?

[tkurbad]

@sergioausrio It took me a while to figure it out, but what you need to do is basically enable the following two INVERT_..._LIMIT_PIN_MASK defines in config.h:

#ifdef DEFAULTS_RAMPS_BOARD
  // Only enable the following line if you have - (min) limit switches attached
  #define INVERT_MIN_LIMIT_PIN_MASK ((1<<X_AXIS) | (1<<Y_AXIS) | (1<<Z_AXIS))
  // Only enable the following line if you have + (max) limit switches attached
  #define INVERT_MAX_LIMIT_PIN_MASK ((1<<X_AXIS) | (1<<Y_AXIS) | (1<<Z_AXIS))  
#endif

Wire your (normally open) limit switches between signal pin and GND and set the limit pins as inverted in the configuration, too by doing a:

$5=1

on the serial terminal.

If you now set the status bits to include the limit switches, e.g.:

$10=16

you can will see sth. like

Pn:X

if you hold an X limit switch closed. (And, of course, Y and/or Z, if the respective switches are being closed)

Good luck, Torsten

[tkurbad]

@sergioausrio Forget what I wrote. You just have to connect your (NO) endstop switches as they are supposed to being connected to the Ramps board. Since homing in grbl is done towards the max limit switch, you have to connect your switches to Xmax, Ymax, and Zmax accordingly. Also, make sure you set up your machine right (using the "right hand rule"). Also, if possible, employ the recommended RC circuit to minimize interference. In addition, if you inverted one or more of your axis directions via $3, you have to use the ...min endstop connector for homing those particular axes.

Note, however, that a.t.m. the switches only seem to work for homing, since the hardware limit switch functionality is disabled in the code for Ramps. I.e., once homed, I can drive machine well beyond the limit switches without triggering an alarm. I use software limits at the moment to circumvent this. However, since Ramps does support 2 endstop switches per axis, it would be nice to be able to use them as hardware limit switches...

@docwelch Are you planning to implement the hardware limit feature for Ramps eventually? If not, can you tell me what needs to be done to get it running, basically?

[docwelch]

@tkurbad I am not really planning on any further changes due to the fact this is a temporary fix. @chamnit is working on a better solution (HAL) so time spent extending the current solution does not seem reasonable for me. I am using software limits like you are and have not had any issues so far. I suspect you could get the end stops to work as limit switches, but I have not really thought about all the details needed to make this work. I suspect the main issue would come down to how the switches are mapped to the ports. If they are on separate ports, it will be more difficult than if they are all on the same port. If you decide to pursue this, I wish you the best.

[tkurbad]

@docwelch A HAL solution sounds promising. Thank you for the info. Do you know if there's a rough ETA for this?

[chamnit]

@tkurbad : The HAL draft is complete, but still unpublished. It'll be released when it's ready, and I can't say when that will be. I've been slammed at work and can't give you a time table.

[DarkAlchy]

Earlier today I almost had a fire as I uploaded the sketch over Marlin and within 15 seconds my hotend was smoking (probably the PTFE tube in the throat) and it had no fan going. I had to dig through a lot of different pages to finally get enough information to see that coolant is always on which correlates to D10 which is my hotend. Must have gotten over 290c or even 300c before I pulled the 24v power supply out of the wall (the heatsink was bloody hot with no fan running over it).

Is there no place with any instructions on what does what for the Ramps pin outs with this firmware? FWIW most Ramps have no mosfet heatsinks (my first ramps burned up and I replaced my fets with good IRF ones that do not even get warm now after a 20h print) and we Marlin people do use D9 for our fans which runs our lasers.

[109JB]

You misunderstand the purpose of ramps with Grbl. It is not so that Grbl can run 3D printers so much as it is for people with 3D cutting machines (mills, routers, etc) can use a ramps board for the interface to their machines. Grbl has a very limited set of commands, and doesn't include many commands that the 3D printer world has used. It also doesn't have PID for hot end

These are the supported codes in Grbl. You will not the limited nature and the many missing 3D printer specific codes.:

G0, G1: Linear Motions G2, G3: Arc and Helical Motions G4: Dwell G10 L2, G10 L20: Set Work Coordinate Offsets G17, G18, G19: Plane Selection G20, G21: Units G28, G30: Go to Pre-Defined Position G28.1, G30.1: Set Pre-Defined Position G38.2: Probing G38.3, G38.4, G38.5: Probing G40: Cutter Radius Compensation Modes OFF (Only) G43.1, G49: Dynamic Tool Length Offsets G53: Move in Absolute Coordinates G54, G55, G56, G57, G58, G59: Work Coordinate Systems G61: Path Control Modes G80: Motion Mode Cancel G90, G91: Distance Modes G91.1: Arc IJK Distance Modes G92: Coordinate Offset G92.1: Clear Coordinate System Offsets G93, G94: Feedrate Modes M0, M2, M30: Program Pause and End M3, M4, M5: Spindle Control M7 , M8, M9: Coolant Control M56 : Parking Motion Override Control

[DarkAlchy]

Right, I understand that what I do not understand is where is the documentation on what pins on the Ramps get hooked up where? I never once thought D8 would be always on before I even ran anything.

All I want to know is how to hook up my laser to which port and my endstops are hooked up where endstops go on a Ramps so those can stay put but I will remove the heated bed, and the nozzle leaving everything else where it is and having D8/9/10 vacant where the laser will surely go. Not having anyway to know what goes where for this grbl fork with a Ramps is what caused the issue. I hope no one else thinks to just leave their 3d printer stuff hooked up and burns down their house. My thought was I am not using it so it will be safe to leave them hooked up and when I need my 3d printer again I would just flash Marlin back.

[cgimark]

You can save yourself a lot of grief by just getting a cheap ebay nano clone with laser support for about $20. If you just want to use your current ramps and mega and not use the grbl code here you can look at the program http://estlcam.com/, it has firmware that you can flash and use right away with no changes, trial is free with no limitations and no time limit. From what I could tell estlcam uses a simple control program on the board and the pc is doing all the calculations and just sending stepping data over usb. So the board isn't running grbl or marlin. I don't use it because I need wireless connectivity and also the cnc to work stand alone from a pc.

[DarkAlchy]

I wonder how it performs compared to Marlin? I currently use Marlin but it lacks a whole lot due to it being for a 3d printer not a laser setup. I have never heard of a nano clone coming with laser support before.

[chamnit]

In theory, estlcam shouldn't work any better, because the main limitation of speed is the step interrupt overhead on the AVR processor. Both Grbl and Estlcam are limited by this. However, Grbl does perform very well when compared to firmwares on faster ARM processors.

The pin configuration for RAMPS mode is in the cpu_map.h file after the #ifdef CPU_MAP_2560_RAMPS_BOARD. The comments show that pin D9 and D10 are mist coolant pins.

[DarkAlchy]

Well, grbl looks like it will perform much better than Marlin on the same hardware as I have been digging through the code and see a lot of optimization (this same optimization makes this Arduino coding newb befuddled some) but there is something I am trying to find and couldn't and that is why D10 is full on from the get go (meaning as soon as I uploaded the sketch)? In my case it almost caused a fire, or at least a melt down, of my hotend so is there any way I can disable the coolants (D10/D9) that are disabled from the first upload so they never come on?

[chamnit]

@DarkAlchy : Yes. You can invert the coolant pins by uncomment the #define INVERT_COOLANT_FLOOD_PIN and #define INVERT_COOLANT_MIST_PIN lines in config.h file. Make sure you are editing the file that was copied into your Arduino library folder.

BTW, coolant pins are low by default. If they are high, that means that you might not be running the RAMPS version of Grbl-Mega. D10 is high only if the default pin configuration is active and using that pin as a limit pin. To alter Grbl to run on RAMPS, you'll need to alter the lines //#define DEFAULTS_RAMPS_BOARD //#define CPU_MAP_2560_RAMPS_BOARD at the top of the config.h file.

[DarkAlchy]

@chamnit Thank you so much and when I finally had a minute I started digging into all of this and hit config.h first and noticed the ramps define because I had not touched anything before and just uploaded it as it was which means I was on the generic definition. Btw, on the ramps version there are a lot of redefines causing warnings and I am unsure if anyone knows about that.

Oh, and I noticed a lot of defines for steps etc... in another file that I changed to fit my config (like X/Y=80 means a 20t gear and I use 16t so those needed to be 100 instead). I think I am about ready to reupload it I just wanted a way to turn off the coolant lines but if the ramps is already active low then I shouldn't have any issues since nothing I would do would turn those on.