Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ramps 1.4 #11

Open
Gummibaer opened this issue Nov 30, 2016 · 76 comments
Open

Ramps 1.4 #11

Gummibaer opened this issue Nov 30, 2016 · 76 comments

Comments

@Gummibaer
Copy link

@Gummibaer Gummibaer commented Nov 30, 2016

Please add Support for Ramps 1.4.

@MoonshineSG

This comment has been minimized.

Copy link

@MoonshineSG MoonshineSG commented Dec 27, 2016

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

@chamnit

This comment has been minimized.

Copy link

@chamnit chamnit commented Dec 27, 2016

@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

This comment has been minimized.

Copy link
Author

@Gummibaer Gummibaer commented Dec 27, 2016

Thx for response.

@MoonshineSG

This comment has been minimized.

Copy link

@MoonshineSG MoonshineSG commented Dec 27, 2016

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

This comment has been minimized.

Copy link

@chamnit chamnit commented Dec 27, 2016

@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

This comment has been minimized.

Copy link

@MoonshineSG MoonshineSG commented Dec 27, 2016

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

This comment has been minimized.

Copy link

@chamnit chamnit commented Dec 27, 2016

@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

This comment has been minimized.

Copy link

@MoonshineSG MoonshineSG commented Dec 31, 2016

@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 "COOLANT_MIST_", "COOLANT_FLOOD_" or "SPINDLE_PWM_" 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

This comment has been minimized.

Copy link

@electrokean electrokean commented Dec 31, 2016

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

This comment has been minimized.

Copy link

@MoonshineSG MoonshineSG commented Dec 31, 2016

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

This comment has been minimized.

Copy link

@chamnit chamnit commented Dec 31, 2016

@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

This comment has been minimized.

Copy link

@jekhor jekhor commented Jan 1, 2017

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

@MoonshineSG

This comment has been minimized.

Copy link

@MoonshineSG MoonshineSG commented Jan 2, 2017

@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

This comment has been minimized.

Copy link

@jekhor jekhor commented Jan 2, 2017

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

This comment has been minimized.

Copy link

@MoonshineSG MoonshineSG commented Jan 2, 2017

@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

This comment has been minimized.

Copy link

@jekhor jekhor commented Jan 3, 2017

I have got grbl-Mega running on K40 CO2 lasercutter with RAMPS controller. Commit is here: minsk-hackerspace@94a7df3
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

This comment has been minimized.

Copy link

@jekhor jekhor commented Jan 3, 2017

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

This comment has been minimized.

Copy link

@chamnit chamnit commented Jan 3, 2017

@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

This comment has been minimized.

Copy link

@MoonshineSG MoonshineSG commented Jan 4, 2017

@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

This comment has been minimized.

Copy link

@jekhor jekhor commented Jan 4, 2017

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

This comment has been minimized.

Copy link

@MoonshineSG MoonshineSG commented Jan 4, 2017

@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

This comment has been minimized.

Copy link

@jekhor jekhor commented Jan 4, 2017

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

This comment has been minimized.

Copy link

@MoonshineSG MoonshineSG commented Jan 4, 2017

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

@MoonshineSG

This comment has been minimized.

Copy link

@MoonshineSG MoonshineSG commented Jan 4, 2017

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

This comment has been minimized.

Copy link

@MoonshineSG MoonshineSG commented Jan 6, 2017

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

@Silly105

This comment has been minimized.

Copy link

@Silly105 Silly105 commented Jan 12, 2017

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

This comment has been minimized.

Copy link

@chamnit chamnit commented Jan 22, 2017

@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

This comment has been minimized.

Copy link

@jekhor jekhor commented Jan 22, 2017

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

This comment has been minimized.

Copy link

@langwadt langwadt commented Jan 22, 2017

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

This comment has been minimized.

Copy link

@docwelch docwelch commented Jun 26, 2017

@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

This comment has been minimized.

Copy link

@chamnit chamnit commented Oct 9, 2017

@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

This comment has been minimized.

Copy link

@DarkAlchy DarkAlchy commented Oct 9, 2017

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

@chamnit

This comment has been minimized.

Copy link

@chamnit chamnit commented Oct 9, 2017

@DarkAlchy : I just tried it with the Arduino IDE uploading. It worked with no errors or warnings. Make sure that you don't have any other grbl source code in your library and the Mega2560 is selected as your board type in the IDE Tools menu.

Also comment the two lines about the RAMPS configuration lines, just as the instructions say.

@DarkAlchy

This comment has been minimized.

Copy link

@DarkAlchy DarkAlchy commented Oct 10, 2017

@chamnit I have a question and that is I have my define.h setup and my config.h has my ramps uncommented and the other two commented and when I do a $$ I am getting back the generic defaults. What I tried was just having the ramps defaults in the file with no ifs in it just hard defines and still $$ had the generic defaults. Is this a bug or am I doing something wrong?

@chamnit

