Slic3R PE x-2.8 problem

MrMik

(@mrmik)

Honorable Member

Slic3R PE x-2.8 problem

Hi,
I'm using Slic3r Prusa Edition Slic3r-1.39.1-beta1-prusa3d-linux64-full-201802221542.AppImage in Ubuntu and I have had several occurrences of gcode files with impossible x positions.

For example the latest one shown below:
G1 X230.388 Y20.580 E0.01562 ; infill G1 X230.477 Y20.535 E0.00519 ; infill M204 S1000 ; adjust acceleration G1 E-1.00000 F2100.00000 ; retract G1 Z79.000 F7200.000 ; lift Z G1 X34.639 Y118.587 F7200.000 ; move to first perimeter point G1 X24.280 Y139.887 F7200.000 ; move to first perimeter point G1 X11.390 Y167.450 F7200.000 ; move to first perimeter point G1 X8.802 Y171.849 F7200.000 ; move to first perimeter point G1 X-1.525 Y193.274 F7200.000 ; move to first perimeter point G1 X-2.449 Y195.775 F7200.000 ; move to first perimeter point G1 X-2.810 Y197.517 F7200.000 ; move to first perimeter point G1 X-2.809 Y199.112 F7200.000 ; move to first perimeter point G1 X-2.391 Y202.411 F7200.000 ; move to first perimeter point G1 X-0.979 Y202.046 F7200.000 ; move to first perimeter point G1 X23.856 Y190.474 F7200.000 ; move to first perimeter point G1 Z78.800 F7200.000 ; restore layer Z G1 E1.00000 F2100.00000 ; unretract M204 S800 ; adjust acceleration G1 F2400 G1 X23.689 Y190.264 E0.01354 ; perimeter G1 X71.702 Y152.073 E3.09826 ; perimeter G1 X67.424 Y146.694 E0.34709 ; perimeter

As you can see, the extruder is supposed to move to x-2.8 and that will cause a layer shift.

I had similar problems with x251 or x252 values in the past, so I always search the gcode file for "x-" and 'x251' before embarking on a long print.

I think it is caused by some attempt by Slic3r to not cross perimeters or whatever.

I cannot be bothered re-slicing until I randomly get a useable gcode file and I don't have time to trouble shoot this properly at the moment.

So my question is if I can use a quick and dirty fix by editing the gcode manually.

I hope I can simply change the offending impossible x values to zero, so that instead of

G1 X8.802 Y171.849 F7200.000 ; move to first perimeter point
G1 X-1.525 Y193.274 F7200.000 ; move to first perimeter point
G1 X-2.449 Y195.775 F7200.000 ; move to first perimeter point
G1 X-2.810 Y197.517 F7200.000 ; move to first perimeter point
G1 X-2.809 Y199.112 F7200.000 ; move to first perimeter point
G1 X-2.391 Y202.411 F7200.000 ; move to first perimeter point
G1 X-0.979 Y202.046 F7200.000 ; move to first perimeter point
G1 X23.856 Y190.474 F7200.000 ; move to first perimeter point

the new gcode will read:

G1 X8.802 Y171.849 F7200.000 ; move to first perimeter point
G1 X0 Y193.274 F7200.000 ; move to first perimeter point
G1 X0 Y195.775 F7200.000 ; move to first perimeter point
G1 X0 Y197.517 F7200.000 ; move to first perimeter point
G1 X0 Y199.112 F7200.000 ; move to first perimeter point
G1 X0 Y202.411 F7200.000 ; move to first perimeter point
G1 X0 Y202.046 F7200.000 ; move to first perimeter point
G1 X23.856 Y190.474 F7200.000 ; move to first perimeter point

Is that feasible or is it not possible to simply change one part of the moving instructions without adjusting he other parts (like the y-value)?

Any help would be much appreciated!

Respondido : 13/05/2018 4:23 am

MrMik

(@mrmik)

Honorable Member

Topic starter answered:

Re: Slic3R PE x-2.8 problem

The object being printed is a surfboard fin

Respondido : 13/05/2018 4:28 am

MrMik

(@mrmik)

Honorable Member

Topic starter answered:

Re: Slic3R PE x-2.8 problem

After searching he gcode file a bit more, I realised that all x values are expressed as x.xxx.

I'm not certain but I assume that I need to use x0.000 instead of x0

I'll try it out and see what happens....

gcode edited to:

