For some reason when I issue a G0 command for X or Y the motors seem to run at different speeds causing the gantry to go out of square. Now this is not the case when just using the jog buttons to move between .01mm to 100mm at a time. When I do this they move at equal speeds and stay square. I am using fuel endstops and run a homing sequence every time I start up the machine to make sure things are square.
I’m also using gbrl for the Rambo board and not Marlin if that helps at all.
While I do not run G0 codes much if at all I wonder if this is also causing my pocketing tool paths being off by as much as 1mm when trying to pocket out a hole. Any help would be greatly appreciated.
It is significant enough to not only see but to also cause the gantry to jam once it gets far enough out of square. When doing the Y G0 it didn’t jam but when I went to rehome it the y motors reached the limit switch a noticeable time apart. I would say a full second from each other.
I’m using openbuilds to issue the G0 and can try another software to see if it has the same issue.
Because I’m using gbrl all the feed rates are set within the firmware from how I understand it but I can take a look to see what I can find.
I will also try the push and pull but I would assume both motors are engaged considering they will still home just fine after.
On the lagging motor, check the grub screws between the stepper motor and the pulley. Next, check the micro-stepping. If the micro-steps are different between the two motors, then you would get the behavior you describe. Intermittent wiring issues are a distant possibility.
Grbl with dual endstops? Does that mean you’re on grbl mega 5x?
If so, double check the top of the config file for number of axes, number of linear axes, and axis names.
That caused some issues for me where everything would move nicely except when I homed, moved in inches, or sent an arc move. I wonder if the same mechanism is goofing up the g0?
Yes that is what I’m using but it was designed specifically for the Rambo board. You can find the thread on this forum.
It works perfectly fine for everything other than the G0 command. So I assume the code is accurate for the number of motors. Homing is no issue and it does it perfect. I can jog with no issues and I can do a continuous jog with no issues as well.
Yeah, that one, too. I had to change the number of linear axes.
Again, my problems weren’t related to G0 moves, though.
So then, AFAIK, grbl will send G0 moves at the max feedrate. In the sender console, type $$ and verify the max feedrates there. The order should be X, Y, Z, X2, Y2. X should=x2, y should=y2. May as well check the accelerations while you’re in there. For reference, mine were set to 5000mm/min, about 250 for acceleration.
If that isn’t it, go ahead and open the config and start looking for things that don’t make sense.
Here are the current settings that $$ brings up. I will attempt to look at the config file for anything that doesn’t look right but unfortunately I do not understand most of this code. I do write a lot of SQL and some basic code for my work but far from the complexity of this stuff. The area where X2 and Y2 would be do say unknown but the values are set correctly. Let me know what you think…
I assume that this part of the code refers to what you were talking about for the number of linear axes. I can certainly change the value from 3 to 5 if you think that may help.
// Axis array index values. Must start with 0 and be continuous. #ifdef DEFAULTS_RAMPS_BOARD
// 4, 5 & 6 axis support only for RAMPS 1.4 (for the moment :-)…) #define N_AXIS 5 // 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’
#if N_AXIS <3 #error “N_AXIS must be >= 3. N_AXIS < 3 is not implemented.” #endif #if N_AXIS > 3 #define AXIS_4 3 #define AXIS_4_NAME ‘X’ // Letter of axis number 4 #endif #if N_AXIS > 4 #define AXIS_5 4 #define AXIS_5_NAME ‘Y’ // Letter of axis number 5 #endif #if N_AXIS > 5 #define AXIS_6 5 #define AXIS_6_NAME ‘C’ // Letter of axis number 6 #endif #if N_AXIS > 6 #error “N_AXIS must be <= 6. N_AXIS > 6 is not implemented.” #endif
$133 and $134 are x2 max and y2 max. They need to match x and y or you can get wacky behavior. I’m surprised only the G0 moves are weird, so maybe that’s not it, but it’s easy to fix and check.
Just type into the console
$133=1100
$134=670
and pull $$ again to verify they took, then give it a test.
Like you pointed out, other folks are using this. Likely it only affects the inch mode and MAYBE the ijk, or perhaps only the combination…I forget. I wouldnt bother with that just yet.
I will set them to those values. Those from what I understand are my soft limit values so I do not crash my machine with a code that would go beyond my working area.
I also find it strange that the G0 commands have issues but jogging and homing have no issues at all. I have not really had any other issues with the machine other than having to increase my pocketing tool paths by a considerable amount to get things like dowels and other things to fit in those pockets. I tried Ryans recommendation of a small finishing pass and slowing my feed rate way down but I still have to increase some pockets by as much as .07 inches. I verified my steps per inch are accurate by using a v bit and plunging the tip into a piece of wood raising it and moving a set distance, plunging it back down and using calipers to measure between the two points and it is pretty much spot on within an acceptable margin of error. All my grub screws are tights and have thread locker on them as well.
There is a part of the code about arc tolerance and the value is set at 12 and was wondering if maybe that is what is causing my pockets to be inaccurate and maybe I should lower that value and see what happens.
The “unknown” is from your gxode sender. It doesn’t know what those are supposed to be because it isn’t vanilla grbl.
Grbl is kind of an old project, and as far as I know, not really being developed anymore. The programmer who wrote it for the uno moved on to other things, IIRC.
Grbl mega was an adaptation of grbl to utilize more pins and memory for more features, and some other stuff. Since it wasn’t written from scratch for 4+axes, they probably had to do some trickery to use the code that was already written for 3 axes. Think about taking a couple tables in sql, and needing to join them, but they don’t have any keys that can reference between them, but you know there is a third table (that also doesn’t have any unique keys) but shares a couple columns that you can reference for the other two. Sure, you can join them both to the third table and maybe it works, but maybe ALSO you duplicate a bunch of rows. If you figure it out you can try again, but if it only duplicates one row maybe you never find out until somebody stumbles across it.
So yeah, those ARE the sizes of the table, which would be referenced for soft limits, but that’s why x and x2 need to be the same (and y=y2). Doesn’t make sense for them to be different, and the calculations grbl is doing with the moves just might not be completing correctly.
I really don’t know enough about the modules in grbl (or classes or functions or whatever we call them) to say “this is happening”. Just enough to know that it COULD be the thing. Sorry I can’t be more certain.
Also, since you mentioned soft limits, i noticed your study and hard limits are both turned off ($20 and $21). Mine stay off because I had some issues with noisy switches, but after you get this all sorted you can choose whether to turn them on.
Also also, $140-$144 are the digipots for your drivers (x, y, z, x2, y2) and $150-$154 will be the ADDITIONAL distance each motor moves back from the endstops after homing (on top of the homing switch pull off, $27). These are the variables you’ll use to fine tune your squaring, like M666 in Marlin.
Those were never part of grbl, and i think added by jon and/or enducross (detailed in the thread you mentioned) so your sender didn’t know them either.
Pretty much all the other unknowns are just continuations of the xyz into x2 y2.
G0 in grbl always uses the max feedrate, which looks like 7200.
Can you try a G1 F7200 to see if that is any different?
If it is the same, you might just drop that max feedrate. You may be skipping steps or exceeding the step rate of the rambo. 7200mm/min is 120mm/s, and 12,000 steps per second (time two, for two axis). That might be close to the limit.
Seems to be a much bigger issue. Jogging and homing all my motors work just fine. But even running a job one will lag behind the other and seems to turn a lot slower. This is the case with both the Y and X motors.
I’m going to red lash the board tonight and see if that helps any. I will also save a copy of the default settings so I can go back to them in the future. I’m actually not even sure if all the motors are even turning actually. I tried turning the max feed rate down to 5000 but that didn’t help either.
Crossing my fingers that red lashing the board solves the problem.
When all else fails reflash the board. When I was changing the soft limits I must have done something. I flashed the board reset the eeprom and boom everything is back to normal. While I was in there I also changed the Linear axis to 5 and decreased the arc setting from 12 to 10.
So far so good. It was almost like one motor was turning and the other wasn’t but not when jogging and homing. I thought it was only a G0 command issue until I tried to run a job tonight and it did the same thing. So I flashed the board and reset everything back to the defaults and things seem good now. I’m sure I still have the accuracy issue with pocketing but that is an entire other issue.