Unexpected behavior when printing

[SuperBoppy]

About 3 years ago, I built a Voron 2.4 300mm from scratch (Pi4B, SKR 1.4 MCU boards, Afterburner). Very pleased with it.

Maybe someone has some insight on this. Every so often (very rare), A print will shift out of position (around 5 mm or so) after the first or second layer. Or, like what happened last night, the printer stopped right after printing the entire file, the print head positioned over the part at the very last position - the bed heater turned off, but the hot end still heated (not turned off) and not returned to a neutral position, etc. Also, Fluidd showed an error symbol for the print job (see image).

I'm glad I stayed up last night to take the print out - if I hadn't, the print head would have been hovering over the last point in the print job with the hot end still heating (see why you shouldn't leave a 3D printer unattended?) 

Any clues as to what might cause this? Like I said these occurrences are extremely rare, but disturbing when they happen. It's not a physical problem with the printer - the shifting problem, for example, goes away when I reprint the same g-code file. It seems to be a hiccup in the system when it's printing. Bad memory spot on Pi SD card? I check the g-code file on the printer to see if it got chopped off somehow when importing to the Pi, but it was all there - it was not corrupted.

Noise in the electronics, perhaps a micro interruption in power to the printer? A very brief interruption in power from the mains is to me the one that seems to be the most plausible. Perhaps a good reason to use a UPS with printers...

Anyone with thoughts on this?

 

 

[GarthSnyder]

Shifts are from one or more motors skipping steps. The instantaneous acceleration is too high or the motor currents are too low. It's not 100% consistent between repetitions of the same G-code file because you're operating near the configuration's physical limits and there's some randomness inherent in that.

The other issue is some kind of error. Look in the Klipper log (~/klipper_logs/klippy.log on my Pi, but I'm not sure that's standard) or the console to see what it is.

[SuperBoppy]

Thanks for the suggestion on motor skipping. This problem is very rare, and it has happened on small objects where the speed or complexity was not a factor. I never print above 120mm/sec, and my acceleration and jerk are the default - I have not tried to make the machine a speed-demon, I'm just happy it prints stuff. As far as the motor currents are concerned, I need to check into that - I don't believe I've ever checked them on the Voron.

The other issue I figured out. I was printing an object that was 295mm x 295mm. What was happening was the printer ignored a command in the print_end macro to move 10mm to eliminate stringing at the end of the print. Because the print was so large, the 10mm was outside the the print boundary so Klipper returned an error message and stopped. I commented out the command so this won't happen anymore.

[DangerBit]

Have you done any periodic cleaning or lubrication of the rails? They will wear out and wear out faster if they aren't cleaned and re-lubricated periodically. 

[SuperBoppy]

Haven’t touched the rails since I built it. I don’t have tons of hours on the printer, but may not be a bad idea to clean and lube them. Is there a good link to a procedure for doing this?

[DangerBit]

Well there's a good video here for cleaning and lubricating rails.

And I just came across this one that also looks useful.

 

[dshess]

My PRINT_END macro has these lines:

    {% set max_z = printer.configfile.config["stepper_z"]["position_max"]|float %}
...
    {% if printer.toolhead.position.z < (max_z - 2) %}
        {% set z_safe = 2.0 %}
    {% else %}
        {% set z_safe = max_z - printer.toolhead.position.z %}
    {% endif %}
...
    G0 Z{z_safe} F3600             ; move nozzle up
    G0 X{x_safe} Y{y_safe} F20000  ; move nozzle to remove stringing
    TURN_OFF_HEATERS
    M107                           ; turn off fan

    G90                            ; absolute positioning
    G0 X60 Y115 F20000          ; park nozzle near rear
    {% if printer.toolhead.position.z + z_safe < max_z - 10 %}
        G0 Z{max_z - 10} F3600
    {% endif %}

This was cribbed from elsewhere, and I have a TODO in there saying "clean this up", so it is probably horrid.  It also has some X and Y versions which I omitted for brevity.  The gist of it is to move the nozzle up and to the side immediately to avoid stringing, then it moves the nozzle to a parked position.  If the nozzle has plenty of headroom, it moves up 2mm, then to max_z-10mm.  If there is not headroom, it just moves up to max_z.

[This is for a V0.2, where the bed has to travel to the bottom to trigger the Z endstop.  So it makes sense to just park close to max_z at the end of a print.  In other situations I'd probably just have it go up 20mm and to the back wall.]

[cjkennedy72]

@SuperBoppy If you haven't already, I would suggest going through the build and checking every single screw to be sure they are tightened as they should be. They have a way of wiggling loose now and then and troubleshooting this when it causes a problem so infrequently can be infuriating. 

Good Luck!

[chrisalbertson]

The printer's motion control operates "open loop". The only solution is to either slow down or send more power to the motors.   An open loop system has to be more powerful than needed so the chance of a skipped step is practically zero.   What is needed is a sensor to sense toolhead motion and then the motor controller does "wherever it takes" to reduce the difference between the commanded toolhead location and the measured location.

The simplest way to measure is to place rotation sensors on the drive pulleys.   My next printer will use these and the loop will be closed in the MCU.