search

MarlinFirmware / Marlin

Marlin is an optimized firmware for RepRap 3D printers based on the Arduino platform. Many commercial 3D printers come with Marlin installed. Check with your vendor if you need source code for your specific machine.
https://marlinfw.org
GNU General Public License v3.0
16.14k stars 19.2k forks source link

Layer shift at random heights on 1.1.3 Bugfix #7009

Closed Kaibob2 closed 7 years ago

Kaibob2 commented 7 years ago

Since i upgraded from RCBugFix to 1.1.3 bugFix i experience random layer shifts on every print. img_20170609_184609

The GCODE produced by S3D is okay. I printed the same cube a dozen times before with BCbugFix from before RC8.

I tested 115200baud and 250000baud via serial and also printing the same file from SD. Like you can see the shift happens at different heights, so the behaviour is random. The printer is well calibrated, the driver have enough current, Acc. and vel. is pretty conservative.

Any ideas?

Kaibob2 commented 7 years ago

I caught the serial output when it happened. Layershift.txt This is what it printed img_20170609_191736 The last good layer is M117 Layer 60, H=9 The inner perimeter of layer 61 is okay, the outer one is shifted to the left.

This is what S3D sends for the both perimeters 1.txt

It's always the outer perimeter which fails and it shifts about the same distance several times img_20170609_194209

epatel commented 7 years ago

If you slow it down a little?

I am thinking that maybe your travel speed is too close to what the current version can handle in speed (sending pulses to the stepper drivers).

Kaibob2 commented 7 years ago

Was there a decrease in the maximum speed since RCBugFix? I have travel speed set to 200mm/s which was fine before.

epatel commented 7 years ago

I wouldn't be surprised.

Kaibob2 commented 7 years ago

Setting maximum velocity to M203 X500.00 Y500.00 Z9.00 E150.00 and performing a manual movement with G91 G1 X-100.000 F30000 G90 works flawless. So this doesn't seem to be the cause. To be honest: I would have been surprised :)

Kaibob2 commented 7 years ago

Different object, same problem img_20170609_201441 The gecko is 72mm, the layer is shifted by 36 mm. Exactly the half.

Bob-the-Kuhn commented 7 years ago

After the shift and the print is completed/stopped, does M114 report the correct information or is that also shifted?

When you look at the X/Y values in the log from the good layer vs. the bad layer, are they the same or shifted?

Kaibob2 commented 7 years ago

Only the X-axis seems to be affected. I never had a shift in the Y-axis. Maybe you can take a look at Layershift2.txt This is the log from layer 59-61 of a cube which was fine until the outer perimeter of layer 61 shifted. I don't get the Count: output. The coordinates seem okay.

Kaibob2 commented 7 years ago

Below is the last part of the log when another cube failed right now. I was watching the whole time and this is what happened in the moment of failure: unbenannt This is the topview. Printing direction is counterclockwise. Startpoint for every layer is fixed at the top left of the drawing.

Green: 30 layers ok Red: first line of layer 31 orange: slowly creeping back to startpoint of red line blue: left turn and printing into the air at normal speed violet: continue to print the cube...shifted

SENT: M117 Layer 31, H=4.65 READ: X:118.90 Y:108.73 Z:4.50 E:0.00 Count X:7315 Y:7293 Z:7196 READ: ok READ: ok SENT: G1 X90.600 Y114.400 F12000 READ: ok SENT: G1 Z4.650 F540 SENT: G1 E0.0000 F2400 READ: ok SENT: G92 E0 READ: ok SENT: M105 SENT: G1 X90.600 Y85.600 E0.6825 F2730 READ: ok READ: X:90.60 Y:114.40 Z:4.65 E:0.00 Count X:7315 Y:7901 Z:7196 READ: ok READ: ok T:189.71 /190 B:60.16 /60 T0:189.71 /190 T1:30.49 /0 @:60 B@:0 @0:60 @1:0 SENT: G1 X119.400 Y85.600 E1.3650 READ: ok SENT: G1 X119.400 Y114.400 E2.0475 READ: ok SENT: G1 X91.000 Y114.400 E2.7205 READ: ok SENT: G1 X90.600 Y114.400 F2730 Print stopped here.

M114 returns: SENT: M114 READ: X:90.60 Y:114.40 Z:14.65 E:2.72 Count X:7275 Y:9141 Z:23428

This is the Gcode file: Cube 30x30x15.txt

epatel commented 7 years ago

I would expect "Count" to be the stepper counters, and when looking at the logs this looks very fishy...will check the code a little.

(i.e. X_STEPS_MM → count value)

Kaibob2 commented 7 years ago

At the last log I had to lift Z 10mm to prevent the nozzle from melting the object. That's why Z:14.65 but H=4.65

epatel commented 7 years ago

I imagine the "Count:" log can be a little misleading as the count numbers are a snapshot of the absolut position in travel so to speak, but the XYZ are probably the position the steppers are working to get to. First it looked strange I thought, but I can imagine it be correct and maybe not too helpful. Unless the position is reported when the head is not moving...

Kaibob2 commented 7 years ago

Yap. That's the problem when sending M114 after the print is stopped or still shifted. I don't know exactly where the nozzle physically was when the position is reported. I managed to take a video of the shift. Funny, but true. The shift happens not only once but again and again... It happens at around 1:15 https://youtu.be/LUHp9UVuhOg

Pretty close to my great artistic drawing, right :)

Kaibob2 commented 7 years ago

And for completeness:

Configuration.zip

epatel commented 7 years ago

Have you tried to set MINIMUM_STEPPER_PULSE to something > 0? (Configuration_adv.h)

Again, still thinking its a problem with the stepper driver. Maybe it gets more picky on the pulse width with heat? well, guessing...

fiveangle commented 7 years ago

video is sad. poor thing ! https://www.youtube.com/watch?v=NeFkrwagYfc

Kaibob2 commented 7 years ago

OH! MY! GOD! This is so akward, i missed to uncomment #define USE_CONTROLLER_FAN Shame on me. The TMC drivers become quite hot without cooling @epatel You were right from the begining!! Great job!!! I'm an electrical engineer and i missed this little thing. Damn, sorry for that!!! Sometimes you are so focused on the error that you won't see the forest because of all the trees.

Kaibob2 commented 7 years ago

@fiveangle ...at least it tried...

Kaibob2 commented 7 years ago

Thanks all for the patience and good will...

andergrin commented 7 years ago

I have the same problem with 1.1.3 and 1.1.4 versions - shifted layer on the Y axis on the random hight. GCODE generated by Simplify 3D. Previosly i use'd RC7 and it's work fine without any problems, and settings in 1.1.3 and 1.1.4 was identical with RC7. So now i have to return to RC7.

Kaibob2 commented 7 years ago

Like I commented above, in my case, it was not Marlins fault but mine. Without active cooling the stepper drivers overheat and cause random shutdowns of themselves which results in step losses.

nealpalmer commented 7 years ago

I'm having the same problem on 1.1.1. But I usually see the problem on the Z-axis showing extra thick layers that aren't bonded well to the layer below and are like spaghetti (about 10% of prints do this once or twice). I heard it happen once: it was in the middle of a layer doing infill, and the x/y stopped moving, and Z did a large move (about 1mm) which was very audible, then the print separated after that. I think I have also seen the Y-axis shift, but much more seldom than the z-axis. My problem is definitely not the stepper driver overheating.

github-actions[bot] commented 2 years ago

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.