[Sticky] OctoPrint issues and tips  

Page 2 / 21
  RSS
joris.m
(@joris-m)
Estimable Member

Does this also impact the mk2s? I am suffering from random disconnects, both while printing and while idle. Using the original Raspberry powersupply and 3.1.0 firmware on my mk2sMMU

Posted : 07/01/2018 7:17 pm
chris.b3
(@chris-b3)
Active Member

Since disabling filament sensor and crash detection I haven't had any issues. I tried re-enabling filament sensor (crash detection still disabled) today (first time since upgrading FW to RC4). I experienced the "Recv: echo:busy: processing" with the first print. Printed fine after disabling filament sensor again.

OctoPrint 1.3.6
RPi 3 Model B via USB (also tried via PC running Ubuntu Mate with OctoPrint 1.36)

...
Posted : 08/01/2018 4:42 am
rapterron
(@rapterron)
Active Member


I experienced the "Recv: echo:busy: processing"

The "echo:busy: processing" is normal, it is a feature implemented in one of the last firmware's to keep the connection to octoprint alive when the printer is doing something which takes some time and has no output (like the mesh leveling, once started octoprint will get an answer after the printer finished it).
Depending on the octoprint timeout setting it could lead octoprint assuming the printer is "dead".

I have something else for this topic:

Mintemp warning causing octoptint problems on initial connection.

Firmware: 143e

My printer stand in an unheated storage room which environment temperature is around 16 - 20 degree.

I know from other topics that the mintemp value is hard coded in the firmware but this cause problems with octoprint as well.
Maybe also an improvement idea to be able to adjust the mintemp value in the printers menu.
I mean 16 degree isn't to cold or? 🙂

The printer reports on power on "Err: MINTEMP" and when I try to connect octoprint it will drop the connection immediately after it was established due to the MINTEMP Error.

Tipp / Workaround:
Make sure the Temperature Thermistors are working fine then preheat the printer via the menu and afterwards connect octoprint and start the print.

Cheers Christian

Posted : 08/01/2018 12:46 pm
radim.h4
(@radim-h4)
Eminent Member

Hi,
yesterday i made fresh new octopi from Prusa.
It works well for 2 short prints. So i start new job over night.
What i saw in the morning?
2 times shifted layers.

- Drivers (sliced by Slic3r) 2.1.3
- FW version 143e
- RPi used Zero W
- Method of the connection - USB
- Filament sensor on
- Crash detection on

I will try to turn off fillament sensor and crash detection off and repeat print.

Sometimes I heard very hard step from motors. Without consequencies, but i have never heard it when i print from SD card. Sounds weird.

Posted : 08/01/2018 2:52 pm
tor martin.o
(@tor-martin-o)
Active Member

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 did the same mistake and on high speed movement it sounds like the steppermotor hits a concrete wall. After doing the M502 and M500 commands it started working correctly

What you should see is this;

Send: M502
Recv: echo:Hardcoded Default Settings Loaded
Recv: ok
Send: M500
Recv: echo:Settings Stored

Posted : 08/01/2018 3:04 pm
simon.m
(@simon-m)
Trusted Member


Sometimes I heard very hard step from motors. Without consequencies, but i have never heard it when i print from SD card. Sounds weird.

I've had this when printing from SD. Most noticeable in Stealth but still occasionally in Normal.
It's a proper 'clunk' like one of the axis has either hit something or stalled heavy. I kept checking the prints expecting the head to have moved out of sync but nothing and the print comes out fine. It's a bit unnerving to keep hearing it in an otherwise fine print.

...
Posted : 08/01/2018 3:22 pm
radim.h4
(@radim-h4)
Eminent Member

I did factory reset and new calibration. It isn't enough?
I don't use Stealth mode anymore.
I will try it to set M502 and M500.

You must either factory reset the printer or run M502 gcode followed by M500.

Posted : 08/01/2018 3:25 pm
tor martin.o
(@tor-martin-o)
Active Member

Factory reset should be enough from what I know but I would try the commands just to be sure. I havent had the clunk sound after doing M502 and M500.

Posted : 08/01/2018 3:33 pm
simon.m
(@simon-m)
Trusted Member

I also did the factory reset and fresh calibration prior to that.

...
Posted : 08/01/2018 3:48 pm
josefprusa
(@josefprusa)
Member Admin

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.

Founder and owner / Majitel a zakladatel...
Posted : 08/01/2018 4:05 pm
radim.h4
(@radim-h4)
Eminent Member

