Some bugs find in 1.4.1.2

[TOM YY]

Hi Jonathan,

Frist... Sorry my english not good.

I just download and test 20mm Box and I found some bugs:

1) After slice, in Models+Pahts or  Paths mode, 

    I can't see any layer, every time I move Z layer and it turn to "All Layers" in a second.

   but I fix it by press [Defaults>] button to reset settings.

   

2) G-Code > N[*]Layers  is empty, but every layer it move to some point

    but this time [Defaults>] button can't fix it.

Anyone found bug like me?

TomYY

[meoudon]

I have found bug in gcode about wipe :

 

 G1 X113.52 Y111.81 E4.5989

G1 X113.2 Y112.2 E4.6167

;

; 'Wipe (and De-string) Path', 0.0 [feed mm/s], 20.0 [head mm/s]

G1 X13.2 Y12.2 E3.6167 F900                 <---------------------------------- bug!

G1 X113.2 Y112.2 E3.6167 F1200

G1 X112.81 Y112.52 E3.6167

G1 X112.36 Y112.79 E3.6167

...

...

G1 X92.6 Y92.84 E19.181

G1 X92.6 Y92.14 E19.1935

G1 X93.16 Y91.58 E19.2075

;

; 'Wipe (and De-string) Path', 0.0 [feed mm/s], 20.0 [head mm/s]

G1 X-6.84 Y-8.42 E18.2075 F900                             <---------------------------- bug!

G1 X93.16 Y91.58 E18.2075 F1200

G1 X92.6 Y92.14 E18.2075 

[lonesock (Jonathan)]

Good detective work!  I'm trying to find this bug right now....could anyone zip up a G-code file that has the problem, and attach it here?

thanks,

Jonathan

[lonesock (Jonathan)]

Never mind, I think I found it!

This would only happen at the very beginning of Wipe, and only if you were using an extruder with a non-zero X & Y offset (under the [Extruder Hardware] tab).

Please try out the attached version...if this works I will update the main thread.

thanks,

Jonathan

EDIT: removed attachment...there's a newer one farther down.

[Davide Ardizzoia]

It still does the "homing" thing :-(


Best Regards
Davide Ardizzoia

[lonesock (Jonathan)]

Could you please zip up the G-code file and attach it here?  Please make sure the "[X] Include Comments" is checked in Settings->Printer->Firmware.

thanks!

Jonathan

[Davide Ardizzoia]

Here it is...

Thank You!
Davide Ardizzoia

[lonesock (Jonathan)]

Thanks, Davide.

I could not find anything that would trigger a homing sequence.  After every layer there is a "G92 E0" used to reset the extruder axis...is it possible that is triggering a homing sequence?  It seems your firmware type is "5D - Absolute E"...maybe try changing that to "5D - Abs E no Reset (makerbot)" to see if that makes a difference.

thanks,

Jonathan

[Chris Burger]

"5D - Abs E no Reset (makerbot)" made no difference for me

; 'Wipe (and De-string) Path', 0.0 [feed mm/s], 24.9 [head mm/s]
G1 X-5.6 Y0.91 E66.8199 F2400
G1 X155.5 Y205.16 E66.8199 F1495.6
G1 X156.91 Y203.75 E66.8199
G1 X156.91 Y203.75 Z1.12 E66.8199 F120

see the entire Gcode here                             https://www.dropbox.com/s/y9i0x7j3zaphyem/Gcode%20post-2nd-win32-rebuild_AbsE.gcode

With normal "5D Absolute E"                       https://www.dropbox.com/s/d913ncch6tll40e/Gcode%20post-2nd-win32-rebuild.gcode

I'm keeping all of this in a dropbox folder, if you want it for reference
https://www.dropbox.com/sh/k0mh0kw7tuqh619/3aww9PKj1m
 

[Chris Burger]

Johnathan,
  Is it possible the wipe/destring is somehow set to relative coordinates, regardless of the gcode type? i tried switching to "5D Relative E" Gcode type, and noticed the wipe/destring values are similar, but the Gcode prefix still contains a G90 (absolute mode), which is confusing, i thought "5D Relative E"would imply that G90 should be removed from the prefix. shouldn't "5D Relative E"generate movements in relative mode (g91) ?

[Chris Burger]

oops forgot the link. man i wish you could edit google group posts..

"5D Relative E"
https://www.dropbox.com/s/1vdpnndvxijkt3b/Gcode%20post-2nd-win32-rebuild_relativeE.gcode

[giovanni...@gmail.com]

Hi,

I've sliced the same part with the same ini files, Wipe was disabled but the new version add wipe lines.

[Chris Burger]

sorry to post a million replies, just trying to help.

So, i tried a few setting changes, and i think i've refined the issue.

Turned off wipe, that didn't work, wipe/destring still went to a -value in X and Y. Changed the Wipe value to 0, the error persisted
https://www.dropbox.com/s/1vdpnndvxijkt3b/Gcode%20post-2nd-win32-rebuild_relativeE.gcode

Turned off destring, with wipe still off, and the gcode still has wipe/estring sections somehow, but now they are positive, correct looking values
https://www.dropbox.com/s/1vdpnndvxijkt3b/Gcode%20post-2nd-win32-rebuild_relativeE.gcode

shouldn't this part be non existent with my settings? Settings: https://www.dropbox.com/sh/o71kgqqntm2u3z0/dOWssAlaoc

; 'Wipe (and De-string) Path', 0.0 [feed mm/s], 30.0 [head mm/s]
G1 X151.92 Y201.45 E26.5137
G1 X151.92 Y201.45 Z0.55 E26.5137 F120

[Chris Burger]

Wrong links above.

Wipe off:
https://www.dropbox.com/s/0kuqytzwi4i3h8l/Gcode%20post-2nd-win32-rebuild_5DabsoluteE_wipe-off.gcode

wipe/destring off:
https://www.dropbox.com/s/bcsoqhs9c6npe22/Gcode%20post-2nd-win32-rebuild_5DabsoluteE_wipe-off_destring-off.gcode

[meoudon]

G1 X113.2 Y112.2 E4.6167

;

; 'Wipe (and De-string) Path', 0.0 [feed mm/s], 20.0 [head mm/s]

G1 X13.2 Y12.2 E3.6167 F900                 <---------------------------------- bug!  minus 100

G1 X113.2 Y112.2 E3.6167 F1200

I check all wipe line are minus 100. 

[meoudon]

I have found about this bug. if printer.ini line: 

bed_offset_x_mm=0

bed_offset_y_mm=0

bed_offset_z_mm=0

will destring correct. But if they are  non zero. Destring line will incorrect. Please check you code.

[lonesock (Jonathan)]

More great detective work!  You uncovered another bug!  Try this version:

thanks,

Jonathan

P.S.  I changed the G-code comment to "Destring/Wipe/Jump Path", since those 3 operations may all happen there.  And, if they do happen, they happen in that order.

EDIT: I removed the attachment...the new build is on the main 1.5 preview thread.

[Chris Burger]

https://www.dropbox.com/s/o8ywj0gw4fkgl8p/Gcode_newest%20revision.gcode

It works!! no odd jumps to negative values, thanks!

[lonesock (Jonathan)]

Great!  I will update the main thread in a few hours, and remove this thread's executable.  Please let me know if anyone is still having this problem with this release.

thanks,

Jonathan

[Andrew Rutter]

Fixed it for me too.

Trying to break it with dual extruder prints now.

[Florian Horsch]

The crowd is screaming for a Mac version ;-)

