Odd single thickness wall bug

[mattsch]

I had submitted this issue over to Slic3r first (#1873), moved here after their review.

When trying to print the standard 20mm calibration cube to calculate extrusion multiplier with the extrusion width set to .40mm, I get a very interesting leaning tower (picture attached). If I let Slic3r do it's own calculation, bump the width up manually to .48mm, or rotate the cube 45 degrees before slicing then it prints perfectly.

I went through and checked all my mechanics, haven't had any other issues manifest that would indicate faulty parts. I'm running the latest from the Marlin_v1 branch and my repo with configs is here.

STL, gcode, etc: http://www.excentral.org/files/slic3r_thing_wall_bug.tar.gz

[orcinus]

Have you tried reducing your acceleration? Maybe the g code results in a particularly violent move after layer change that results in skipped steps.

I've had that happen with Slic3r and Repetier once, and it wasn't Repetier's fault - Slic3r was consistently generating violent Y moves immediately after a layer change and in had the acceleration / max. feedrate set too high for my mechanics.

[mattsch]

I don't see how acceleration would factor in on this, simply changing the extrusion width from .40mm to .48mm "fixes" the offset. It's printing hollow with a single perimeter so infill or number of movements per layer are the same.

[orcinus]

Like i've said, i've experienced the exact same thing before, with Slic3r, albeit quite a few versions ago. A certain combination of slicing parametes would produce a violent move with an unusually high feedrate. With max. feedrate set too high and high acceleration set in firmware, this would then result in an impossible move (torquewise) for the stepper and the Y caddy.

This, in turn, then resulted in a skipped step always at the same place (start of a new layer), with exact same symptom as in your photo.

Have you tried a different slicer? Have you tried more conservative speed and/or acceleration? Different firmware? It's pretty easy to find the culprit by simple elimination :)

[mattsch]

I should have added, during my testing/tweaking of the mechanical bits, I was watching the print extremely closely looking for any signs of skipping (noise, odd movements, etc.) and saw nothing but smooth movement. Wouldn't using a gcode viewer like gcode.ws show the kind of movement you describe?

Speed for these layers is only 10mm/s so I'd be surprised if slowing it down any further would make much difference. Max accel/feedrates are as follows, haven't seen any other issues using them but I can drop em just to rule it out:

#define DEFAULT_MAX_ACCELERATION      {2000,2000,150,5000}
#define DEFAULT_MAX_FEEDRATE          {400, 400, 4, 30}

I haven't tried a difference slicer yet, Cura's been on my list to try again but just haven't done it. Thing is, assuming (and I may be assuming too much here) the various gcode viewers are accurate, I would think at least one of them would show something odd about the model if the culprit were the slicer.

[orcinus]

Your travel moves are happening at 150 mm/s, not 10 mm/s.

I'm not saying that's the cause, just that it's one possibility (based on my own experience with similar symptoms). My suggestions are: 1) try reducing the travel feedrates 2) try reducing acceleration to 1000 just to be on the safe side 3) try KISSlicer or Cura 4) try Repetier (with the same settings)

That should clear up what the cause is.

[ledvinap]

This problem is not caused by skipped step - motor can only skip 4 full steps, that's few millimeters for belt drive ...

[orcinus]

Not really, no. For a 16T pulley, T2.5 belt, standard resolution stepper, 1 full step is 0.2mm. Making 4 full steps equal to less than a millimeter.

[ErikZalm]

Did you check if your pulleys are slipping. Place a marking on the axis and pulley and see if they are still aligned after printing. Rotating the print by 45deg lowers the axis speeds by sqrt(2). This can explain why it is not happening when you rotate it.

[mattsch]

@orcinus I do plan on trying to reduce acceleration and such, just haven't had the time in front of the printer to test just yet. I have done several longer prints in the meantime without any issues so I would be extremely surprised if those made a difference. Trying Cura however is likely going to be the first thing I try.

@ErikZalm The first things I checked were mechanical. Pulleys have been verified as nice and tight, belt is solid, x/y movement is smooth across the smooth rods (with and without belts).

[mattsch]

So ran into this again when calibrating my other printer (Prusa I3), same steps, same symptoms. With the exception of not being able to fix it printing oddly by changing extrusion widths, even setting it to automatic and letting Slic3r decide. Url to the gcode file is below, gcode.ws doesn't show any issues and the lcd reports it making a proper square track (same x/y coordinates at level change) but it's clearly not square.

http://www.excentral.org/files/testcube_20mm-i3_slanted.gcode.gz

[andrewsil1]

FYI, there’s a new final v1.0.0 version (no longer RC status) of Slicer out as of yesterday, as well as an experimental v1.1.0. Might be worth trying with the updated slicers, several bug fixes were listed in the release notes. … www.slic3r.orghttp://www.slic3r.org

From: Matthew Schick [mailto:notifications@github.com] Sent: Thursday, March 27, 2014 5:09 PM To: ErikZalm/Marlin Subject: Re: [Marlin] Odd single thickness wall bug (#853)

So ran into this again when calibrating my other printer (Prusa I3), same steps, same symptoms. With the exception of not being able to fix it printing oddly by changing extrusion widths, even setting it to automatic and letting Slic3r decide. Url to the gcode file is below, gcode.ws doesn't show any issues and the lcd reports it making a proper square track (same x/y coordinates at level change) but it's clearly not square.

http://www.excentral.org/files/testcube_20mm-i3_slanted.gcode.gz

— Reply to this email directly or view it on GitHubhttps://github.com/ErikZalm/Marlin/issues/853#issuecomment-38876434.

[mattsch]

This was sliced using v1, no gonna try 1.1 unless I'm sure it's needed. I have yet to try this particular piece with Cura but I'll see what that does.

[nothinman]

@mattsch please update or close

[mattsch]

I haven't been able to reproduce with Cura, but the issue remains with the gcode/slic3r configs posted. Since gcode simulators don't see an issue or show anything but a proper cube to be printed, I'm not sure where to go from here. I've been printing quite a bit in the meantime without issues (including parts for other printers) but this specific combination is problematic for some reason I don't get.

[nothinman]

Please reopen if you run into problems again. Thanks.

[galexander1]

I would not discount @orcinus' hypothesis. Are you still using 175mm/s travel feedrate?

It was suggested that you reduce travel feedrate and/or max acceleration. Have you?

[barneycg]

According to the gcode my xy speed is all of 5mm/s the z is as fast as it can go but that isn't the problem axis :) and there is no travel except when it moves to the start of the first non infill bottom later, all the other layers are simply 4 lines one for each corner of the square it is drawing on that layer. Problem goes away if I add a 2nd shell.

[galexander1]

Um, either your travel speed is 175mm/s or it isn't and avoiding the question won't help you fix it.

[barneycg]

My travel speed has never been 175mm/s I'm a different person to the person who raised this originally ;) so I'm not avoiding the issue. I will reslice and set all my speeds manually to 5mm/s to confirm.

[galexander1]

oh :)

[mattsch]

I'm the original submitter, can confirm I still see this under the same conditions. I'm 100% certain it's not a calibration or other mechanical issue since I only see it in this specific use case.

[galexander1]

@mattsch uh, if you're saying that because your robot is reliable it cannot have mechanical problems, would you not also say that because it is reliable it cannot have firmware problems? It is not wrong to suspect the firmware, but it has not been proven yet.

Anyways,can you tell me: have you tried reducing your travel speed and acceleration settings?

[mattsch]

What I'm saying is that I can ONLY reproduce this bug under a very specific set of circumstances and it does NOT show up anywhere else. I've printed much more complex figures with larger jumps without any loss in accuracy or drift like this. As barneycg pointed out, there's no travel other than in z at the end of each layer.

I have had to adjust both travel speeds and accel as I've fine-tuned this printer, and I'm familiar with what it looks like when you lose steps or overshoot due to moving too fast. This isn't that.

[galexander1]

Well, if it is a firmware bug, it would be an interesting one, and we need someone who can debug to try to reproduce it. I have a delta so I doubt it can be me.

[barneycg]

Also I can mitigate the problem by adding a 2nd shell ... this inner shell is actually printed faster than the outer one due to my slic3r settings yet somehow this is enough to print a perfect cube with walls that are the expected thickness (ie 2 shells worth). That is 3 physically different printers with (if I'm interpreting Mattsch right 2 different designs) that see the same problem. Though I am a little puzzled that Mattsch see's it in the x axis and I'm seeing it in the y axis (for clarity on my prusa i3 the y axis is the bed moving back and forth) Also if it were slippage the variation between the top and bottom would not be so even or exactly the same 5mm at the top every time. I actually tried a 15cm square by 20mm high hollow box to verify it wasn't something about the acceleration or the minimum layer time I've got set and got exactly the same result.

[nophead]

It would be useful to know what the offset between layers is on terms of micro steps and motor steps. If it is exactly four motor full steps then the motor is skipping as the firmware and electronics work in microsteps.

[barneycg]

I was doing 0.25 layer height on 1/16 microstepping with 1.8 degree motors and GT2 belts with 20 tooth pulleys and m6 z axis.
I'm not sure this maths is correct but : The top is 5mm further forward than the bottom and it is 20mm high @ 0.25 mm layer height there is 80 layers ... the angle is consistent so that would make each layer offset by about 0.0625mm which with 80 steps per mm for the belts is 5 steps. Which since there are 80 layers means 0.0625 steps per layer :) - which is exactly 1 microstep per layer.

Does that sound right or have I got it completely wrong ? that does look decidedly suspicious in some way.

[nophead]

Yes 5mm over 80 layers is 0.0625mm per layer, I am with you so far. One micro step is 1/80 = 0.0125mm so the offset is 5 microsteps per layer.

That is an odd amount so I am guessing it is perhaps related to the number of changes in direction per layer. What does the gcode for one layer look like?

[barneycg]

I'm confused ... where do you get 1 microstep being 1/80 from ? I though that if the steps per mm of the y axis = 80 then the 0.0625mm offset per layer is 5 steps (80*0.0625) not 5 microsteps.

anyway layer 3 ( the first single shell with no infill looks like ): G1 Z0.750 F9000.000 ; move to next layer (2) G1 X99.750 Y109.750 F9000.000 ; move to first perimeter point G11 ; unretract G1 X80.250 Y109.750 E2.33288 F311.760 ; perimeter G1 X80.250 Y90.250 E4.66576 ; perimeter G1 X99.750 Y90.250 E6.99863 ; perimeter G1 X99.750 Y109.690 E9.32433 ; perimeter G10 ; retract G92 E0 ; reset extrusion distance

and layer 80 looks like : G1 Z20.000 F9000.000 ; move to next layer (79) G1 X99.750 Y109.750 F9000.000 ; move to first perimeter point G11 ; unretract G1 X80.250 Y109.750 E2.33288 F311.760 ; perimeter G1 X80.250 Y90.250 E4.66576 ; perimeter G1 X99.750 Y90.250 E6.99863 ; perimeter G1 X99.750 Y109.690 E9.32433 ; perimeter G10 ; retract G92 E0 ; reset extrusion distance

NB it is probably worth saying I'm using FW retract and Volumetric extruder settings.

BTW thanks to everyone for looking at this.

[galexander1]

When he said 80 steps per mm, he meant 80 microsteps per mm.

Maybe it is a red herring, but I am still blown away when I see "F9000". IIRC when I was calibrating my robot, I found F9000 at the absolute upper end of what it would take, though it is a very different robot than yours. My point is, if that said F1000 instead, I would not give any credence to @orcinus' theory but while it is there, @orcinus' theory is at the front of my mind.

[nophead]

The steps per mm value in the firmware is a misnomer. It is actually pulses on the stepper pin of the driver, which are micro steps, not motor steps, which the firmware knows nothing about.

[nophead]

A motor can only skip multiples of four full steps, which is 0.8mm with 80 steps per mm.

The driver can miss one micro step per direction change if the step signal is inverted or the timing of the dir signal is wrong.

[barneycg]

@nophead right that makes sense thanks for clearing that up. Is that miss one microstep per direction change even if that driver isn't changing direction. In which case am I right in saying there are 5 direction changes per layer which matches with the number of microsteps it is out which implies what you said is the case. Is there anything I can to to determine this and is the cause of it hardware (ie the stepper drivers, RAMPS board or Arduino board) or in the firmware ? I assume the answer to the latter is "it depends" :) ... again anything I can do to get you guys more information.

@galexander1 a) that is only on the z axis move so I don't see how it would have any impact on x or y axis moves - those are F311.760 btw and b) the Feed rate is clamped in firmware to a lower value which Slic3r has absolutely no knowledge of. I can't be sure of the firmware limit and I don't have access to the machine the config file is on from where I a right now but I seem to recall it is 500.

[orcinus]

"and there is no travel except when it moves to the start"

So there is travel :)

