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!
Re: Slic3R PE x-2.8 problem
The object being printed is a surfboard fin
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
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
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…
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.
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…
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.