Strange extruder skipping issue

[karlo]

I have an issue with the extruder skipping during a print. I've tweaked acceleration and extrusion speeds, but it still skips during this particular operation. At the moment, I'm looking at the source code to see if there might be a bug. However, it could just be my extruder or stepper motor is faulty. Can someone test the following gcode to see if they get skipping as well? In particular, it skips on the fast extrude and retract (lines 2 and 3), causing overextrusion. The code is nonsensical, don't worry about that; this is just the minimal case.

Code: Select all

G1 Y0 E0
G1 E4 F2400
G1 E0
G1 Y2 E4 F666.7

If I remove the Y move, the extruder behaves as expected.

In any case, please test and report your findings.

- Karl

[626Pilot]

The code appears to move filament up and down twice. No issues.

[karlo]

Forgot to mention, you need to run it twice. My bad.

[karlo]

As an aside, I'm hacking on the Repetier 0.90alpha firmware. It's grown a little, and I'm having some minor issues. If I switch on the generic thermistor tables and sdcard support at the same time, the Arduino refuses to run. Remove one or the other, and all works fine. Am I hitting a size limit? Once the firmware hits ca. 114kB things go downhill.

[karlo]

I think I have it figured out. There appears to be an bug in the extruder code, where a quick extrude + retract with no simultaneous movement will ignore acceleration, ie. it will run the filament down at full speed, and then back it out at full speed with no decel/accel in between. At least for me this causes skipping--I think my stepper motor has issues. With the change in place, the skipping is now gone. Can someone test with and without and see if this breaks anything?

Code: Select all

diff --git a/Repetier/motion.cpp b/Repetier/motion.cpp
index 4391f91..f89ee4b 100644
--- a/Repetier/motion.cpp
+++ b/Repetier/motion.cpp
@@ -1034,7 +1034,7 @@ inline void queue_E_move(long e_diff,byte check_endstops,byte pathOptimize
        p->delta[i] = 0;
        axis_diff[i] = 0;
   }