[nophead]

If there is not enough time between the dir signal changing and the step signal or vice versa (setup and hold times) the result is undefined but I think it usually makes the first or last step of the line in the wrong direction. That would be a two microstep error and only when dir changes.

There is high speed XY travel every layer according to the gcode.

G1 X99.750 Y109.750 F9000.000 ; move to first perimeter point

[orcinus]

FWIW, i've done feedrates of 14400 and greater with Marlin (SLA machine, double steppers for each axis) at accelerations of 3000 or more and had no issues, so i doubt it's the firmware not keeping up.

I did notice it's fairly easy to cause skipped steps (not just microsteps) when you mess with the stepper interrupt loop (producing shifts like above), but that was due to badly optimized third party code (written by someone else and not part of Marlin). Stock works fine.

[barneycg]

I suppose there is indeed a move ... but look at where it is moving from G1 X99.750 Y109.690 E9.32433 on the layer below. ... that is 0 mm in the x axis and 0.06mm on the y axis, and again I'll say just coz the gcode says go 9000mm/min the firmware can and indeed does override this :)

[nophead]

0.06 on Y at the start of each layer !

Isn't that exactly how much it slants? Seems like a big clue there.

[orcinus]

To eliminate some weird rounding / integer casting error, and out of curiosity, could you change your steps/mm slightly and retest?

