Slic3r Generated G-code Files are Truncated When Printed

I encountered a strange problem with Slic3R. I'm using Slic3R Version 1.2.9 running under Linux. The problem occurs with all stl files tried so far when I try slicing them in Slic3r. I'm using a Tevo Tarantula with a large bed, and the dimensions of the large bed have been configured in Slic3R. The stl files come from a variety of sources, including those output by myself from Fusion360, and those downloaded from Thingiverse. The following photograph shows an example of a failed print that was sliced using Slic3r.



What happens with all stl files that I try to slice in Slic3r, is that the rear of the print gets cut off, or if you like truncated. You can see in the above photo of a failed Slic3r print, where the skirt is the correct distance from the print along the sides, but across the rear of the print, the skirt and the print body meet, and in this case the print has been truncated by about 20 mm. The truncation seems to occur on the same place on the bed each time (i.e. about 160mm from the front of the bed), regardless of where the print is positioned on the bed.

If I slice the same stl files with Cura, they print without error.

I've checked that the bed size is set correctly in Slic3r, and it is, so does anyone have any idea why this problem occurs on all attempts to slice with Slic3r, on a wide variety of stl files?

Thanks,

RoyG

It seems the firmware doesn't allow to print negative coordinates and truncates the moves internally.
How did you set the bed origin in slic3r and Cura? Are they the same? ( eg. both have the bed center at 0,0 checked/unchecked ? )

Quote
o_lampe
It seems the firmware doesn't allow to print negative coordinates and truncates the moves internally.
How did you set the bed origin in slic3r and Cura? Are they the same? ( eg. both have the bed center at 0,0 checked/unchecked ? )

Cura has the "Bed Centre a 0,0" unchecked.

Slic3r has home configured as 9,0 (i.e. near left corner) the same as Cura (See screen shot below). Hope that info helps diagnose the problem.

Many thanks,

RoyG

Quote

Slic3r has home configured as 9,0

Is it a mismatch of inch and metric? Do you have a G20 instead of G21 command in your start code?
I'm running out of ideas...

First see whether the issue is with Slic3r or your controller. Make a small print file using a text editor (or send the commands manually):

G1 X0 Y0
G1 X200 Y0
G1 X200 Y260
G1 X0 Y260
G1 X0 Y0

If that results in the head moving along each edge of the bed, the issue is with Slic3r. If not, it is with your controller (disable limiting via "M564 S0" command or set limits set using M208 [reprap.org])

Dave

Quote
dmould
First see whether the issue is with Slic3r or your controller. Make a small print file using a text editor (or send the commands manually):

G1 X0 Y0
G1 X200 Y0
G1 X200 Y260
G1 X0 Y260
G1 X0 Y0

If that results in the head moving along each edge of the bed, the issue is with Slic3r. If not, it is with your controller (disable limiting via "M564 S0" command or set limits set using M208 [reprap.org])

Dave

Dave,

Thanks for that suggestion. I copied and pasted your recommended commands one at a time into the OctoPi's Console. The print head initially moved to the front left 0,0 position, and then tracked around the perimeter of the print bed and back to 0,0. So, it seems that my Controller is OK. Is this a bug with Slic3r that I should report to [github.com] ?

Thanks,

RoyG

Slice the attached STL using a layer height of 0.25mm and upload the resulting G-code file here and I'll take a look.

Dave