This comment has been minimized.

Copy link

@chamnit chamnit commented Oct 10, 2017

@DarkAlchy : While Marlin is a fork of Grbl, it doesn't handle the EEPROM the same. Grbl has hard defaults only when the EEPROM needs to be wiped (there is a bug that fails to detect fresh installs that won't be fixed due to several good reasons). You can issue a $RST=* command to Grbl to wipe and restore EEPROM to defaults manually.

@DarkAlchy

This comment has been minimized.

Copy link

@DarkAlchy DarkAlchy commented Oct 10, 2017

Thank you as I was trying $RST= nut it was an unknown command and $ came back with a few command but $RST was not listed.

@chamnit

This comment has been minimized.

Copy link

@chamnit chamnit commented Oct 10, 2017

Please read the wiki pages. It's all listed and explained there. You are missing an asterisk.

@DarkAlchy

This comment has been minimized.

Copy link

@DarkAlchy DarkAlchy commented Oct 11, 2017

Just to let you know this thing works a treat and is lightning fast. USB 250k connection. Marlin over USB maxes out around 50mm/s and SD card about 80-90mm/s but this beast I max out around 16k-18k mm/min over USB and if it had SD card abilities I bet I could get even faster. So, around 300mm/s using everything the same. That is a HUGE increase in speed which means I can use my laser more at full power (full spectrum range without it burning). I am very pleased to say the least. I use 3k acceleration in Marlin but with this about 5k though I haven't had a chance to really tweak yet either because at 300mm/s my machine is throwing stuff off of my table it is going so fast (a wobbly card playing like table you see at fairs and exhibitions etc...).

@chamnit

This comment has been minimized.

Copy link

@chamnit chamnit commented Oct 11, 2017

Good to hear. Don’t forget to try the dynamic laser mode via the M4 command when laser mode is enabled. It’ll make crisper burns with less over burning in corners.

@DarkAlchy

This comment has been minimized.

Copy link

@DarkAlchy DarkAlchy commented Oct 13, 2017

@chamnit Have any idea why in my defaults I have X,Y acceleration set to 3000 and Z to 100 but when I do a $RST=* it sets 120/121/122 = 0.838??? I have to go in and hard set them for some odd reason but everything else in my defaults.h gets ported over just fine. Acts like it is doing some sort of calculation on its own and ignoring my defaults.h file.

@chamnit

This comment has been minimized.

Copy link

@chamnit chamnit commented Oct 13, 2017

Please look at the other defaults. There should be a /(60.0*60.0) in each entry.

@DarkAlchy

This comment has been minimized.

Copy link

@DarkAlchy DarkAlchy commented Oct 13, 2017

@chamnit Take this line DEFAULT_X_ACCELERATION that only appears in two files DEFAULT.h and SETTINGS.c and in the settings it is only one line which is settings.acceleration[X_AXIS] = DEFAULT_X_ACCELERATION;

What you are saying is that I need to multiply those values from X to X*3600 to get the real value I am after?

@chamnit

This comment has been minimized.

Copy link

@chamnit chamnit commented Oct 14, 2017

What I’m saying is that look at the comments next to the acceleration defaults in the default.h file. It spells it out completely and clearly.

@DarkAlchy

This comment has been minimized.

Copy link

@DarkAlchy DarkAlchy commented Oct 14, 2017

@chamnit Ahhh, I went straight to the Ramps section as that is the only part of the define I cared about and that is not there.

#define DEFAULT_X_MAX_RATE 18000.0 // mm/min
#define DEFAULT_Y_MAX_RATE 18000.0 // mm/min
#define DEFAULT_Z_MAX_RATE 300.0 // mm/min
#define DEFAULT_X_ACCELERATION 3000
#define DEFAULT_Y_ACCELERATION 3000
#define DEFAULT_Z_ACCELERATION 100
#define DEFAULT_X_MAX_TRAVEL 200.0 // mm
#define DEFAULT_Y_MAX_TRAVEL 200.0 // mm
#define DEFAULT_Z_MAX_TRAVEL 200.0 // mm

Notice the missing comments for that in that section.

@bigshug

This comment has been minimized.

Copy link

@bigshug bigshug commented Apr 1, 2018

" I also changed the spindle to work on digital pin 8 as this has a 12v output that can be PWM controlled"

So are you using PIN 8 for 12v PWM? Can it be used for 0-5v PWM?

@luisluna2

This comment has been minimized.

Copy link

@luisluna2 luisluna2 commented May 3, 2018

Hello friends, one question: How can SWAP the ZAXIS motor to YAXIS motor?

I try change pins in cpu_map.h but when I change the pins it does not work any axis, I wanna change the motor for have 2 Conetors Y and 1 Conestor for Z.

Thank you for your coments and help!

@chamnit

This comment has been minimized.

Copy link

@chamnit chamnit commented May 3, 2018