[barneycg]

indeed I was just going there mentally after I hit send. It still doesn't quite add up in my head though since if I do 2 shells it works fine and from memory the gcode for that looks pretty much the same but with 2 sets of coordinates ... so if it was a missed step for 1 shell why does it not do the same for 2 shells ? That said once I've got back to my printer I do the following and report back : confirm the firmware max speed. manually set all the speeds in slicer to something really low ... would 5mm/s be low enough ? change my steps/mm for y axis ... any suggestions ?

Did I miss anything ?

[barneycg]

oooh thought ... at 0.06mm that is well into the jerk settings would it be sensible to look at those - I believe mine are currently the default.

[nophead]

It is starting to look like a firmware bug to me as regardless of speed, acceleration and jerk a motor cannot slip 5 micro steps.

But we have a move per layer that seems to be roughly equal to the error. It would actually be 4.8mm not 5mm over the full height, assuming it does the same on the solid layers.

[barneycg]

another thought ... 0.06mm is actually less the calculated offset per layer which was 0.0625 ... and 0.006 / 0.0125 (the distance moved per microstep) = 4.8

So in my ignorance it seems like the firmware needs to make a choice it can either move 4 microsteps, 5 microsteps or just do nothing. Is it even vaguely possible it is choosing the latter ?

[nophead]

