BTW, I’m guessing that one of the moves in the “Line + Fill” is using G0 (rapid movement) and one is using G1, but why the rapid movement is so much more rapid, I have no idea…
C
In grbl, G0 is always at one speed (travel speed). I wouldn’t trust cncjs to use the max speed. I would test like this:
G1 X100 F2000
G1 X5 F2000
That F is mm/min.
2 Likes
@johnboiles this is awesome thank you !
I wish I had read this post before I started digging into Marlin spindle/laser code. I was not aware of this dual endstops version of grbl. Dual endstops is a must have for me and I thought I was locked with Marlin.
Looking forward to testing your version of grbl !
I created a pull request as suggested by @enducross to set the correct PWM pin in cpu_map.h.
By the way, do you have a reference for pin mapping in grbl ? I can’t figure out how to convert a known pin to the values you need to put in cpu_map.h.
Edit : to understand pin mapping, see https://github.com/fra589/grbl-Mega-5X/wiki/Pinout-mapping-in-cpu_map.h
1 Like
@johnboiles - Just saw this posting. I have a Mega2560 with a RAMPS-Plus v1.6 riding it. This will be interesting to try. The board has, for the most part, the same pinout as the other RAMPS boards but with a few minor pin changes. From your description, this package will be in demand as it fleshes out and matures. Thank you for starting the effort.
Followup. Github gave me the base version, not the marked up version. I used the RAMPS-updated version. After finding out any changed assignments with the RAMPS-1.6-PLUS board, the unit is up and running. I went and added a Z-max limit switch to the core to make homing more proper as this is normal for a regular CNC mill - home to the top and work down. Z touch off is working just fine. Next step is to get some pink foam and do squares to check for squareness of operation.
1 Like
Got everything uploaded, with the Grbl for Rambo code but when I try to use UGCS to just move the axes i get jog target exceeds machine travel. It’s set to the defaults and I am using 1mm steps so I would think a 1mm movement should not exceed anything. Where can I start to debug this?
Do you need to unlock or home the machine before it will accept movement commands?
Did you set the bed size for all 5 axes? I think I remember setting 1,2, and 3 (x, y, z) and getting the same error. Had to go back in and set 4 and 5 (x2, y2)
Or it might have been the steps per mm on 4/5. Maybe just run through everything and make sure 4/5 = 1/2
Thanks Tom, yes I can unlock, set home, reset, etc and get the message. Since I don’t have end stops I disabled the soft limit but I still get a message. Interesting. I’ll need to dig in a little more.
Thanks Tony. I set to 3 axis since I don’t have end stops (I think that’s what they’re for??) I’ll poke around and see if I can make it with with 4/5 x2/y2.
If the motors are in series, that’s probably right. If they each have their own driver, definitely set up 4 and 5.
Definitely in series, hm. I’m confused since I disabled the soft limit and still get the soft limit error message. I guess I’ll need to experiment some more.
I’m down to asking if you set the bed size and steps/mm. If it’s giving an error, I want to think it’s something in the $$settings. But I can’t see anything else that would do it.
Thanks,
I set everything in config.h/defaults.h if there’s another step I missed it!
Is there anything I might need to change here?
defaults.h says
#ifdef DEFAULTS_RAMPS_BOARD
#define DEFAULT_AXIS1_STEPS_PER_UNIT 100
#define DEFAULT_AXIS2_STEPS_PER_UNIT 100
#define DEFAULT_AXIS3_STEPS_PER_UNIT 400
#define DEFAULT_AXIS1_MAX_RATE 7200.0 // 9000 mm/min = 9000/60 = 150 mm/sec
#define DEFAULT_AXIS2_MAX_RATE 7200.0 // 9000 mm/min = 9000/60 = 150 mm/sec
#define DEFAULT_AXIS3_MAX_RATE 400.0 // 300 mm/min = 300/60 = 5 mm/sec
#define DEFAULT_AXIS1_ACCELERATION (400.06060) // 3006060 mm/min^2 = 300 mm/sec^2
#define DEFAULT_AXIS2_ACCELERATION (400.06060) // 3006060 mm/min^2 = 300 mm/sec^2
#define DEFAULT_AXIS3_ACCELERATION (200.06060) // 1006060 mm/min^2 = 100 mm/sec^2
#define DEFAULT_AXIS1_MAX_TRAVEL 600.0 // mm
#define DEFAULT_AXIS2_MAX_TRAVEL 600.0 // mm
#define DEFAULT_AXIS3_MAX_TRAVEL 120.0 // mm
#ifdef DEFAULTS_RAMPS_BOARD
// 4, 5 & 6 axis support only for RAMPS 1.4 (for the moment :-)…)
#define N_AXIS 3 // Number of axes
#define N_AXIS_LINEAR 3 // Number of linears axis
#else
#define N_AXIS 3 // Number of axes = 3 if not DEFAULTS_RAMPS_BOARD
#endif
#define AXIS_1 0 // Axis indexing value. Must start with 0 and be continuous.
#define AXIS_1_NAME ‘X’ // Axis names must be in X, Y, Z, A, B, C, U, V & W.
#define AXIS_2 1
#define AXIS_2_NAME ‘Y’
#define AXIS_3 2
#define AXIS_3_NAME ‘Z’
1 Like
Looks good to me
@johnboiles - I did find an issue. Using Ramps-updated. So far all functions work as they should for dual-x/dual-y. The only one that doesn’t work is G2/G3. Calling either one makes the gantry twist. X1 goes right and X2 goes left rather than tracking the same direction. Any ideas where to look?
Both your motors are turning the same direction. One of them needs to turn opposite so that the whole axis moves the same direction. Flip the connector on the motor that is going the wrong direction.
The machine functions as it is as I am making work on it. G0/G1 are operating correctly as wired and programmed. It appears that the sign of the command coming out of G2/G3 going to each stepper is not following the requested convention in the setup. The problem can be fixed in code but deciphering grbl and its signal flow process is not easy to say the least. Once I get that figured out, the rest will be a cakewalk.
There was an issue I had some issues moving in inches with arcs a while ago. Linked a thread in post 124 up above that deals with some ijk weirdness. Have a look there and see if it sheds any light on your problem.