G1 X8.802 Y171.849 F7200.000 ; move to first perimeter point
G1 X0.000 Y193.274 F7200.000 ; move to first perimeter point
G1 X0.000 Y195.775 F7200.000 ; move to first perimeter point
G1 X0.000 Y197.517 F7200.000 ; move to first perimeter point
G1 X0.000 Y199.112 F7200.000 ; move to first perimeter point
G1 X0.000 Y202.411 F7200.000 ; move to first perimeter point
G1 X0.000 Y202.046 F7200.000 ; move to first perimeter point
G1 X23.856 Y190.474 F7200.000 ; move to first perimeter point

Respondido : 13/05/2018 4:45 am

MrMik

(@mrmik)

Honorable Member

Topic starter answered:

Re: Slic3R PE x-2.8 problem

The manual editing as described above worked well. The print breezed past the z78.8 level without a hitch.

The next fin's gcode file has a whopping 3 occurrences of x-0.2 . I have edited them the x0.000 and hopr for the best...

faulty with x-2 occurrences 3 times


    harmless one:

        G1 X1.036 Y203.427 E0.01904 ; brim

        G1 X0.583 Y202.729 E0.02741 ; brim

        G1 X0.190 Y201.907 E0.02997 ; brim

        G1 X-0.101 Y201.040 E0.03012 ; brim

        G1 X-0.287 Y200.156 E0.02975 ; brim

        G1 X-0.381 Y199.241 E0.03026 ; brim

        G1 X-0.383 Y198.299 E0.03102 ; brim

        G1 X-0.295 Y197.335 E0.03186 ; brim

        G1 X-0.117 Y196.357 E0.03272 ; brim

        G1 X0.149 Y195.373 E0.03357 ; brim

        G1 X0.503 Y194.373 E0.03492 ; brim
    harmless two:

        G1 X0.260 Y200.931 E0.02863 ; brim

        G1 X0.084 Y200.088 E0.02834 ; brim

        G1 X-0.004 Y199.213 E0.02897 ; brim

        G1 X-0.006 Y198.307 E0.02982 ; brim

        G1 X0.077 Y197.394 E0.03018 ; brim

        G1 X0.250 Y196.448 E0.03167 ; brim
    1

        before editing:

            G1 X2.194 Y187.504 F7200.000 ; move to first perimeter point

            G1 X-2.882 Y198.027 F7200.000 ; move to first perimeter point

            G1 X-2.948 Y199.017 F7200.000 ; move to first perimeter point

            G1 X-1.237 Y203.917 F7200.000 ; move to first perimeter point

            G1 X5.712 Y205.257 F7200.000 ; move to first perimeter point

            G1 Z21.500 F7200.000 ; restore layer Z

            G1 E1.00000 F2100.00000 ; unretract

        after editing:

            G1 X3.102 Y185.046 F7200.000 ; move to first perimeter point

            G1 X2.194 Y187.504 F7200.000 ; move to first perimeter point

            G1 X-0.000 Y198.027 F7200.000 ; move to first perimeter point

            G1 X-0.000 Y199.017 F7200.000 ; move to first perimeter point

            G1 X-0.000 Y203.917 F7200.000 ; move to first perimeter point

            G1 X5.712 Y205.257 F7200.000 ; move to first perimeter point

            G1 Z21.500 F7200.000 ; restore layer Z
    2

        before

            G1 X10.451 Y169.810 F7200.000 ; move to first perimeter point

            G1 X2.977 Y185.307 F7200.000 ; move to first perimeter point

            G1 X2.079 Y187.742 F7200.000 ; move to first perimeter point

            G1 X-2.882 Y198.027 F7200.000 ; move to first perimeter point

            G1 X-2.948 Y199.017 F7200.000 ; move to first perimeter point

            G1 X-1.237 Y203.917 F7200.000 ; move to first perimeter point

            G1 X5.712 Y205.257 F7200.000 ; move to first perimeter point

            G1 Z23.000 F7200.000 ; restore layer Z

            G1 E1.00000 F2100.00000 ; unretract

        after

            G1 X2.977 Y185.307 F7200.000 ; move to first perimeter point

            G1 X2.079 Y187.742 F7200.000 ; move to first perimeter point

            G1 X-0.000 Y198.027 F7200.000 ; move to first perimeter point

            G1 X-0.000 Y199.017 F7200.000 ; move to first perimeter point

            G1 X-0.000 Y203.917 F7200.000 ; move to first perimeter point

            G1 X5.712 Y205.257 F7200.000 ; move to first perimeter point

            G1 Z23.000 F7200.000 ; restore layer Z

