Move your router up or down measuring the physical distance. If the electronic measurement is the same as the physical measurement, then this is not a driver setting issue.
1 Like
I’ll confirm this tomorrow (my machine is at work).
Does it look like it climbs up to positive 15 before going 2mm under where you set zero?
And yes, the rambo is a4498 drivers and they max at 16 microsteps. You can test that easily by jogging 10mm, and making sure it moves 10mm
2 Likes
The store says the RAMBO has 1/16th microstepping so I think the steps/mm is correct.
I notice the first two Z axis moves in the gcode have no feed speed specified, and the Z axis limit in the settings is set to 400mm/min. This feed speed is more than twice as fast as Ryan recommends starting with. You might try changing the $112 Z axis maximum rate to 200 or a little less (Ryan recommends starting at 180).
It may be missing steps right at the start when it tries to go to Z15.24. This is what @ttraband was thinking. It doesn’t necessarily make any sound when it skips steps.
1 Like
I’m not certain, but it might. I’ll pay attention to that tomorrow.
I’ll add that to the list of things to look at tomorrow. My gantry is probably on the heavy side, so that makes sense.
I run Marlin, not GRBL, so you can take my observations with a grain of salt. First, your Z movements are way too fast for a ‘standard’ T8-8 lead screw with drivers set at 16 microsteps . This may be handled if you have set more appropriate feedrates limits in firmware. The firmware that V1 ships with its boards and provides on github has a default Z feedrate max of 900 mm/min, and this is too fast. You will lose steps at that speed, especially if cutting at that speed. The g-code above has a Z feedrate for downward motion of 762mm/min which is likely too fast (especially when cutting), but I see place where the Z upward feedrate is 1524. Again this assumes that GRBL g-code operates like Marlin g-code where the last feedrate seen applies to all axes.
The second issue, is that there is nothing in this code that sets the current position at the start of the script to Z=0. On marlin this would mean that if you were electronically at Z=5 when the script was started (even thought the bit was at the home position), then all of the cutting would be 5mm too deep.
The last potential thing I see to look at is the G54. I’m assuming when the machine starts, GRBL is in G53 (global) workspace. I don’t know how the offset for the G54 is set, and if that offset is persistent in any way. Again I’m sure there are GRBL vs. Marlin differences here.
Alright, I blew a fuse and had to wait for new ones to come in, but I finally got to test it.
I reduced the z-axis speed to 180 (are there recommendations for the other axis too?) and made sure that 10mm in the gcode sender was 10mm on the machine. I tried to surface the spoil board and got some stair-stepping (guess I need to figure out how to level the gantry), but it seemed that it worked as expected as far as depth goes.
I did try setting up homing as I finally got my limit switches installed. It didn’t work, but I did notice that if my x-axis is on a side, the gantry will twist. My guess is there’s too much weight on the gantry? I’m trying to figure out of there’s a way to solve that. I’m about ready to just slam my head into my desk and start over.
Hey! I’ve been digging through the config file and trying to learn what I can about settings. It seems that with grbl, it will never go faster than the max feedrates defined in the $$ settings. grbl uses mm/min so I have 7200 for X and Y and 800 for Z. Ryan gave those settings in this post but he may have been talking about the MPCNC, not the Lowrider. Do you know if there are recommended max speed settings for the lowrider?
I’m not certain how grbl treats feed rate in the gcode, so I can’t say anything about that.
With grbl, I position the spindle where zero is and set a workpiece zero. I don’t think there needs to be anything in the gcode to handle that. How I start a job is:
Place spindle in safe space > G28.1 > Move spindle to top of the workpiece (I don’t have the probe working yet) > Zero workspace Z > Increase Z height > move the spindle to edge of workpiece > zero workspace X and Y > start job.
It seems to work OK except for the Z going too low.
I tried flashing Ryan’s Marlin onto my RAMBo and my Z axis was performing much better from what I could tell by jogging the machine (I was having trouble getting a job to run). It seemed like the motors were running cooler as well. What would be going on to make that happen? Could my current be too high and the motors aren’t preforming properly because of that? I’m a bit lost and confused with all this, so I appreciate all the help!
So are you still having trouble with your router going too low? As mentioned before, I don’t own a LowRider and I’ve never used GRBL, so my information comes from the MPCNC experience and reading on the forum.
I just took a look at the latest V1 Marlin firmware for the LowRider. Current to the motors is set for the Rambo board in this line in Configuration_adv.h:
#define DIGIPOT_MOTOR_CURRENT { 138, 138, 138, 138, 138 }
This 138 value is the same as is used on the MPCNC, and sets the drivers to about 0.8A. So you can compare that 0.8A value to whatever value the GRBL is setting the drivers. I know nothing about the GRBL firmware, so I don’t know where to tell you to look for the current settings.
The most prevalent reason I’ve seen for lost Z steps for the LowRider on this form for the Rambo board is that it is wired wrong. Typically both Z steppers are plugged into the two provided Z plug slots on the Rambo board (assuming dual wiring where each stepper has its own driver). The second Z stepper needs to be plugged into the second extruder plug.
Your Rapids still sound too high to me. I’m assuming that a LowRider uses the same lead screw for both Z axes that the MPCNC uses for its Z axis. In his EstlCAM setup section, he recommends 2100mm/min for XY movements, but only 480mm/min for Z.
If you are running Marlin firmware, you can set this limit by running the following g-code once (the change will be presistent):
M203 Z8 ; Limit feedrate to 8mm/s (480mm/min) M500 ; Save the changes to EEPROM
I cannot help but think we are missing something. It shouldn’t be this hard to figure out what is going on.
1 Like
Woah, that’s actually super helpful! The current settings in my firmware is 135, so I’m going to bump it up a bit and see if that helps.
Since I’m trying to run Dual Endstops (eventually) I have each motor plugged into it’s own driver. So it goes (from left to right) X1 > Y1 > Z > empty > Z2 > Y2.
I’ll try those rapid settings, that may be what I’m missing (I couldn’t find them anywhere!).
I’ll report back tomorrow evening after I’ve tried this stuff. Thanks a bunch @robertbu!
If this is really how you have your machine wired, then you’ve have a problem. Your Z2 and Y2 need to be swapped. The wiring according to this chart:
…pulled from this page, says Y2 gets the first extruder slot, and Z2 gets the second extruder slot.
1 Like
Yeah, I did see that chart. Because grbl doesn’t have official Ryan support I had to go in and edit the firmware myself. So I just made the headers whatever I wanted. I can change it to match the chart if it helps people out.
You have enough uncommon choices here that it may be difficult for the forum with its narrow communication line, to figure out the problem. Maybe the place to start is to do a standard V1 install of Marlin including his wiring choices and see what happens. If it works, then you’ve pretty much identified the problem as something you’ve done in GRBL and the people on the list that know GRBL can help you track it down. If the problem persists, then we can begin looking at the software pipeline and hardware issues to track the problem down.
You might want to try looking into your acceleration settings for your Z axis. It would be $122. It may skip steps and not lift the Z high enough at the start of your run. Then when the commands come in to lower the Z, since gravity is working with the move, it works fine, but since it started lower, it plunges lower.
Now I don’t have a lowrider, but my Primo Z acceleration is set to 10mm/sec2. So $122=10.
Edit: Ach, nevermind. Just plugged your settings in and works fine, even pushing down on the Z during an up move.
I actually did end up flashing marlin to see if it would work for me. I got everything installed and I could jog the machine around, but I kept getting a weird error in the gcode sender. That being said, I used the wiring from the chart and edited the grbl firmware, so it should be what is expected.
I made the changes you listed above (motor current to 138, 2100mm/min for XY and 480mm/min for Z) and it seems like it’s working! I ran a surfacing operation and aside from some stair-stepping (which may be due to the dust brushes, I’ll look into that in a bit), it seems like it took the right cut and didn’t do anything weird!
@robertbu what uncommon choices did I make? This is my first time delving into anything CNC, so I don’t really know what I’m doing. I’d like to know for next time so it’s a smoother process!
@Strider_Matic I’m really new to all of this (if it wasn’t too obvious 
and that was a good tip! I went through and checked all my settings in $$ and I had missed some. I also pulled up the config.h file from the normal grbl v1.1 and it seems like a lot of stuff was edited out. I imagine it’s not needed since the machine runs, but are there any other settings I should double check and make certain of?
Thanks for all the help you guys, I’m finally starting to see some progress with this machine!
2 Likes
GRBL is used by a tiny minority of MPCNC users, so if the issue was rooted in GRBL few on this list would have the experience to help you. The swapped wiring was also a bit of a surprise, and it made me wonder what other choices you made we were not seeing. I’m a big believer in starting from a simple working solution and evolving to get to where I want.
I’m really glad you seem to have this sorted. Good luck, and I look forward to seeing things you’ve made on the list.
1 Like
As far as editing the grbl config.h file goes, I had to enable the variable speed spindle and additional enable pin settings, but I’m using an Arduino/CNC shield, and the V1 PID speed control, so I am even further down yet another low-occupancy branch of “what’s most popular” here on the forums. I puttered around with homing sequences, but once I realized my problem was due to noise on the switch lines I put it all back the way it started.
Once steps-per-mm is properly dialed in, the interrelated variables/tunable elements remaining in the motion control arena are motor current, velocity, and acceleration. Looks like you’ve identified which of these was the primary contributor to your issue but it might be helpful for further tuning to understand how they interrelate.
(Feel free to consider the rest here TL;DR)
Too little current and you don’t have the power to make the moves you want, too much current and drivers and motors get hotter than they should and the drivers start to cut out, which may present as vibration. On my 3D printer this presented as moire patterns in the plastic extrusions. Nothing stopped moving, but the motion was no longer smooth. Options here are to lower the current or add cooling (fans) to the drivers and possibly the motors.
Too high a velocity setting and you lose steps on long runs (where you actually get up to full speed) because stepper torque drops as velocity increases. Too high acceleration and you lose steps on all moves as the current provided to the motor isn’t adequate for the forces required to make the commanded move.
Current is tuned based on the amperage the motors can handle using the motor and driver specification sheets. Some controllers support “digi-pots” that can be set via software/firmware, others have physical pots that get tweaked. Once current is set, I’ve found it most useful to tune acceleration next by picking a very conservative velocity setting, then increasing the acceleration setting until steps are skipped, then backing the setting off 5-10% for a safety margin. With a known good acceleration setting you can then increase velocity settings until steps are lost and then back that off 5-10%. I’ve used this approach on 5 different machines and get very reliable motion control. I don’t worry about losing steps under most circumstances.
2 Likes
@jeffeb3 Is there a place I can put up a tutorial for getting grbl running on the lowrider? Might be a good resource for crazy people like me.
We don’t have any grbl in the docs. I think it is better that way for now. I would say a clean forum post in #software:grbl makes the most sense.
1 Like