On my CR10, I have been using a BL touch for the past month with good results. Lately had been trying to resolve some under extrusion issues. But in the process my printer has decided that after homing x and y it will move to the centre of the bed and just flash the BL touch red light with out moving the z axis and then report that bed levelling is done and not proceed with the printing of the model. All of this while being about 4 inches off the bed surface. It doesn’t try to go through the various bed targets for checking level.
I checked the probe and it seams to be able to move freely. Any thoughts?
Have you got a test file that you know works? Try resetting the printer and printing that file. I’ve gotten a few odd bl touch errors and they seem to be tied to the file somehow and at least once I had to pull the probe out to stop it from erroring out.
I just had 3 errors in a row with BL touch and one thing I notice and failed to mention is if it fails to respond it seems tell the controller to turn it off. So the next time you run the file it will ask if your machine as BL touch because the G-code called for it (G29 I think) but it was switched off
Good suggestion, I just went and tried to print a file that printed a week ago and same issue. head goes to middle of the bed and claims bed is level and does nothing.
I also tried the home z command on the cr10 display and it didn’t move. I then used the move z axis and found it would only move up. wouldn’t move down. So I disabled the limits, and tried again. The display showed negative values but the axis didnt move down. only up. I’m stuck.
Did you check your wires form the Z motors? also with the power off you should be able to turn the rods in both directions by hand
wires appear to be seated properly. With power off Z axis travels up and down with out a problem too.
Your problem is that your Z-Limit switch is being triggered. It’s either a separate limit switch or part of the BL-Touch (probably the latter). It won’t move down because it believes it’s already as low as it can go. It won’t print because part of the startup sequence, aside from homing, is to move away from the home position far enough to release the limit switch. Since your limit switch is stuck, it can never clear it and technically never completes the homing process and therefor doesn’t start printing.
wooo good call. hope thats all it is
that makes a lot of sense. so perhaps the BL touch needs replacing?
that appears to be it. I mucked with the BLtouch a bit. the prob may have had a slight lean to it. I applied a bit of pressure the other way. and ran z home command and it worked. It is now attempting a bed level. Thank you both for the help. Now to see if this under extruding issue is still there.
Ok. so now it gets past the z axis centre home, but now when it does the auto levelling it works it’s way through all 25 of the calibration locations. (it is a CR10s5) and then just sits at the last one (back far right corner) and doesnt progress from bed leveling to printing.
It doesn’t time out or anything?. How is the ABL called is the command coming from the Gcode at the beginning of the file?
I’m glad you got past the Z-axis problem. You should probably post this next problem in a new thread as anyone who has the ability to help you but hasn’t followed this thread will see that you’ve indicated the problem as “solved” and stop reading to discover there’s a subsequent problem.
I don’t own a CR10 so I’m taking educated shots in the dark. When I hear that a machine just sits there, it’s usually because some condition is not being satisfied (as was the original case), so that raises some questions:
- Is this problem repeatable? Have you restarted the machine and run the gcode again only to get to the same point?
- It could just be a coincidence that the bltouch stops at the 25th point. That on the BLTouch that was out of alignment the first time could be out of alignment again and it just happened to be on the last test point.
- Have you printed this particular gcode before? Gcode that contains an invalid command can, depending on the a given printer’s firmware, cause the rest of the gcode to be aborted so the printer protects itself from doing something stupid. Unfortunately, I’ve never heard of a firmware author writing “Defective GCode: aborting” on the display when this happens: they usually just fail silently. Try printing something you’ve printed before that you know works.
- When the BLTouch (another thing I don’t own) sits at the last test point, has it completed the test and raised the pin? I should probably have asked this earlier.