3 before G1 Z79.000 F7200.000 ; lift Z G1 X35.119 Y118.240 F7200.000 ; move to first perimeter point G1 X24.484 Y140.104 F7200.000 ; move to first perimeter point G1 X9.325 Y172.546 F7200.000 ; move to first perimeter point G1 X-0.977 Y193.927 F7200.000 ; move to first perimeter point G1 X-2.008 Y196.792 F7200.000 ; move to first perimeter point G1 X-2.302 Y198.843 F7200.000 ; move to first perimeter point G1 X-2.069 Y200.896 F7200.000 ; move to first perimeter point G1 X-1.099 Y203.806 F7200.000 ; move to first perimeter point G1 X22.116 Y191.799 F7200.000 ; move to first perimeter point G1 Z78.800 F7200.000 ; restore layer Z G1 E1.00000 F2100.00000 ; unretract M204 S800 ; adjust acceleration after G1 X35.119 Y118.240 F7200.000 ; move to first perimeter point G1 X24.484 Y140.104 F7200.000 ; move to first perimeter point G1 X9.325 Y172.546 F7200.000 ; move to first perimeter point G1 X-0.000 Y193.927 F7200.000 ; move to first perimeter point G1 X-0.000 Y196.792 F7200.000 ; move to first perimeter point G1 X-0.000 Y198.843 F7200.000 ; move to first perimeter point G1 X-0.000 Y200.896 F7200.000 ; move to first perimeter point G1 X-0.000 Y203.806 F7200.000 ; move to first perimeter point G1 X22.116 Y191.799 F7200.000 ; move to first perimeter point G1 Z78.800 F7200.000 ; restore layer Z G1 E1.00000 F2100.00000 ; unretract M204 S800 ; adjust acceleration

Respondido : 13/05/2018 2:23 pm

PJR

(@pjr)

Antient Member Moderator

Re: Slic3R PE x-2.8 problem

Hi MrMik!

Yes, it is possible to amend the G-code and as long as X is followed by a valid digit (e.g. 0) that's fine, you do not have to add a decimal point.

However, the bounds of the printer are set in firmware. If the firmware sees a G-code command outside of the limit, it should simply move to the limit and no further. You should not experience layer shifts at all.

Peter

Please note: I do not have any affiliation with Prusa Research. Any advices given are offered in good faith. It is your responsibility to ensure that by following my advice you do not suffer or cause injury, damage…

Respondido : 14/05/2018 12:09 pm

MrMik

(@mrmik)

Honorable Member

Topic starter answered:

Re: Slic3R PE x-2.8 problem

Thanks Peter!

I have noticed before that the brim extrusion is suppressed automatically when it is programmed to exceed the print bed size. And no extra filament seems to be extruded when the extruder crosses the same line again for a couple of times. But maybe that's just because the previously extruded material stops the fresh stuff from coming out of the nozzle.

But, I have seen several very clean layer shifts (at 8hrs or so into a 16hr print) caused by Slic3r telling the extruder to move to X252 or thereabouts. I thought they were random errors or some other cause of layer shift, until it clicked and I found the connection. I am certain this problem exists and can be prevented by searching he Gcode file for x251, x252, x253 and x- occurrences.

I keep a quite comprehensive record of the OpenScad, STL and GCODE files created during my efforts. That's why I am certain that the actually printed layer shifts were due to the same error.

Respondido : 14/05/2018 1:52 pm

PJR

(@pjr)

Antient Member Moderator

Re: Slic3R PE x-2.8 problem

Yeah I understand what you are saying and it is possible that the firmware has been changed since I last saw these problem myself.

Generally when you hit the firmware limits, the extruder keeps operating, so as you suggest in your case it probably skipped.

The other possibility is that the extruder is physically limited (on the right), where the firmware limit is 255 and is only able to get to (say) 250.0 before making contact with the right hand frame, and that would definitely cause a layer shift. This would not happen on the left as the X_MIN is at zero - which is the end-stop.

Peter

Please note: I do not have any affiliation with Prusa Research. Any advices given are offered in good faith. It is your responsibility to ensure that by following my advice you do not suffer or cause injury, damage…

Respondido : 14/05/2018 2:02 pm

Vojtěch Bubník

(@vojtech-bubnik)

Miembro Admin

Re: Slic3R PE x-2.8 problem

> The other possibility is that the extruder is physically limited (on the right), where the firmware limit is 255 and is only able to get to (say) 250.0 before making contact with the right hand frame, and that would definitely cause a layer shift. This would not happen on the left as the X_MIN is at zero - which is the end-stop.

Slic3r does not currently limit the brim, skirt or support extrusion outside the printer working space. We should improve upon that. The upcoming Slic3r 1.40.0 (the alpha is already out) at least tests for the objects outside the build space.

The firmware should limit the working space before reaching the physical end stop, therefore there should be no layer shift. If it is so, then there is an issue with the firmware machine limits.

Respondido : 15/05/2018 7:46 am