[gnea/grbl-Mega Issue#11] Ramps 1.4

#9 – electrokean 于 2016-12-31

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)

#10 – MoonshineSG 于 2016-12-31

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…

#11 – chamnit 于 2016-12-31

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

#12 – jekhor 于 2017-01-01

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

#13 – MoonshineSG 于 2017-01-02

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

#14 – jekhor 于 2017-01-02

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…

#15 – MoonshineSG 于 2017-01-02

@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

#16 – jekhor 于 2017-01-03

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.

#17 – jekhor 于 2017-01-03

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.

#18 – chamnit 于 2017-01-03

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

#19 – MoonshineSG 于 2017-01-04

@jekhor I used your code with minor port changes, configured the DEFAULTDIRECTIONINVERTMASK and DEFAULTHOMINGDIRMASK 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 DEFAULTHOMINGPULLOFF > 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 DEFAULTSMKSGEN14
// Grbl generic default settings. Should work across different machines.
#define DEFAULTXSTEPSPERMM 40
#define DEFAULTYSTEPSPERMM 40
#define DEFAULTZSTEPSPERMM 200
#define DEFAULTXMAX_RATE 5000.0 // mm/min
#define DEFAULTYMAX_RATE 5000.0 // mm/min
#define DEFAULTZMAX_RATE 300.0 // mm/min
#define DEFAULTXACCELERATION (20.06060) // 106060 mm/min^2 = 10 mm/sec^2
#define DEFAULTYACCELERATION (20.06060) // 106060 mm/min^2 = 10 mm/sec^2
#define DEFAULTZACCELERATION (20.06060) // 106060 mm/min^2 = 10 mm/sec^2
#define DEFAULTXMAX_TRAVEL 210.0 // mm
#define DEFAULTYMAX_TRAVEL 210.0 // mm
#define DEFAULTZMAX_TRAVEL 100.0 // mm
#define DEFAULTSPINDLERPM_MAX 1000.0 // rpm
#define DEFAULTSPINDLERPM_MIN 0.0 // rpm
#define DEFAULTSTEPPULSE_MICROSECONDS 10
#define DEFAULTSTEPPINGINVERT_MASK 0
#define DEFAULTDIRECTIONINVERTMASK ((0<AXIS)|(1<STEPPERIDLELOCKTIME 254 // msec (0-254, 255 keeps steppers enabled)
#define DEFAULTSTATUSREPORT_MASK 1 // MPos enabled
#define DEFAULTJUNCTIONDEVIATION 0.01 // mm
#define DEFAULTARCTOLERANCE 0.002 // mm
#define DEFAULTREPORTINCHES 0 // false
#define DEFAULTINVERTST_ENABLE 0 // false
#define DEFAULTINVERTLIMIT_PINS 0 // invert X&Y limit switches
#define DEFAULTSOFTLIMIT_ENABLE 1 // false
#define DEFAULTHARDLIMIT_ENABLE 0 // false
#define DEFAULTINVERTPROBE_PIN 0 // false
#define DEFAULTLASERMODE 0 // false
#define DEFAULTHOMINGENABLE 1 // false
#define DEFAULTHOMINGDIRMASK ((1<AXIS)|(1<HOMINGFEED_RATE 100.0 // mm/min
#define DEFAULTHOMINGSEEK_RATE 1000.0 // mm/min
#define DEFAULTHOMINGDEBOUNCE_DELAY 250 // msec (0-65k)
#define DEFAULTHOMINGPULLOFF 0 // mm
#endif
“

#20 – jekhor 于 2017-01-04

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.

#21 – MoonshineSG 于 2017-01-04

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

#22 – jekhor 于 2017-01-04

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.

#23 – MoonshineSG 于 2017-01-04

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

#24 – MoonshineSG 于 2017-01-04

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

#25 – MoonshineSG 于 2017-01-06

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

#26 – Silly105 于 2017-01-12

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.

#27 – chamnit 于 2017-01-22

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

#28 – jekhor 于 2017-01-22

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.

#29 – langwadt 于 2017-01-22

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

#30 – docwelch 于 2017-06-26

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