Bug 1152816

Created attachment 947074 [details]
slic3r 1.01 error, second extruder not supported, low gain on extruder motor

If a gcode file is created from slic3r 1.1.7 the fiels will show two filament settings

eg: filament size: 1.75, 1.75

whereas in slic3r 1.0.1

it will read 

    filament size: 1.75 

I could not determine from teh gcode why the second extruder gain is turned way down. It has hoever been tracjked to the slic3r progam and is not a firmware issue.

(In reply to Craig Faas from comment #0)
> Description of problem:  Second extruder motor gain is down in the gcode produced by slic3r 1.0.1.  slic3r 1.1.7 loaded from a tarball could print the same .amf piece well, the secodn extruder motor gain was fine.

When comparing the gcode files between slic3r 1.0.1 and 1.1.7 there is less information for the second extruder in the 1.0.1 version (attached).

The print is stringy from the second extruder and it turns but a a very reduced rate. This si not a hardware or settign issue in slic3r. For whatever reason the secodn extruder motor gain appears turned down. The feed-rate values appear to be correct but it is difficult to tell.

The second extruder x,y locaiotn are fine; elevations are fine; temperautre is fine. Teh printer host (RepetierHost 0.95) extruders correctly when used manually (10mm = 10mm) 

 
> 
> 
> Version-Release number of selected component (if applicable):

slicer 1.0.1 (Fedora 20 stable)

compare with 

slic3r 1.1.7 (Tarball, Fedora 21- under testing)

> 
> 
> How reproducible: 100%
> 
> 
> Steps to Reproduce:
> 1. build .gcode file from .amf (used TWO_COLOR.amf availabel throguh Printrbot) (I can email this to you)
> 2. Print on Reprap/Marlin Printer (Printrbot Go V2)
> 3.wait. 
4. Build .gcode from the same .amf with slic3r 1.1.7 and watch the extruder perform well. 
> 
> Actual results:
> Low 2nd extruder motor gain (low extruder values)
> 
> Expected results:
> Extruder 2 works just the same as extruder 1.  

> 
> Additional info:

Glad to help any way I can. Living in Calgary, can test code at night.

Thanks for reporting. However your report is quite confusing for me.

Could you please provide:

 * 3D model to slice (i.e. the amf file)
 * slic3r configuration (in inf file) that you have used

And describe a way how to tell if the gcode result is OK or not (e.g. telling me that the first G1 command after T1 has a low F value or something like that).

In that case I would be able to recognize if I can reproduce it with slic3r 1.0.1 and slic3r 1.1.7 - and if the situation is the same as you describe (i.e. it is wrong in 1.0.1 and good in 1.1.7), I might be able to locate when the issue was fixed and if possible backport the fix to Fedora 20.

> in inf file
I meant in ini file

(In reply to Miro Hrončok from comment #4)
> > in inf file
> I meant in ini file

Hi Redhat,

Thanks gain for looking at this. I am running Fedora 20 BTW.

Everything you have requested is attached in the email body below. If you are still missing something I don't know what it is.

Attached are the TWO COlOR.amf file (this came from Printrbot and I have
printed successfully with Window slic3r 1.1.7 many times), the .ini file (which has a .txt extension, you'll need to change it back to .ini. The redhat sever rejected my email because of the .ini extension),
and the (4) .gcode files are generated from as follows

TWO COLORslic3r1.0.1FedOct152014.gcode was made using slic3r 1.0.1
installed through yum package manager.

TWO COLORslic3r1.0.1WinOct152014.gcode was made using slic3r 1.0.1 on a
windows 7 machine.

TWO COLORslic3r1.1.7FedOct152014.gcode was made using slic3r 1.1.7
installed through Archive Mounter from a tarball

TWO COLORslic3r1.0.1WINOct152014.gcode was made using slic3r 1.1.7 on a
windows 7 machine.

The .ini file may not help much (attached as .txt). I assured the user permitted values were exact matches. There are some odd differences on the 1.1.7 set; different number of threads,.. some background config stuff. 

The greatest difference and likely where you will see the bug solved in
in the amount of filament used in the 1.0.1 files between Windows and
Fedora slic3r 1.0.1. (Note they use the term filament rather than
extruder 1, extruder 2)

Fedora 1.0.1 
extruder 1 = 244.4mm (0.6cm3)
extruder 2 = 164.4mm (1.2cm3)

Windows 1.0.1
extruder 1 = 244.4mm (0.6cm3)
extruder 2 = 488.5mm (1.2cm3) A > 2 fold difference (our bug, or the
results thereof)


For completeness

Fedora 1.1.7
extruder 1 = 251.6mm (0.6cm3)
extruder 2 = 527.3mm (1.3cm3)

Windows 1.1.7
extruder 1 = 246.6mm (0.6cm3)
extruder 2 = 527.3mm (1.3cm3)

(In reply to Miro Hrončok from comment #4)
> > in inf file
> I meant in ini file

Hi Redhat,

Thanks gain for looking at this. I am running Fedora 20 BTW.

Everything you have requested is attached in the email body below. If you are still missing something I don't know what it is.

Attached are the TWO COlOR.amf file (this came from Printrbot and I have
printed successfully with Window slic3r 1.1.7 many times), the .ini file (which has a .txt extension, you'll need to change it back to .ini. The redhat sever rejected my email because of the .ini extension),
and the (4) .gcode files are generated from as follows

TWO COLORslic3r1.0.1FedOct152014.gcode was made using slic3r 1.0.1
installed through yum package manager.

TWO COLORslic3r1.0.1WinOct152014.gcode was made using slic3r 1.0.1 on a
windows 7 machine.

TWO COLORslic3r1.1.7FedOct152014.gcode was made using slic3r 1.1.7
installed through Archive Mounter from a tarball

TWO COLORslic3r1.0.1WINOct152014.gcode was made using slic3r 1.1.7 on a
windows 7 machine.

The .ini file may not help much (attached as .txt). I assured the user permitted values were exact matches. There are some odd differences on the 1.1.7 set; different number of threads,.. some background config stuff. 

The greatest difference and likely where you will see the bug solved in
in the amount of filament used in the 1.0.1 files between Windows and
Fedora slic3r 1.0.1. (Note they use the term filament rather than
extruder 1, extruder 2)

Fedora 1.0.1 
extruder 1 = 244.4mm (0.6cm3)
extruder 2 = 164.4mm (1.2cm3)

Windows 1.0.1
extruder 1 = 244.4mm (0.6cm3)
extruder 2 = 488.5mm (1.2cm3) A > 2 fold difference (our bug, or the
results thereof)


For completeness

Fedora 1.1.7
extruder 1 = 251.6mm (0.6cm3)
extruder 2 = 527.3mm (1.3cm3)

Windows 1.1.7
extruder 1 = 246.6mm (0.6cm3)
extruder 2 = 527.3mm (1.3cm3)

Created attachment 948992 [details]
Solid Model

Created attachment 948993 [details]
Config File

Must be changed from .txt to .ini to use.

Created attachment 948994 [details]
Slic3r File with Error

see filament used line. This is the file with an error

Created attachment 948995 [details]
Windows output from slic3r 1.0.1 for comparison

Windows generated gcode from slic3r 1.0.1. This file is correct and included for comparison.

Created attachment 948996 [details]
Fedora 20 - slic3r 1.1.7 File - Correct

This is the slic3r 1.1.7 generated gcode in Fedora 20. slic3r 1.1.7 was installed from a tarball.

Created attachment 948998 [details]
Windows slic3r 1.1.7 - Correct

Windows generated gcode from slic3r 1.1.7. It is correct and included for comparison.

Created attachment 948999 [details]
Config file

Thanks, I'll look at it soon.

Ok, when I slice the file with 1.1.7 and 1.1.6 from tarball, I get:

696.71mm of filament used in this print

When I slice the file with 1.0.1 from Fedora 20 package, I get:

388.55mm of filament used in this print

For various crashes, I was not able to run any of version between 1.0.1 and 1.1.6.

I was also not able to run 1.0.1 from the tarball.

Testing on Fedora 21 with 1.1.7 Fedora package uses 696.71mm of filament, so we can tell this is most probably not a packaging error.

I'll try git bisecting it. Hold on.

The amount of filament used in git commits in between those two versions oscilates a lot, I'm not able to tell when the "fix" happened.

I can only recommend to run from tarball until you update to Fedora 21, where this is fixed (1.1.7 is there).

Sorry