@luisluna2 : Please stop hijacking unrelated issues threads with your questions and posting multiple times. This is at least the third one I've found this morning. Posting multiple places wastes a lot of people's time. Post in one place in a new thread and wait patiently for an answer.

@luisluna2

This comment has been minimized.

Copy link

@luisluna2 luisluna2 commented May 3, 2018

@chamnit so sorry my friend, I do not want to bother, I just wanted to know how to do it. Thank you very much, it will not happen again.

@rasciodc

This comment has been minimized.

Copy link

@rasciodc rasciodc commented May 28, 2018

I was very surprised to see a 2560 version of GRBL and even more when I crossed with this issue to use the RAMPS board...

Is there any news on this topic? I saw some developments going on and just would like to know what is the status on it. Tks!

@DarkAlchy

This comment has been minimized.

Copy link

@DarkAlchy DarkAlchy commented May 28, 2018

@rasciodc It works as GRBL without issue but if you are meaning will GRBL work as a 3d printer controller that will never happen I think.

@rasciodc

This comment has been minimized.

Copy link

@rasciodc rasciodc commented May 28, 2018

Thanks for the quick reply.

I'm intending to use it as mill, not 3D printer...

Is there an easy way to clone Y (or X) axis to the E0 or E1 axis on Ramps via code? I was able to do that on the GrblForCyclone but it wasn't an optimal implementation...

@spikedrba

This comment has been minimized.

Copy link

@spikedrba spikedrba commented May 31, 2018

hi, wondering why this issue is still open... as far as I can see a pull request to add RAMP 1.4 support was accepted a year+ ago and as far as my preliminary testing goes it's all working (altho still fighting with some issues).

did I miss anything? should I expect some kind of problem going down this route?

and thanks to @chamnit @jekhor and @docwelch for making this possible! 👍

@dennishatton

This comment has been minimized.

Copy link

@dennishatton dennishatton commented Jun 18, 2018

I'm using ramps 1.4 with N.O. limit switches
I can't get them to cause an alarm in bcnc or gcodesender
If check status with a terminal program, I can see pn:x or y or z when I trip micro switches

I have un commented in config.h
//#define DEFAULTS_RAMPS_BOARD //#define CPU_MAP_2560_RAMPS_BOARD

@dennishatton

This comment has been minimized.

Copy link

@dennishatton dennishatton commented Jun 20, 2018

Is there a problem with pin change interrupts for ramps?
They are commented out
When I put them back in It won't compile

@tkurbad

This comment has been minimized.

Copy link

@tkurbad tkurbad commented Jun 20, 2018

@dennishatton, as I had to realize earlier in this issue's discussion, hardware limit switches for ramps a.t.m. only work for homing. During operation you have to use soft limits, which works for me. One of the problems is that the ramps board supports separate upper/lower limit switches, while grbl a.t.m. only supports one limit switch (connection) per axis. To support limits for ramps would require lots of code changes within the grbl code itself as far as I was able to deduce.

@chamnit is apparently working on a HAL solution for grbl, which isn't ready for release yet. If this is done, it will be much easier to implement all kinds of stuff for different hardware - so we ramps (or in my case Azteeg X3) owners have to stay tuned...

@dennishatton

This comment has been minimized.

Copy link

@dennishatton dennishatton commented Jun 21, 2018

Ok, thanks

@rasciodc

This comment has been minimized.

Copy link

@rasciodc rasciodc commented Jul 2, 2018

Have anyone tried to clone X, Y or Z axis on motors E0 or E1? I've put some hours on it but was unsuccessful.... It would be great if anyone could point me to the right direction...

Apperently it should only require to have the bits being written to [X,Y or Z] axis to be applied on the [E0 or E1] Port on the stepper.c file but I think I'm missing something else....

Thanks!

@garyebersole

This comment has been minimized.

Copy link

@garyebersole garyebersole commented Oct 5, 2018

I have been trying to get grbl-Mega to run on a Mini-Rambo 1.3a board which is an Arduino Mega 2560 with on-board support for RAMPS 1.4. My goal is to replace the Marlin controller that came with the LowRider2 CNC (derived from the MPCNC design) with real CNC software. I modified the config.h file as noted earlier and flashed the Mini-Rambo. Using Universal Gcode Sender (Platform version), I am able to connect to the controller (the 'Grbl.1.1g' header is printed) but the '$$' and '$G' commands are not executed.

As a test, I flashed the grbl-Mega-5X fork from @fra589. It actually worked with no changes logging the header as well as the results from the '$$' and the '$G' commands. Unfortunately, it threw an alarm ('Safety door detected as opened and door state initiated.') which blocks further interaction with the controller.

I'm either missing other obvious basic settings, configuration variables and defaults that must be set to work or there are code changes that @fra589 made as he added the support for additional axes. Any thoughts to what I might need to do to make progress?

Thanks. I use grbl on a desktop CNC and really hope I can get it working on the big CNC I am building.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.