*SCREAAAM* ;-)

Thanks Jonathan!

Florian

[lonesock (Jonathan)]

Heh, this morning I woke up a bit early, specifically to do a Mac build.  However, my daughter woke up early as well, so instead of a Mac build, I ended up reading "Arthur Goes to School".  [8^)  I will try to get you one late tonight.

For right now, I'm updating the Win32 build in the main thread, and then removing the one posted here.

thanks,

Jonathan

[Isaac Thompson]

just sliced another part with the beta, and it's still having the problem where when you try to preview the layers, it only shows the layer you are looking at for about 1/2 second, and then immediately reverts to showing the first layer. i'm using version 1.4.1.3

[lonesock (Jonathan)]

I just figured out how to get the bug to manifest on my system.  I will work on it tonight.

thanks,

Jonathan

[giovanni...@gmail.com]

Hi Jonathan,

on my computer the bug of the preview layers is not always present, when it appears I've to restart the computer and after it's OK.

At the moment I don't have it, if it appears I'll try to see if something will trigger it.

[lonesock (Jonathan)]

Sorry, I forgot to post here!  In the main 1.5 preview thread, I posted an update (1.4.1.4) that (should) fix that bug!

Jonathan

[Jaime García Villena]

I'm getting anomalous layer heights for the raft and for the first layer on the raft.

Let's say: bed roughness=0.05, layer thickness = 0.24.

You would expect these heights: 

layer 1: 0.29, (raft) 

layer 2: 0.53, (raft)

layer 3: 0,77, (part)

... and so on.

but instead, I'm getting:

layer 1: 0.30, (raft) 

layer 2: 0.55, (raft)

layer 3: 0,79, (part)

Is there some setting I'm misinterpreting? This kind of errors lead to lame first layer results, and even warping of the own raft.

I don't know if it is an error of the code, but if it is, it may lead to confuse results...

Thank you.

El sábado, 26 de abril de 2014 02:52:16 UTC+2, TOM YY escribió:

Hi Jonathan,

Frist... Sorry my english not good.

I just download and test 20mm Box and I found some bugs:

1) After slice, in Models+Pahts or  Paths mode, 

    I can't see any layer, every time I move Z layer and it turn to "All Layers" in a second.

   but I fix it by press [Defaults>] button to reset settings.

   

2) G-Code > N[*]Layers  is empty, but every layer it move to some point

    but this time [Defaults>] button can't fix it.

Anyone found bug like me?

TomYY

[jomo]

Hi Jonathan,

On another thread about Skin thickness  we found what we think might be a bug. The mouse over Says "Will make the solid skin of the model this thick (all surfaces: top, sides, bottom)"   but the Skin Thickness setting only seems to affect top and bottom   With side only controlled by loops times extrusion width.  Which is correct?

[frozen...@yahoo.com]

Skin thickness actually does affect all surfaces. This is not a bug. Take a cube and slice it with a skin of 1mm with 1 loop and hollow. The sides will have a single outside loop, with what looks like a partial solid infill to make the sides 1mm thick.

Steve

[frozen...@yahoo.com]

With your settings of 0.1mm skin and .64 extrusion width, you would never see skin thickness with these settings. Number of Loops will not be reduced by skin thickness, and you can't do a 0.1mm side wall with a .64 extrusion width.

On Monday, May 5, 2014 9:36:32 PM UTC-5, jomo wrote:

[jomo]

On Monday, May 5, 2014 11:12:48 PM UTC-5, frozen...@yahoo.com wrote:

Skin thickness actually does affect all surfaces. This is not a bug. Take a cube and slice it with a skin of 1mm with 1 loop and hollow. The sides will have a single outside loop, with what looks like a partial solid infill to make the sides 1mm thick.

Steve

Steve, Thanks for the info. I see now that skin produces solid top and bottom layers equal to the Skin setting  but produces a narrow solid infill to  make up the difference between the Skin setting and the  total of loops * extrusion width.  Thanks