OctoPrint issues and tips  

Re: OctoPrint issues and tips

Thanks Josef, will test out tonight after work 🙂

Re: OctoPrint issues and tips

Josef,

Just think out aloud here would it not be possible for the raspberry Pi to take over complete control of the printer and thus have a more powerful MPU at your disposable.

The AVR would then only have to handle the driving of steppers effectively becoming a salve to the PI

I see with additional features being added that the overhead problem may become more and more of a problem.

Just a thought

Richard

Re: OctoPrint issues and tips

Downloaded. Installed. Re-printing a previously 2 x failed part through OctoPrint and will report back in a couple hours.

Re: OctoPrint issues and tips

Any thought of changing Y1 to 20, 22.1184, or 24MHz

Re: OctoPrint issues and tips

Just as a data point, running a version of 3.0.12 with Linear Advance with OctoPrint 1.3.5 (and later 1.3.6) on a Raspberry Pi 3 has been working fine on a MK2 for months. From that, I'd say Linear Advance alone is not the main culprit, but certainly adding in the other changes could have pushed things over the edge regarding serial communication.

Send Gina a MK3 to help troubleshoot, and also to make even more of the awesome MK3 features available when printing from OctoPrint!

John

Re: OctoPrint issues and tips

Josef,

Just think out aloud here would it not be possible for the raspberry Pi to take over complete control of the printer and thus have a more powerful MPU at your disposable.

The AVR would then only have to handle the driving of steppers effectively becoming a salve to the PI

There exists a project to do this already:

https://github.com/KevinOConnor/klipper

Looks like a great idea to me. I doubt its been tested with the MK3 yet.

Re: OctoPrint issues and tips

Josef,

Just think out aloud here would it not be possible for the raspberry Pi to take over complete control of the printer and thus have a more powerful MPU at your disposable.

The AVR would then only have to handle the driving of steppers effectively becoming a salve to the PI

I see with additional features being added that the overhead problem may become more and more of a problem.

Just a thought

Richard

i'd rather have a wifi accessible mk3 that i could control from my phone or computer. The pi is a running an os that can buffer, the printer is not.

Re: OctoPrint issues and tips

With 143e I just reprinted a 3 hour print with failed constantly 3 times before through OctoPrint. Using the same gcode.

During the first failed print (black PLA) it seemed like it went into crash recovery mode several times and it shifted the layers a couple of time. I let it continue since it seems like the part would still be usable (yet ugly). I then reprinted it with official Prusa PLA and left it overnight and came to the silver print. Update the firmware this morning to 143e, and used the same g-code as the previous and it printed flawlessly.

Previous Examples of the failed print:

Failed Print 1

Failed Print 2

Successful Print

Whatever you changed in 143e, seems to be working for my Setup:
Original Prusa i3 Mk3 Kit
Firmware 143e
Raspberry Pi 3
OctoPrint 1.3.6

Re: OctoPrint issues and tips

There exists a project to do this already:

https://github.com/KevinOConnor/klipper

Looks like a great idea to me. I doubt its been tested with the MK3 yet.

Looks exactly what I thought of. Would be intresting to see if this could work on the mk3

Re: OctoPrint issues and tips

Whatever you changed in 143e, seems to be working for my Setup:
Original Prusa i3 Mk3 Kit
Firmware 143e
Raspberry Pi 3
OctoPrint 1.3.6

i have had 2 shifted print using current octoprint setup with raspi3 over usb. usually, it hangs up, homes the x axis quickly then goes back to printing. one time, it moved the z axis all the way to the top, then continued printing about .4mm above the layer it stopped at. i really hope this fixes some issues i have had using octoprint.

Re: OctoPrint issues and tips

Hello Guys and greetings from Germany,

Subject / Problem: Shifted layes

After the problem with "Filament auto loading attempt in the middle of the print" was sorted out with the latest firmware I observed a new serious problem with shifted layers.

Setup: Raspberry PI3 with latest octopi image and printer connected via USB
Webcam installed to monitoring the print remotely.
Sliced gcode in S3D.
I checked the Linux system load several times but the load is around 0.14 - 0.04 so very low
I checked the assembly of the printer and ensure a stable stand on the desk and also locked the room.

I checked the Video footage frame by frame but the shift just happened without any physical interference.

Print case:

Filament sensor: on
Fan check: on
Crash detection on

After around 10 - 20 layers of small prints I had 2 prints failed with shifted layers:
Here is one example:

