48”x60” LR3 dual endstops
SKR pro1.2 TFT 35
Controller and all hardware from V1 shop.
Makita 700
Single flute (from V1) first and only endmill I’ve used
Dewalt shop vac for DC
Running files from SD card in screen
I recently built this machine. Had it up and running for a few weeks. Been successfully cutting 3/4 plywood. Successfully cut the attached file yesterday. Attempted to cut the same file this evening and that’s when the issue arose. Seem to have lost x steps, leading to misaligned cuts. Skipping seems to happen at the far right(rail side). Once the ‘skip’ happened, it continued to run normally (although misaligned) until I stopped it.
No other tools were running in the shop during this cut. Mini fridge was the only other thing using power
Pictures of where the lost steps seem to have happened:
I’m planning to run it again in the morning, on the same work piece (to hopefully not waste another costly sheet of birch ply) and see what happens. I’ll record it with a camera.
There are a number of things that can cause lost steps, so tracking down the issue can be difficult. Given the single large movement (instead of multiple small movements), my first suspect would be a loose grub screws on the pulley for the X axis. Beyond that, look for any way the X axis could bind or rub. The only way I’ve seen a g-code file cause lost steps is when the feedrate is too fast for the cutting conditions.
Thanks Robert, I pulled the core off the morning and check the x pulley grub screws the flat spot on was nice and tight. The second one was a touch loose but nothing major.
The second one was a touch loose but nothing major.
I’m not a Lowrider owner, but it is my understanding there is only one stepper motor for the X axis, so there should only be one pulley.
There are a number of reasons for lost steps. I experienced some, and I’ve read about many more on the forum. Most of them result in a more gradual loss rather than a single big loss like I see in your cut. One reason that can result in a big shift is the stepper driver shutting down due to overheating. If you left your current settings at the V1 defaults, then this should not be an issue, but if you adjusted the current to the steppers…
I get a shift like yours when bit hits something like a clamp. Early on I played with pushing the feedrate and would get major shifts if I pushed things too far. I have no sense for whether your 900mm/min is a reasonable feedrate for a Lowrider in your material at whatever DOC you are using.
Sorry I should have been more clear, the second grub screw is what I was referring to.
I haven’t changed any current settings. Could it be possible that some else in the shop is causing a surge. Like a fridge cutting in, or some kind of interference from my shop vac?
It is remotely possible you have a weak power supply or a sudden loss of power to the router (making it more difficult to cut material), but it would have to be a very specific scenario. You did not lose steps in the Y or Z directions. Your electronics did not shut down. It would take a significant loss of RPM that would be easily heard to cause additional stress on the router. I wouldn’t pursue interference until you’ve ruled out other things.
I think it may be an issue with my z2 stepper. When powered up, and core on the far #2 side, the gantry will drop. Should it not be supported by the steppers and hold its position?
Edit: upon further testing, it seems none of the steppers are engaged with the machine powered up. When I homed x (with the #2 side propped up) the #1 side dropped at the core came over to the left
The steppers are engaged the first time you move them. For example, if at startup, you first move in the X direction, but not Y or Z, the Y and Z steppers will not be engaged. You can explicitly engage steppers with an M17 g-code. There is an autostart feature in Marlin you could use to run a g-code file from the SD card to engage the steppers when the electronics are turned on. I don’t know if it will work if your display is not in Marlin mode.
Based on reading forum posts, most of the Z dropping/weakness problems on the Lowrider are traced to two sources. First is mechanical associated with alignment and lubing of the lead screws. The second is using the second Z plug on the Z stepper driver for the Z1 stepper motor rather than the E1 stepper driver.
Interesting problem. If the z axis was dropping in the middle of the job then I would expect both x and y to start skipping steps. However, this issue only affects the x stepper when the core is close to the maximum x limit. Are the x axis stepper wires fully extended at this point? I would check the connections on the x axis wires and possibly use additional zip ties to prevent the x axis connectors from being pulled.
Another thing I noticed, when I home Z, only the #1 side moved up. The #2 side only moves down as if it hit the end stop when it hasn’t. But when I move the axis, both move
I usually run a few test jobs with the z axis origin set so that the endmill is always above the material. With only a sd card you could generate gcode where the final pass is about 10mm above the material.
My rig has a heavy router and I need to crank up the amps on the z axis drivers to the max otherwise one of the z axis motors will start skipping steps when the core is at xmin or xmax. Then you need additional cooling to prevent the drivers from overheating.
But based on what you describe it looks like a wiring issue. I would check the z2 endstop and x axis motor connections.
I’m trying to decipher the following gcode, it looks like the z axis is moved to -12 then there’s a y move. But then z goes down 4mm and the feed rate changes to 900. The feedrate set here applies to subsequent moves that omit this parameter. Then it draws an arc (one of the corners presumably)
Are you sure you want the feedrate to be 900 before cutting an arc? And is it cutting 4mm material at this point? Something looks a odd with the gcode.
Looking at the gcode file, Marlin is likely getting confused regarding feedrates. In particular, given the flow of this gcode, you are attempting to move the Z axis at 900mm/min. This often results in lost steps, and usually those lost steps occur when the gcode is attempting to lift the router. These lost steps mean that you will end up with a deeper depth of cut, making more difficult to move in the X and Y directions.
The fix is to have Estlcam generate federate parameters for every G0 and G1 command. I don’t use Estlcam, so I’ll refer you to Dan’s answer here.
I’m not 100% certain your cutting issue is caused by the federate issue I’ve outlined, but regardless, you need to change the settings, since it is a serious issue.
Just a thought but have you tried cutting slower to say 480mm min to see if it’s ok? When I had z issues I lubed the screws and put heatsinks on the motors and it worked fine. While testing I was losing x steps and it was the wiring.