I did M502 and M500. Still crash detection and filament sensor on.
Changed Slic3r setting as Josef wrote.
I even looked at the printer when it happened.
The wounds of the X motor and suddenly a shifted layer.

What next? I'll try to turn off crash detection.

Posted : 08/01/2018 8:50 pm
laurent.m4
(@laurent-m4)
Eminent Member

I am still on RC4 and have been chasing Octoprint reliability issues until I found this thread. I am using the Pi Zero W mounted as per instructions using /dev/ttyAMA0 (per forum thread) and Octoprint 1.3.6.

2 brief findings:
* Using the Octoprint serial dump, I get >2% of commands retried with checksum errors when printing from Octoprint. This results in enough actual errors to get several obvious issues on the prints.
* I tried to print from SD from the front panel and just use Octoprint to monitor (i.e. poll M105 every 10sec), and while I don't know if there was any error (no checksum on the M105), the printer stopped at least once to "wait for user input", so I assume a M105 got garbled and misinterpreted.

All this is with all detections on.

Will be trying the new firmware soon.

Posted : 08/01/2018 10:24 pm
chris.b3
(@chris-b3)
Active Member


Since disabling filament sensor and crash detection I haven't had any issues. I tried re-enabling filament sensor (crash detection still disabled) today (first time since upgrading FW to RC4). I experienced the "Recv: echo:busy: processing" with the first print. Printed fine after disabling filament sensor again.

OctoPrint 1.3.6
RPi 3 Model B via USB (also tried via PC running Ubuntu Mate with OctoPrint 1.36)

Here's video of the issue I was having:

I just made the speed settings Josef mentioned and re-enabled filament sensor and crash detection. Printing now.

...
Posted : 09/01/2018 12:01 am
laurent.m4
(@laurent-m4)
Eminent Member


I am still on RC4 and have been chasing Octoprint reliability issues until I found this thread. I am using the Pi Zero W mounted as per instructions using /dev/ttyAMA0 (per forum thread) and Octoprint 1.3.6.

2 brief findings:
* Using the Octoprint serial dump, I get >2% of commands retried with checksum errors when printing from Octoprint. This results in enough actual errors to get several obvious issues on the prints.
* I tried to print from SD from the front panel and just use Octoprint to monitor (i.e. poll M105 every 10sec), and while I don't know if there was any error (no checksum on the M105), the printer stopped at least once to "wait for user input", so I assume a M105 got garbled and misinterpreted.

All this is with all detections on.

Will be trying the new firmware soon.

Printed the exact same job as in my first finding above (Benchy printed from Octoprint) after firmware upgrade, all sensors/detections ON and got:
* No printing issue
* No checksum error

Note that this is with Octoprint serial.log enabled (to trace the checksum errors), so this may or may not have slowed down the command rate.

Posted : 09/01/2018 2:30 am
radim.h4
(@radim-h4)
Eminent Member

I have bad experience with bigger prints than 3Dbenchy....
Usually, the problem occurs after more than one hour of printing.
Unfortunately... i started print from SD card over night and .... Unseccesfull.... 👿
I wasn't in the mood to take photos... ❗

Posted : 09/01/2018 8:58 am
radim.h4
(@radim-h4)
Eminent Member

So, i' m really upset.
I started new print job withouf OctoPi (even not connected)
Latest drivers 2.1.3, changed some parameters as Josef wrote.
Printed from SD card and layer is shifted again 😈 😈 😈
Filament sensor Off
Crash Detection Off

Photo from OctoPi, but disconnected.

Posted : 09/01/2018 10:07 am
rapterron
(@rapterron)
Active Member

I am printing now the 4 part of a big print (each part take around 7 - 12 hr with the b143e Firmware and all sensors and detections enabled) very successful.

As I am printing very slow ( 0.01 layers at printing speed average 45mm/s and traveling speed 150mm/s sliced in S3D ) I can confirm that the speeds have something to do with this issues.

Besides the mintemp issues on octoprint startup which can be bypassed by pre heating before connecting, the printer prints quite good (fingers crossed).

Posted : 09/01/2018 11:47 am
jmsaltzman
(@jmsaltzman)
Eminent Member


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.

Posted : 09/01/2018 4:11 pm
tor martin.o
(@tor-martin-o)
Active Member



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.

Posted : 09/01/2018 9:05 pm
kelchm
(@kelchm)
Eminent Member

I created this thread a few weeks back to track ideas for things that would improve the OctoPrint and Mk3 user experience.

Posted : 09/01/2018 9:40 pm
Page 2 / 21
Share:

Please Login or Register