Firmware 3.4.x bug (layer shift)
This is a write up for report to the issue on github firmware page.
Had an overnight print in 3.4.0, next morning saw this:
Flashed to 3.4.1. Restarted the print and failed in similar location:
Resliced with lower infill speed, also printed in normal / stealth mode, still failed in different position.
Refreshed to firmware 3.3.0 and printed successfully:
Re: Firmware 3.4.x bug (layer shift)
So I go back to firmware 3.4.1 and try again. Sliced with slightly different parameter, and shift occurred in different location. My last Gcode had layer shift in 2nd layer, front left region. 2 attempts shows shift start in nearby region, but not the same spot.
By stacking 2 failed print together, shows it offset in X & Y by same amount, so the end edge (green line) is in the same location.
In second attempt, the print halted again in nearby location, but no layer shift this time:
Because the shift starts in predictable location, I was able to film it:
Going back to firmware 3.3.0 for now. First 4 layer of gcode is below for other to troubleshoot, but I didn't saw any strange code near those region:
https://drive.google.com/file/d/1kyaOBH4_qS5YSCoTbJLP5jmz76FyWhgy/view?usp=sharing
My eeprom settings seems normal, M503 result below:
SENDING:M503
echo:Steps per unit:
echo: M92 X100.00 Y100.00 Z400.00 E280.00
echo:Maximum feedrates - normal (mm/s):
echo: M203 X200.00 Y200.00 Z12.00 E120.00
echo:Maximum feedrates - stealth (mm/s):
echo: M203 X100.00 Y100.00 Z12.00 E120.00
echo:Maximum acceleration - normal (mm/s2):
echo: M201 X1000 Y1000 Z1000 E5000
echo:Maximum acceleration - stealth (mm/s2):
echo: M201 X960 Y960 Z1000 E5000
echo:Acceleration: S=acceleration, T=retract acceleration
echo: M204 S1250.00 T1250.00
echo:Advanced variables: S=Min feedrate (mm/s), T=Min travel feedrate (mm/s), B=minimum segment time (ms), X=maximum XY jerk (mm/s), Z=maximum Z jerk (mm/s), E=maximum E jerk (mm/s)
echo: M205 S0.00 T0.00 B0.00 X8.00 Y8.00 Z0.40 E1.50
echo:Home offset (mm):
echo: M206 X0.00 Y0.00 Z0.00
echo:PID settings:
echo: M301 P21.12 I2.00 D55.85
echo:PID heatbed settings:
echo: M304 P132.01 I6.04 D721.05
echo:Retract: S=Length (mm) F:Speed (mm/m) Z: ZLift (mm)
echo: M207 S0.80 F2400.00 Z0.00
echo:Recover: S=Extra length (mm) F:Speed (mm/m)
echo: M208 S0.00 F1200.00
echo:Auto-Retract: S=0 to disable, 1 to interpret extrude-only moves as retracts or recoveries
echo: M209 S0
echo:Filament settings: Disabled
My slicer setting different from stock by custom start g-code to allow nozzle clean before print starts, and avoid leaky stringy dots when mesh probing, and also firmware retraction (don't like marks leave behind by retract wipe). It's all in the Gcode above.
Re: Firmware 3.4.x bug (layer shift)
I had the same problems with about 4 or 5 different firmware versions. Ever since I turned off crash detection never had a problem since.
Jim
Re: Firmware 3.4.x bug (layer shift)
My crash detection is always off. This is a different problem, if a crash is detected, XY coordinates is assume to be lost, the hotend need to home first to a known XY coordinate, and then resume printing. In the video, the hotend just halt, and then jump to wrong location and resume printing without homing.
Re: Firmware 3.4.x bug (layer shift)
Further test suggest this is filament sensor related. Re-sliced with sliced retraction, first 4 layers gcode below:
https://drive.google.com/file/d/1Ee7LvYSvnRzHRk5VaNt-pMqUbsk4K8I9/view?usp=sharing
Printing paused at similar region but without layer shift. There's 3 pause in nearby region, com terminal shows following output during those pause:
fsensor_stop_and_save_print
fsensor_oq_meassure_start
echo:Enqueing to the front: "G1 E-3 F200"
echo:Enqueing to the front: "G1 E3 F200"
fsensor_oq_meassure_stop, 5 samples
st_sum=723 yd_sum=22 er_sum=0 er_max=0
yd_min=18 yd_max=6 yd_avg=5 sh_avg=2
fsensor_err_cnt = 0
fsensor_restore_print_and_continue
fsensor_stop_and_save_print
fsensor_oq_meassure_start
echo:Enqueing to the front: "G1 E-3 F200"
echo:Enqueing to the front: "G1 E3 F200"
fsensor_oq_meassure_stop, 5 samples
st_sum=723 yd_sum=22 er_sum=0 er_max=0
yd_min=17 yd_max=5 yd_avg=5 sh_avg=2
fsensor_err_cnt = 0
fsensor_restore_print_and_continue
fsensor_stop_and_save_print
fsensor_oq_meassure_start
echo:Enqueing to the front: "G1 E-3 F200"
echo:Enqueing to the front: "G1 E3 F200"
fsensor_oq_meassure_stop, 5 samples
st_sum=723 yd_sum=16 er_sum=0 er_max=0
yd_min=16 yd_max=3 yd_avg=3 sh_avg=2
fsensor_err_cnt = 0
fsensor_restore_print_and_continue
Reprint the previous gcode with firmware retraction, also have 3 pause nearby. Layer shift occurs at first pause, com terminal shows following output:
fsensor_stop_and_save_print
fsensor_oq_meassure_start
echo:Enqueing to the front: "G1 E-3 F200"
echo:Enqueing to the front: "G1 E3 F200"
fsensor_oq_meassure_stop, 5 samples
st_sum=726 yd_sum=24 er_sum=0 er_max=0
yd_min=18 yd_max=6 yd_avg=5 sh_avg=2
fsensor_err_cnt = 0
fsensor_restore_print_and_continue
fsensor_stop_and_save_print
fsensor_oq_meassure_start
echo:Enqueing to the front: "G1 E-3 F200"
echo:Enqueing to the front: "G1 E3 F200"
fsensor_oq_meassure_stop, 5 samples
st_sum=717 yd_sum=21 er_sum=1 er_max=1
yd_min=31 yd_max=6 yd_avg=5 sh_avg=2
fsensor_err_cnt = 0
fsensor_restore_print_and_continue
fsensor_stop_and_save_print
fsensor_oq_meassure_start
echo:Enqueing to the front: "G1 E-3 F200"
echo:Enqueing to the front: "G1 E3 F200"
fsensor_oq_meassure_stop, 5 samples
st_sum=718 yd_sum=13 er_sum=0 er_max=0
yd_min=15 yd_max=3 yd_avg=3 sh_avg=2
fsensor_err_cnt = 0
fsensor_restore_print_and_continue
Print shifted right and upward rather than downward as in previous failed print. The carriage will crash into x-end-idler after this shift.
Done the printed parts upgrade during grooved rods replacement, so the filament sensor window was cleaned recently. Filament used include white and silver-gray PLA.
Don't really need the filament sensor for extruder slippage, but need it for filament run-out detection.
Re: Firmware 3.4.x bug (layer shift)
very interesting. But even if the filament laser sensor makes problems, it never should affect the xy coordinates in that way!
Re: Firmware 3.4.x bug (layer shift)
but that's how software bugs behave .... illogically.
Re: Firmware 3.4.x bug (layer shift)
very interesting. But even if the filament laser sensor makes problems, it never should affect the xy coordinates in that way!
Oh great now you've jinxed it!
Re: Firmware 3.4.x bug (layer shift)
Also getting layer shift. I'm printing a very thin walled wing from 3dlabprint. The only way I can get a successful print is by reducing the speed to 90%. The gcode I am using is provided by 3dprintlab. I'm using the latest firware 3.4.1
Re: Firmware 3.4.x bug (layer shift)
Switching off crash detection solved it for me
Re: Firmware 3.4.x bug (layer shift)
Switch off crash detection. It does not work reliably. It detects false crashes and resets to the wrong place causing random layer shifts.