It should move 4 or five microsteps, it shouldn't do nothing.

[barneycg]

I like the use of the word "Should" :D

[nophead]

Or if it chose to ignore such a short move it should leave its current position unchanged, so the next move would simply go a bit further. There should never be a cumulative error.

[nophead]

When I do G1 X99.750 Y9.69 (can't go to 109 in my machine) G1 Y9.75 M114 I get X:99.75Y:9.75Z:200.00E:810.84 Count X:99.75Y:9.69Z:200.00 What do the Count numbers mean?

[nicolas-rambaud]

Hello i’ve written an article about how to choose a pulley

https://nutz95.wordpress.com/2014/12/02/reprap-how-to-choose-your-pulleys-for-your-3d-printer/

And a few pulleys size are not adequate depending on your stepper settings.

If you use 16, 20 or 25 teeth with GT2 belt 2mm pitch and 1.8°/step motor you should have integer steps/mm values.

In other cases you will get some rounding errors.

De : Chris [mailto:notifications@github.com] Envoyé : vendredi 9 janvier 2015 17:38 À : MarlinFirmware/Marlin Objet : Re: [Marlin] Odd single thickness wall bug (#853)

Or if it chose to ignore such a short move it should leave its current position unchanged, so the next move would simply go a bit further. There should never be a cumulative error.

— Reply to this email directly or view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/853#issuecomment-69359915.[image: Image supprimée par l'expéditeur.]

[ErikZalm]

The count numbers are position calculated from the stepper pulses. If both are equal then all pulses are generated as expected. I added this because in the beginning many people had slipping pulleys an claimed that it was a firmware fault. This proves that the firmware generated the correct pules.

[ErikZalm]

@nicolas-rambaud I do not understand your calculations. The firmware keeps track of its position with floats. (float)position + (float)steps/mm = position in microsteps. (Rounded but not having a cumulative error) Cumulative errors could be checked with M114.