-  axis_diff[3] = e_diff*inv_axis_steps_per_unit[3];
+  axis_diff[3] = fabs(e_diff*inv_axis_steps_per_unit[3]);
   if (e_diff >= 0) {
        p->delta[3] = e_diff;
        p->dir = 0x88;

This is for 0.80 RepetierMax. I have the fix for 0.90alpha as well, if anyone is interested.

- Karl

[Eaglezsoar]

I think I have it figured out. There appears to be an bug in the extruder code, where a quick extrude + retract with no simultaneous movement will ignore acceleration, ie. it will run the filament down at full speed, and then back it out at full speed with no decel/accel in between. At least for me this causes skipping--I think my stepper motor has issues. With the change in place, the skipping is now gone. Can someone test with and without and see if this breaks anything?

Code: Select all

diff --git a/Repetier/motion.cpp b/Repetier/motion.cpp
index 4391f91..f89ee4b 100644
--- a/Repetier/motion.cpp
+++ b/Repetier/motion.cpp
@@ -1034,7 +1034,7 @@ inline void queue_E_move(long e_diff,byte check_endstops,byte pathOptimize
        p->delta[i] = 0;
        axis_diff[i] = 0;
   }
-  axis_diff[3] = e_diff*inv_axis_steps_per_unit[3];
+  axis_diff[3] = fabs(e_diff*inv_axis_steps_per_unit[3]);
   if (e_diff >= 0) {
        p->delta[3] = e_diff;
        p->dir = 0x88;

This is for 0.80 RepetierMax. I have the fix for 0.90alpha as well, if anyone is interested.

- Karl

Could you post this for the 0.90alpha please.
I am not a programmer so this may be a silly question but does it matter where you insert this code in configuration.h

[karlo]

Here's the 0.90alpha code. This is not a change in Configuration.h, this is a change in motion.cpp. Either you use 'patch', or you have to locate the code in motion.cpp and make the change there. Line number 1100.

Code: Select all

diff --git a/src/ArduinoAVR/Repetier/motion.cpp b/src/ArduinoAVR/Repetier/motion.cpp
--- a/src/ArduinoAVR/Repetier/motion.cpp
+++ b/src/ArduinoAVR/Repetier/motion.cpp
@@ -1100,7 +1102,7 @@ inline void PrintLine::queueEMove(long e_diff,uint8_t check_endstops,uint8_t pat
         p->delta[i] = 0;
         axis_diff[i] = 0;
     }
-    axis_diff[E_AXIS] = e_diff*Printer::invAxisStepsPerMM[E_AXIS];
+    axis_diff[E_AXIS] = fabs(e_diff*Printer::invAxisStepsPerMM[E_AXIS]);
     if (e_diff >= 0)
     {
         p->delta[E_AXIS] = e_diff;

Then compile and update the Arduino.

- Karl

[karlo]

Nobody? I have a verification that the fix works from someone outside the forum, but I'd really like some more testers before I start pestering Roland.

- Karl

[dpmacri]

Here's the 0.90alpha code. This is not a change in Configuration.h, this is a change in motion.cpp. Either you use 'patch', or you have to locate the code in motion.cpp and make the change there. Line number 1100.

Code: Select all

diff --git a/src/ArduinoAVR/Repetier/motion.cpp b/src/ArduinoAVR/Repetier/motion.cpp
--- a/src/ArduinoAVR/Repetier/motion.cpp
+++ b/src/ArduinoAVR/Repetier/motion.cpp
@@ -1100,7 +1102,7 @@ inline void PrintLine::queueEMove(long e_diff,uint8_t check_endstops,uint8_t pat
         p->delta[i] = 0;
         axis_diff[i] = 0;
     }
-    axis_diff[E_AXIS] = e_diff*Printer::invAxisStepsPerMM[E_AXIS];
+    axis_diff[E_AXIS] = fabs(e_diff*Printer::invAxisStepsPerMM[E_AXIS]);
     if (e_diff >= 0)
     {
         p->delta[E_AXIS] = e_diff;

Then compile and update the Arduino.

- Karl

I haven't looked through the surrounding code, so I'm not 100% certain what that particular piece of code is supposed to be doing. However, just based on the variable names, it looks like it's setting the "difference" of movement for the Extruder (E_AXIS). Your change makes that difference always positive which seems to me like you may have just eliminated retraction. Especially given that the not modified code is change for whether the movement is a fowrad movement or not (e_diff >= 0), it at least appears that there's an expectation that the difference could be negative.

[karlo]

Retraction is most definitely still there. The direction of the extruder stepper motor is set in p->dir, while the axis_diff is the length of the move, at least that's how it works for the X, Y and Z axes.

- Karl

[626Pilot]

I ran it a bunch of times so I could be sure. It doesn't seem to be skipping. Maybe I should ask some questions.

Are you using the stock hot end or something else?
What kind of filament?
At what temperature was the hot end?
How long had the hot end been running without being allowed to cool fully?
If the hot end has a fan, was it turned on, and was it at 100% or something else?
Which layer were you on?
Layer height?
Nozzle diameter?

[karlo]

Thank you for your help!

I can reproduce this with pretty much no load, ie. I retract the filament 15cm out of the hotend and just freewheel the filament inside the bowden.

Higher speeds should increase the likelihood of skipping, but if you don't get skipping, you should at least get a good thunk out of the extruder, since it's going through the extrude/retract transition with no decel/accel whatsoever, and hence jerk goes through the roof. A Rostock Mini user on github reports the same issue as me, and confirms that the patch fixes that issue (https://github.com/repetier/Repetier-Fi ... issues/151).

I suspect that my extruder stepper motor is weak, which exacerbates the issue in my case; I cannot reliably run the extruder at > 45mm/s. I'll likely have to replace it soon.

- Karl

[geneb]

Karl, thanks for digging out that bug.

I spent some time a few days ago actually looking at the Repetier firmware code. I don't know about you, but as a professional software developer, perusing that code makes me want to take an ice pick to my frontal lobe.

I learned three things.

1. TERNARIES FOR ALL THE THINGS!

2. Whitespace is where nightmares come from.

3. Constants are for pussies.

Have you had any issue with .90alpha ignoring any movement commands if you try free-air extruding a bit? It extrudes a small amount and then stops. Some seconds later it'll resume. It's almost like the stepper driver is packing it in, but it affects all axes at once and doesn't happen under Marlin or RepetierMAX.

g.

[lordbinky]

I learned three things.

1. TERNARIES FOR ALL THE THINGS!

2. Whitespace is where nightmares come from.

Anything less than zero whitespace 5+ nested ternaries contained on a single line is just ineligant and unreadable. And no you can't use parentheses, they just make it look dirty.

[karlo]

I learned three things.

1. TERNARIES FOR ALL THE THINGS!

2. Whitespace is where nightmares come from.

3. Constants are for pussies.

Umm, yeah. I'm a professional developer as well, and I'll have to agree. I'm not going to criticize free software, but the Marlin code is cleaner.

Have you had any issue with .90alpha ignoring any movement commands if you try free-air extruding a bit? It extrudes a small amount and then stops. Some seconds later it'll resume. It's almost like the stepper driver is packing it in, but it affects all axes at once and doesn't happen under Marlin or RepetierMAX.

I don't really do free-air extrudes, so I haven't seen this, but if you have a test case, I can take a look at it.

- Karl

[geneb]

It's pretty repeatable - just bring your hot end up to temp and start extruding filament. I've got it set at 100 mm/min and a 10mm extrusion length for every button press. I'll get one or two clicks before it appears to quit processing commands of any kind.

g.

[karlo]

Good news! Roland acknowledged the bug and applied my fix with some modifications. As mentioned, the bug exists in 0.80 RepetierMAX as well, although I'm not sure that's being maintained any more.

My printer is down for a PSU replacement. If I find time, I'll take a look at your issue, Gene.

- Karl

[Eaglezsoar]

Good news! Roland acknowledged the bug and applied my fix with some modifications. As mentioned, the bug exists in 0.80 RepetierMAX as well, although I'm not sure that's being maintained any more.

My printer is down for a PSU replacement. If I find time, I'll take a look at your issue, Gene.

- Karl

Thank you for squashing that bug. I'm glad that they applied your fix because it benefits us all.
Now if they can get the communications problems fixed....