Re: OctoPrint issues and tips
Did you remember to do the M502 and M500 to load the new configuration? This has to be done _after_ upgrading the firmware to B143E.
I ran the commands before updating to b143e, and I was bummed to see continued layer shifts. Running them after... prints look good!
There should be a short text file included in the b143e zip file 😉
btw this is with a Pi Zero W on USB. I removed the webcam to lighten its load. I'll run a print with the Pi on the Einsy tonight and see how it goes.
I highly recommend using the RPi3 for octoprint. To me the PiZeroW dosent seem strong enough to compliment the Prusa I3 printer for what it is. On the Rpizero Octoprint just feels amazingly slow compared to the Rpi3.
That's interested idea. But it doesn't solve my problem with shifted layers even without OctoPi.
I suspected the OctoPi and found that it did not work even without OctoPi.
Re: OctoPrint issues and tips
I ran the commands before updating to b143e, and I was bummed to see continued layer shifts. Running them after... prints look good!
There should be a short text file included in the b143e zip file 😉
btw this is with a Pi Zero W on USB. I removed the webcam to lighten its load. I'll run a print with the Pi on the Einsy tonight and see how it goes.
I highly recommend using the RPi3 for octoprint. To me the PiZeroW dosent seem strong enough to compliment the Prusa I3 printer for what it is. On the Rpizero Octoprint just feels amazingly slow compared to the Rpi3.
That's interested idea. But it doesn't solve my problem with shifted layers even without OctoPi.
I suspected the OctoPi and found that it did not work even without OctoPi.
In terms of your problem I think it might be caused by belt tension. I had the exact same problem as you with my printer and I believe its your x axis belt tention that is not "taught" enough. I retightend my belts today as they had become fairly loose after running around 80 hoursish of prints now. I used a buddy of mines mk3 as a reference point as belt tension seems more as a "feel" you will get after getting some experience with 3d printers.
Why it happens at that specific layer height I cant comment on. Maybe someone more experienced can comment on why it happens at higher layer heights?
EDIT: The comment on the raspberry pi zero was more ment towards the frontend interface of octoprint which seems to be alot slower on older rpis or the raspberry pi zero. I've managed to test rpi zero, rpi b+, rpi2 and rpi3 and to me the rpi3 is by far the best. In terms of serial communication towards the einsy board I dont think octoprint is "bogged" down by to many processes running on the rpi as serial communication is quite a simple task. The communication problem with octoprint Josef Prusa has already commented on which was/is related to the linear advance feature from what I could understand
Re: OctoPrint issues and tips
For me, all issues (including several layer shifts) had been caused by what I assume is UART fifo overflow conditions on the Rambo, as evidenced by lots (hundreds) of Checksum errors. These show up in octoprint.log, so it should be easy to see if there are any left (I have attempted more complex prints and haven't had a single one with the new FW).
Example:
2018-01-07 02:17:58,784 - octoprint.util.comm - INFO - Got a resend request from the printer: requested line = 119, current line = 120
| Last lines in terminal:
| Recv: ok
| Send: N111 G1 X109.815 Y138.815 E0.01677*102
| Recv: ok
| Send: N112 G1 X115.578 Y144.578 E0.25591*110
| Recv: ok
| Send: N113 G1 X116.112 Y144.578 E0.01677*105
| Recv: ok
| Send: N114 G1 X109.815 Y138.281 E0.27962*107
| Recv: ok
| Send: N115 G1 X109.815 Y137.747 E0.01677*101
| Recv: ok
| Send: N116 G1 X116.646 Y144.578 E0.30333*109
| Recv: ok
| Send: N117 G1 X117.180 Y144.578 E0.01677*103
| Recv: ok
| Send: N118 G1 X109.815 Y137.213 E0.32705*104
| Recv: ok
| Send: N119 G1 X109.815 Y136.679 E0.01677*100
| Recv: Error:checksum mismatch, Last Line: 118
| Recv: Resend: 119
Re: OctoPrint issues and tips
Well, I tried to print a larger item (Treefrog in 300%) and so far 3 out of 3 died from layer shift. I did a full reset and recalibrate after upgrading the firmware.
Here is a pic of the last one, which I let run to completion. A seriously shifted frog! (8 total).
I did get _one_ error out of all the prints in octoprint.log
2018-01-10 14:01:58,341 - octoprint.util.comm - INFO - Got a resend request from the printer: requested line = 765013, current line = 765015
| Last lines in terminal:
| Recv: ok
| Send: N765009 G1 X148.148 Y60.635 E0.01988*97
| Recv: ok
| Send: N765010 G1 X148.675 Y60.674 E0.01376*110
| Recv: ok
| Send: N765011 G1 X150.333 Y61.087 E0.04454*104
| Recv: ok
| Send: N765012 G1 X151.387 Y61.553 E0.03002*105
| Recv: ok
| Send: N765013 G1 X151.766 Y61.745 E0.01107*96
| Recv: echo:enqueing "G1 Z 78.147 E 0.000 F 800.000"
| Recv: echo:enqueing "CRASH_DETECTED"
| Recv: echo:enqueing "G28 X"
| Recv: echo:enqueing "G28 Y"
| Recv: echo:enqueing "CRASH_RECOVER"
| Recv: echo:busy: processing
| Recv: ok
| Send: N765014 M105*22
| Recv: Error:Line Number is not Last Line Number+1, Last Line: 765012
| Recv: Resend: 765013
Re: OctoPrint issues and tips
Well, I tried to print a larger item (Treefrog in 300%) and so far 3 out of 3 died from layer shift. I did a full reset and recalibrate after upgrading the firmware.
Here is a pic of the last one, which I let run to completion. A seriously shifted frog! (8 total).
20180110_063840.jpg
I did get _one_ error out of all the prints in octoprint.log
2018-01-10 14:01:58,341 - octoprint.util.comm - INFO - Got a resend request from the printer: requested line = 765013, current line = 765015
| Last lines in terminal:
| Recv: ok
| Send: N765009 G1 X148.148 Y60.635 E0.01988*97
| Recv: ok
| Send: N765010 G1 X148.675 Y60.674 E0.01376*110
| Recv: ok
| Send: N765011 G1 X150.333 Y61.087 E0.04454*104
| Recv: ok
| Send: N765012 G1 X151.387 Y61.553 E0.03002*105
| Recv: ok
| Send: N765013 G1 X151.766 Y61.745 E0.01107*96
| Recv: echo:enqueing "G1 Z 78.147 E 0.000 F 800.000"
| Recv: echo:enqueing "CRASH_DETECTED"
| Recv: echo:enqueing "G28 X"
| Recv: echo:enqueing "G28 Y"
| Recv: echo:enqueing "CRASH_RECOVER"
| Recv: echo:busy: processing
| Recv: ok
| Send: N765014 M105*22
| Recv: Error:Line Number is not Last Line Number+1, Last Line: 765012
| Recv: Resend: 765013
Sorry, but i'm really glad that i'm not alone. I have axactly same issues.
I hope Prusa fix it soon.
Re: OctoPrint issues and tips
Sorry, but i'm really glad that i'm not alone. I have axactly same issues.
I hope Prusa fix it soon.
Have you adjusted the travel speed and infill acceleration as Josef suggested?
Re: OctoPrint issues and tips
I FOLLOWED THE PROCEDURE TO UPDATE TO 143e, tried a print over usb in octoprint(latest version) and prined the roman Colosseum. after about 6mm, it shifted layers(2nd pic). after that, i unplugged octoprint, and resliced it using slic3r pe that was in drivers 2.1.3. i printed (unteathered) STRAIGHT FROM THE SD CARD WITH ALL SENSORS AND FEATURES ENABLED. it once again shifted layers. very frustrating. previously, i have only had shifted layers when printing over usb and octoprint. yesterday (still unteathered) printed a lithophane. over half way up, it shifted layers on the x axis and about 5mm above that, it shifted back to the origonal position(1st pic pic).
1 https://imgur.com/a/xmWkN
Re: OctoPrint issues and tips
- Switched yesterday from 3.1.1 b138 RC3 to the 143e release.
- Did send the M502 and M500 commands after the firmware upgrade
- Crash detection and Filament sensor switched to Off
- Connection through Raspberry Pi 3 Model B connected through USB
- Latest version of Octoprint
- Sliced with latest version of Slic3r (1.38.6 Prusa edition)
Result: 3 times a layer shift in the Y direction. One in the 2nd layer, one approx at the 28th layer and as it looks a minor shift near the top. I am going back to the RC3 candidate which was more stable in my case.
EDIT: I did NOT reduce the Travel speed to 200 mm/s and the Infill to 1500mm^2/s as suggested (Only read this now...sorry)
Re: OctoPrint issues and tips
Have you adjusted the travel speed and infill acceleration as Josef suggested?
Trying again with the modified speeds.
Re: OctoPrint issues and tips
Hi all,
also had lot of shifts and "crash" triggers.
issues via octoprint and direct SD
now running the new firmware and using the latest drivers.
and adjustment of speed settings in slic3r, like Josef posted.
printed via octoprint and no issues after 12 hours of printing.
looks like we are heading the right direction.
without the speed adjustment, i noticed that the printed seemed to hit a virtual wall. that it outruns itself.
then you hear the extruder body halting apprupt (or something like that) difficult to explain... 😉
@josefprusa keep on tweaking the settings, we will get there
regards Ron
Re: OctoPrint issues and tips
Have you adjusted the travel speed and infill acceleration as Josef suggested?
Trying again with the modified speeds.
Better with the speed modifications, but still 2 layer shifts.
Re: OctoPrint issues and tips
Wanted to provide another OctoPrint data point:
I've got a MK3 kit and it's been printing fine from the SD card with firmware 3.1.1 RC4 B143 .
Using Slic3r Prusa Edition v1.38.7
I installed the 143e firmware, did a M502 gcode followed by M500
Using OctoPrint v1.3.6, a Raspberry PI 3 and USB cable.
Crash and Filament detection were on.
Printed the Automatic Transmission annulus (HatchBox Red ABS)
As can be seen in picture IMG_0201, layer shift.
I reloaded the RC4 B143 firmware, did a factory reset -> erase data
Printed same gcode file from SD card - looks good as seen in picture IMG_0203.
Crash and Filament detection were on.
I did print a 3D Benchy in Prusa silver PLA from the OctoPI and it printed fine except for some cooling issues on bow halfway up.
I can test the next firmware version when it's available.
Overall printer is nice - would like to get OctoPrint working. Thanks.
Re: OctoPrint issues and tips
I'm still trying print without OctoPi, but shifted layers are when i print from SD card.
FW 143e
Crash Detection OFF
Filament sensor OFF
BTW: now is shifted Y axis.....
I'll try to switch back to FW 143.
Re: OctoPrint issues and tips
Is it possible to use octoprint only to monitor the printer and take a timelapse while printing directly from the SD-card?
Re: OctoPrint issues and tips
I'm still trying print without OctoPi, but shifted layers are when i print from SD card.
FW 143e
Crash Detection OFF
Filament sensor OFF
BTW: now is shifted Y axis.....
I'll try to switch back to FW 143.
shifted layers 4.jpg
Out of interest, what are the numbers for you belts in Support\Belt Status ?
Also, did you see Josef's mention the other day about adjusting speeds in slic3r as it was possibly too fast for the motors to handle.
I just got more info about the layershifts.
As I calibrated the max acceleration ans peed of printer with broken linear advance, it is now pushing more than it can do, especially on user build printers.
So open Slic3r and under the speed tab, reduce the travel speed to 200mm/s and infill acceleration from 3500 to 1500mm^2/s. We are running the tests now.
Did you make those changes and then re-slice ?
Re: OctoPrint issues and tips
Hey Guys,
I observed a new additional problem to the shifted layers.
Shifted layers + clogged nozzle (and a not recognizing Filament sensor)
This time in addition to a small shifted layer also my nozzle clogged during this (well bad things happen sometime) but the Filament sensor which was turned on did not recognized that the filament stopped moving.
In the morning while checking the 24h print I found the printer still printing invisible filament.
Settings and used Filament:
Firmware: b143e
Filament sensor: on
Crash detection: on
Fan check: on
Filamen: original Prusa PLA silver (manufactured 19.12.2017)
Re: OctoPrint issues and tips
I'm still trying print without OctoPi, but shifted layers are when i print from SD card.
FW 143e
Crash Detection OFF
Filament sensor OFF
BTW: now is shifted Y axis.....
I'll try to switch back to FW 143.
shifted layers 4.jpg
Out of interest, what are the numbers for you belts in Support\Belt Status ?
Also, did you see Josef's mention the other day about adjusting speeds in slic3r as it was possibly too fast for the motors to handle.
I just got more info about the layershifts.
As I calibrated the max acceleration ans peed of printer with broken linear advance, it is now pushing more than it can do, especially on user build printers.
So open Slic3r and under the speed tab, reduce the travel speed to 200mm/s and infill acceleration from 3500 to 1500mm^2/s. We are running the tests now.
Did you make those changes and then re-slice ?
As i wrote before. YES. I changed travel speed, acceleration and resliced.
Belt status: X 274 Y 270
Changed FW back to 143 and after 2 hours still looks good.
Octopi disconnected.
Re: OctoPrint issues and tips
Sorry, I did have a quick scan through but I missed the post where you said you made Josef's speed adjustments.
If it's of any use my belts are
X - 273
Y - 249
I get no layer shifts in either printing from SD card or USB direct from slic3r. Not tried OctoPi yet.
Firmware: b143e
Filament sensor: on
Crash detection: on
Fan check: on
Maybe try to slacken the Y belt a bit if it's only that one that's shifting?
Just as a note from my side.
The weirdest part on mine was that when I was getting layer shifts (from printing in stealth mode) they would correct every so often but they weren't at a random point, they appeared to be exactly where they ought to be for a correct print.
To me, that doesn't sound like a mechanical shift but rather a data shift. e.g. for some reason +20 got applied to the Y value or something and then went back to normal after.
Re: OctoPrint issues and tips
I've been using 143e for a few days now, using OctoPrint via built-in RPI on the second UART. I have not seen any issues due to communication failures. I've been printing in stealth mode, so no collision detection. Filament sensor on.
That said, after first installing 143e, I did experience lots of Y layer shifts, and first suspected the firmware, since 143e inexplicably fiddled with the acceleration limit in stealth mode, but it turned out not to be firmware related. After long investigation, I found out that the layer shifts were always a multiple of the belt tooth distance. Even though my Y belt tension showed as 250 and felt pretty tight, the belt was rubbing against the motor side of the pulley and occasionally managed to ride up enough on the side to skip. I tightened the belt another notch and reversed the Y pulley, so the belt could move closer to the motor without rubbing on the side. All good now. By the way, the belt tension number seems to be pretty unreliable. Running the self-test multiple times gets me values that vary by about 30 points.
Re: OctoPrint issues and tips
Can FW 143e also be used for a i3 MK2 MM upgraded printer ?