As I read there are some problems with crash detection and USB printing so I turned the crash detection off via the printers menu.
So far so good, fast prints ( 1 - 8 hr time ) were perfectly done (I presented some of them also in the official Facebook group)

Now in a big 24+ hours Print with 0.01mm layer I observed after around 15 hr printing again shifted layers.
Also here room was locked and no physical reason for the shift visible on the Video.

As mentioned before, the same setup with the same S3D profile worked very well with turned off crash detection in a small print.

I will test with the provided Beta firmware here in smaller prints which had problems in the last run and will let you know about the result.

Happy (octo)printing, Cheers Christian.

Re: OctoPrint issues and tips

Tested out tonight.

Mk3 ran M502 then M500 via Pronterface. Disconnected.
Updated FW to B143e.

Latest drivers 2.1.3 installed. 20mm XYZ calibration cube sliced on latest Slic3r Prusa Edition 1.38.6 @ 0.20 FAST MK3, Prusa PET.

Printed via Octoprint 1.3.6, RPi3 connected via USB. Filament Sensor off, Crash Detect on.

Material Prusa PETG Orange (why isn't this the marvellous bright orange your printers are made from Josef? 🙂 ) Print monitored via Octoprint terminal, no errors seen. Print completed successfully ~40 minutes. (Previous attempt to print via Octoprint crashed nozzle into bed on 2nd layer)

Good quality print, sharp corners. Printed size mm x=20.02, y=20.06, z=20.03.

So far looks good, thank you Josef.

(edit) Forgot to mention, Mk3 now has a high pitched whine which was not present before. One of the fans perhaps?

Re: OctoPrint issues and tips

I am running this now on Rpi3, curious if this will fix the PiZero through Serial Port as well?

Re: OctoPrint issues and tips

Updated FW to B143e.
Sliced with Simplify3d lastest FFF (Original Prusa i3 MK3 v2.fff.zip)

Printed something that failed on RC3 with b143e and success! No Issues

Before

After

Re: OctoPrint issues and tips

Subject / Problem: Shifted layes

I will test with the provided Beta firmware here in smaller prints which had problems in the last run and will let you know about the result.

Here are my results:
I printed exact the same GCODE via my USB connected octoprint:

Only difference is I needed to change the Filament as the original Prusa Silver PLA Spool is already done (new Spools ordered from Prusa 😉 ) but as also the new Filament has this issue (see my previous post) I assume it has nothing to do with it.

On the picture you can see the shifted layers and defiantly see some improvements with the beta Firmware.

Question @josefprusa and the Prusa Team:

and please be cautious and monitor the printer.

Is it safe to start a 24h+ print or can something happen which will harm the printer? Otherwise I will wait with bigger prints till the next official Firmware release is available.

Hope this feedback is helpful for you and please let me know if I can help further.

Cheers Christian

Re: OctoPrint issues and tips

After m502/m500, what information is lost? My 'live-z' value seems to be the same. First print seemed to come out fine (actually that was before I did m502/m500 as I was sloppy!)

I'm running xyz cal just in case, but if it's not necessary let us know.

By the way, as you develope to Einsy/32 for the i3 mk4, please make sure there is an upgrade path, and put me on the list as a beta tester!

Re: OctoPrint issues and tips

Printing with 143e, no issues.

Latest version of Octoprint installed from scratch on a raspberry pi3 connected by USB.

Normal mode, crash detect and filament sensor off. Several 30 minute prints at 115k bps

Re: OctoPrint issues and tips

Sorry to hijack the thread, but I'm having some issues with my MK2 MMU and Octoprint which sound like they might be related.

It's horribly unreliable. Just now, 2.5 hours in to a print, the print head moved all the way over to the right and just stopped. Temperatures stayed up. I've had multiple issues over the past few weeks with longer prints doing this. Here are the last few lines of the terminal and some shots of the printer. Note there are resend errors, a "Full RX Buffer" message, and a couple of "Cold Extrusion Prevented" messages (the temperature never dropped, as far as I can tell).

Any thoughts? If I understand correctly, the firmware in the first post is only for MK3.

FW 3.1.0
OctoPrint 1.3.6 running on OctoPi 0.14.0
Raspberry Pi 3

| Last lines in terminal:
| Send: N145176 M204 S800*94
| Recv: ok
| Send: N145177 G1 F3000*124
| Recv: ok
| Send: N145178 G1 X129.907 Y137.621 E0.01021*90
| Recv: ok
| Send: N145179 G1 X129.638 Y137.497 E0.01003*87
| Recv: ok
| Send: N145180 G1 X129.391 Y137.323 E0.01025*91
| Recv: ok
| Send: N145181 G1 X129.176 Y137.113 E0.01015*83
| Recv: ok
| Send: N145182 G1 X129.005 Y136.866 E0.01017*93
| Recv: ok
| Send: N145183 G1 X128.895 Y136.631 E0.00876*94
| Recv: Full RX Buffer
| Recv: ok
| Send: N145184 G1 X128.801 Y136.303 E0.01158*84
| Recv: Error:Line Number is not Last Line Number+1, Last Line: 145181
| Recv: Resend: 145182
2018-01-06 15:35:37,937 - octoprint.util.comm - INFO - Got a resend request from the printer: requested line = 145182, current line = 145185
| Last lines in terminal:
| Send: N145180 G1 X129.391 Y137.323 E0.01025*91
| Recv: ok
| Send: N145181 G1 X129.176 Y137.113 E0.01015*83
| Recv: ok
| Send: N145182 G1 X129.005 Y136.866 E0.01017*93
| Recv: ok
| Send: N145183 G1 X128.895 Y136.631 E0.00876*94
| Recv: Full RX Buffer
| Recv: ok
| Send: N145184 G1 X128.801 Y136.303 E0.01158*84
| Recv: Error:Line Number is not Last Line Number+1, Last Line: 145181
| Recv: Resend: 145182
| Recv: ok
| Send: N145182 G1 X129.005 Y136.866 E0.01017*93
| Send: N145183 G1 X128.895 Y136.631 E0.00876*94
| Recv: echo: cold extrusion prevented
| Recv: ok
| Send: N145184 G1 X128.801 Y136.303 E0.01158*84
| Recv: Error:Line Number is not Last Line Number+1, Last Line: 145181
| Recv: Resend: 145182
2018-01-06 15:35:38,018 - octoprint.util.comm - INFO - Got a resend request from the printer: requested line = 145182, current line = 145186
| Last lines in terminal:
| Recv: Resend: 145182
| Recv: ok
| Send: N145182 G1 X129.005 Y136.866 E0.01017*93
| Send: N145183 G1 X128.895 Y136.631 E0.00876*94
| Recv: echo: cold extrusion prevented
| Recv: ok
| Send: N145184 G1 X128.801 Y136.303 E0.01158*84
| Recv: Error:Line Number is not Last Line Number+1, Last Line: 145181
| Recv: Resend: 145182
| Send: N145182 G1 X129.005 Y136.866 E0.01017*93
| Recv: ok
| Send: N145183 G1 X128.895 Y136.631 E0.00876*94
| Recv: echo: cold extrusion prevented
| Recv: ok
| Send: N145184 G1 X128.801 Y136.303 E0.01158*84
| Recv: ok
| Send: N145185 G1 X128.774 Y136.009 E0.00997*91
| Recv: Full RX Buffer
| Recv: Error:checksum mismatch, Last Line: 145181
| Recv: Resend: 145182

Re: OctoPrint issues and tips

Tested out tonight.

Mk3 ran M502 then M500 via Pronterface. Disconnected.
Updated FW to B143e.

Latest drivers 2.1.3 installed. 20mm XYZ calibration cube sliced on latest Slic3r Prusa Edition 1.38.6 @ 0.20 FAST MK3, Prusa PET.

Printed via Octoprint 1.3.6, RPi3 connected via USB. Filament Sensor off, Crash Detect on.

Material Prusa PETG Orange (why isn't this the marvellous bright orange your printers are made from Josef? 🙂 ) Print monitored via Octoprint terminal, no errors seen. Print completed successfully ~40 minutes. (Previous attempt to print via Octoprint crashed nozzle into bed on 2nd layer)

Good quality print, sharp corners. Printed size mm x=20.02, y=20.06, z=20.03.

So far looks good, thank you Josef.

(edit) Forgot to mention, Mk3 now has a high pitched whine which was not present before. One of the fans perhaps?

Regarding the "high pitched whine": I have /had this as well. The issue was there during the first prints directly after I built my MK3 running FW version 3.1.1 b122 RC1. In my case it was coming from the print cooling fan (not the Noctua fan) and the sound is only present when fan speed is below 90% and loudest around 40-50%. Installed FW version 3.1.1 b122 RC2 and no change. Also tried FW version 3.1.1 b122 RC3 but that gave a lot of issues and I switched back to FW version 3.1.1 b122 RC2. That annoying high pitched noise is still there but without the issues as described in this thread.