Running into an unfortunate issue - my Maslow 4.1 (firmware v1.16) seems to have lost the z axis home/calibration mid cut. I have it set up to travel between cuts 2mm above the z-home height. For about an hour of cutting this worked perfectly.
All of a sudden, the bit began dragging about 1/4” deep when traveling between cuts. It looks like the cuts themselves are also about 1/4” deeper than where they should be. I verified that the bit did not slip. The Z axis is moving up and down, just seems to have a constant offset of 1/4” lower than it should be all of a sudden.
Has anyone run into this? Anyone have advice on how to avoid it going forward? Better yet - is there a way to pause the cut and adjust the z-home without having to restart it from the beginning?
Potentially unrelated, but I also noticed that the x/y and z adjust step sizes are spontaneously all set to random (very small) values despite being set to sensible values at the beginning of the cut.
Running into an unfortunate issue - my Maslow 4.1 (firmware v1.16) seems to
have lost the z axis home/calibration mid cut. I have it set up to travel
between cuts 2mm above the z-home height. For about an hour of cutting this
worked perfectly.
All of a sudden, the bit began dragging about 1/4” deep when traveling between
cuts. It looks like the cuts themselves are also about 1/4” deeper than where
they should be. I verified that the bit did not slip. The Z axis is moving up
and down, just seems to have a constant offset of 1/4” lower than it should be
all of a sudden.
Has anyone run into this? Anyone have advice on how to avoid it going forward?
Better yet - is there a way to pause the cut and adjust the z-home without
having to restart it from the beginning?
usually when this happens, it means the bit has slipped. It is possible that if
the belts are too tight (bad anchor point locations, or you didn’t set the
workpiece thickness after calibration) the steppers are losing steps as you move
up.
Potentially unrelated, but I also noticed that the x/y and z adjust step sizes
are spontaneously all set to random (very small) values despite being set to
sensible values at the beginning of the cut.
this sounds like switching from mm to inch, if you multiply those values by 25.4
do they become the sensible values?
The downside of stepper motors is that they can lose steps, but there is always the option to drive them with more power. Bumping these up will give the motors more power to not skip steps, with the tradeoff that they will run hotter:
You will want to change them for motor0 and motor1 (since there are two motors on the z-axis).
There isn’t a way to reset the z-axis home while paused. You could pause and manually rotate the stepper motors to basically force them to skip some steps in the opposite direction, but that feels pretty yucky.
The best option is probably to stop it and then manually edit out the part of the gcode that you don’t want. Gcode files are pretty easy to edit by hand. Generally there is some stuff at the top that you want to keep which has information like is the file in inches or mm and then it’s all G1 and G2 commands for moves. A smart move is to look for G0 commands with a change in the Z value to indicate where the z-axis goes up and down to find the start and end of cuts
Doing some more troubleshooting it’s definitely missing Z steps - I marked where I put the bit and it’s in exactly the same spot after it starts dragging. I re-ran calibration and got a better fitness value (and what looks like better accuracy) but still skipping z-steps. Work piece thickness is set accurately. I did notice that sawdust seems to be accumulating in the z axis stepper screws and making its way down into the motors. I might look into modifying the dust shield to try to capture this dust before it causes problems.
I did find another obvious thing to fix - sometime between assembly and now the large capacitor on the power supply seems to have cracked off due to vibration. Going to take a stab at re-soldering that and see if that resolves any of the issues.
@bar any tips on setting safe but maximal thresholds for run_amps and hold_amps? At 1.0/0.5 the motors feel cold to the touch during operation in my 40 degree winter workspace. I have no idea what the board/motors can support safely though.
In terms of adjusting settings mid-cut, I do think long term something like the “tune” menu on Creality 3d printers would be useful to adjust feed rates and z-offset on the fly as needed. That said, for now I think a decent workaround will be to break larger cuts up into smaller gcode files and adjust the z-axis as needed in between. I might also look into adding a z limit switch and regularly tapping that between passes to re-calibrate the z axis but I suspect the software changes for that might be a little complex.
I dealt with Z issues a bit with the linear rail build I did. First point I’d make is until it’s resolved - make sure to re-set Z-stop every until you resolve it - the distance from Z-stop is important for belt lengths and can exacerbate problems.
If you have it happening with no bit, I’d re-seat the motors on the sled (loosen the screws with Z all the way down then retighten, and check that the nut isn’t binding (you might need to loosen the screws for the nut and see if it feels freer hand turning).
The Z-steppers are being worked pretty hard with the Maslow4 design, so anything you can do to lower frictional losses can make a difference between losing steps and not.
And interesting experiment that’s just occured to me is - with the Maslow on the bench, you could try lowering the Z max current and see how much or little you need to drop it before you lose steps.
No idea if it’s a good idea, but it could be interesting.
I haven’t explored it too much. I bumped mine up to 1.3A for run and I think .75 for hold and didn’t have any issues there. If your workspace is pretty cool like that we should have a decent amount of overhead to bump up the current
After installing a new power capacitor I ran this test. Results were:
Depending on Z axis position, Z steppers stopped moving below 0.4A-0.5A max current
Bottom and top of the Z axis seemed to be the stickiest spots with the bottom being especially sticky. This is interesting to me since I seem to be losing steps only once the Z axis starts cutting deeper.
Around 0.5A skipping is asymmetrical - motors will move down but not up.
At 1.4A the motor driver heat sinks start to get hot to the touch with constant Z axis movement
At 1.4A I tried putting a 15lb weight on top of one side of the Z axis and the motors still run fine.
If you loosen the screws holding the motors a little - enough the motors can move relative to the sled, but still stop the motor turning - do you still see the same stickiness at the bottom?
If that doesn’t work, I’d tend to go back to basics. It’s been a while since i’ve done a stock Maslow, but when I was running a stock one, this worked for me to get nice vertical travel:
Remove the Z-posts and the arms, so you have the two clamps with the linear bearing posts, and put the router in (technically you could leave the arms in, but without the Z-posts the stock clamps are a bit fragile)
You need to now adjust this assembly so it travels freely top-to-bottom, with the towers and everything fully bolted, and the lead screw of the Z motors sat in the centre of the clamp holes despite them not being attached.
If they are aren’t staying centred, you need to work out why and fix it. There is a small amount of play in where the linear-bearing-posts attach to the clamps, similarly a small amount in the bolts attaching the Z-motors, and otherwise throughout the whole Maslow. You need to get it right at this point or it’ll never be right.
Once that’s done, put in the lead screw screws and have them loose, and have the Z-motor screws loose as in the comment before. You should be able to use the web interface to move it up and down and it should move freely.
Tighten the lead screw screws bit by bit until they are tight, testing via the web interface and adjusting as you go.
Install the arms and the Z-posts, check it still travels cleanly with the full weight.
Screw the Z-motor screws tight with the Z all the way down, and check again.
I had to loosen the screws that hold the nut for the z axis threaded rods. When I had this problem I could turn one motor freely by hand whereas the other motor was pretty stuff. Loosening the motor helped a bit, but I was able to get them both moving freely by loosening the nuts
I had a very similar issue. I upgraded the firmware (1.17), and allowed a recalibration, having realized that my previous cal was on the default (small) grid and I want to cut 8’ x 4’ sheets. I then thought I’d do some manual jogging to put small holes in the base board to align with where the corners of the 8x4 sheet will go, and on a square grid with 610 mm spacing, which is convenient to measure the accuracy with a 1m steel ruler. So I manually found the zero height for the bit, cut down 5 mm and then set the z-jog to 10 mm. The idea being to retract to 5mm above the surface, move across 610 mm and just do a z-down (10mm) z-up (10mm) to make the other holes. 3 or 4 holes into this process the Z only came up ~4mm - resulting in a cut I didn’t intend to make (fortunately not of significant depth). But I can’t stress highly enough the problems this issue can cause. If Maslow4 spontaneously loses Z position, you can wind up trying to make cuts which are through the base board, which put massive strain on the device.
Previously I’d had Z problems but written this off as a dodgy control card (which Bar quickly replaced). That caused a chain of events - a very deep and too fast cut into the back board putting so much strain on that it broke the router clamps (fortunately I could 3D print some new ones).
I’ve read the comments and will try upping the Z-current in the hope that it will stop the problem.
But how about a 4.2 version with encoders on the Z-axis to confirm correct motion? I think this would make the whole device safer to use.
I’ve read the comments and will try upping the Z-current in the hope that it will stop the problem.
But how about a 4.2 version with encoders on the Z-axis to confirm correct motion? I think this would make the whole device safer to use.
encoders are not simple or cheap to use, which is why they are generally
minimized.
I think you are the only person who has been reporting these failures.
David, It seems to me like the same failure Zach (OP) reported, but I (accidentally) captured it happening in a controlled test rather than when running GCode. If more current is the only answer, I will try that. Is there any way for the firmware to monitor the applied current on the Z and determine if the maximum has been hit? This would indicate a Z failure to move properly and create an alarm, stopping motion and preventing the bit from being dragged screaming through the job (and baseboard). BTW I am running a horizontal rig.
Reporting back - I upped the Z axis current to 1.4 run and 0.75 hold and was able to cut out the rest of my table (2+ hours of continuous cutting) without any issues.
When I have some downtime, I plan to try loosening up the nuts and making sure nothing is binding there and just generally try to optimize friction in the Z travel.
I did notice, my machine is still ingesting saw dust into the Z steppers. While it was cutting I tried to hit those with compressed air every once in awhile when it was travelling. I may work on modifying the dust shield to add some small connections for some small rubber tubes to specifically clean dust off of these areas. Alternatively, I might just need to invest in a proper dust collection setup to get better suction.
David, It seems to me like the same failure Zach (OP) reported, but I
(accidentally) captured it happening in a controlled test rather than when
running GCode. If more current is the only answer, I will try that. Is there
any way for the firmware to monitor the applied current on the Z and determine
if the maximum has been hit? This would indicate a Z failure to move properly
and create an alarm, stopping motion and preventing the bit from being dragged
screaming through the job (and baseboard). BTW I am running a horizontal rig.
Currently the stepper drivers are output only, no ability to get any feedback or
measure current. The stepper driver chips theoretically have the ability to
detect missed steps, but that can be fooled by interference, and we have had
enough problems from that that I strongly suspect reliability would go down if
we tried it (I think it would still be useful to try it, but I wouldn’t expect
good results)
There is no way to measure the applied current to see if it’s hit the max or not
that I know of.
most people who have stepper problems have had one of two solutions
there was a bad batch of boards where the top stepper driver wasn’t installed
correctly, boards have had to be replaced
the alignment of the steppers is bad, loosening the bolts holding the
steppers to the sled, then lowering the sled all the way down, then tighening
the bolts fixes this.
under a half dozen other people have reported Z stepper problems that weren’t
one of the two above. so we don’t have much experience in troubleshooting it.
