Notifications
Clear all

OctoPrint issues and tips  

Strona 6 / 23
  RSS
jweaver
(@jweaver)
Honorable Member
Re: OctoPrint issues and tips


At wifi speed? No-go... Indeed Octopi is connected to PC with wifi. So, from PC to RPi could go with wifi speed. BUT connection from RPi to Prusa's SD card is via AVR's USART, which is connected to RPi with speed 115200 baud, so theoretically it would take maximum 115kbytes per second or over 10 seconds for 1MB file. Well, in practice from my tests this speed is one tenth of this.

Still confused. I thought the point of using a Pi was that you print from Octopi and don't have to transfer files to the Printers SD...

I thought you simply sliced the model.. Transferred it to the Octopi SD, and then using the Octopi software and printed from there...

I know its broken and right now the best way is to use the Printers SD card, but when Octopi is working, I was under the impression you no longer used the SD card in the printer...

Am I misunderstanding the whole process?

Opublikowany : 17/01/2018 5:16 pm
Protoncek
(@protoncek)
Reputable Member
Re: OctoPrint issues and tips

No, the point of octoprint is exactly what you say. However, it IS possible also to transfer file to SD card and print from there. Advantage? Well, printing from PC via octopi goes this way:

PC -->wifi -->Rpi -->UART (serial connection) -->Einsy board.

So, in this mode 3 things can go wrong: PC can freeze/die. Wifi can freeze/die or received command can be wrong. RPi can freeze/die. transfer from RPi via UART to einsy can be bad...

When printing from SD all above dangers dissapear. That's why i don't print like that, always directly from SD card. I have CNC machine without SD card reader so i print via USB. It happened a few times that PC froze and ruined my work...

Note that printing from PC requires only a small bitrate speed as commands go from PC to printer one by one and with actual print speed, while if you copy whole file to SD card whole file must be transferred before you can print from SD.

Opublikowany : 17/01/2018 5:31 pm
jweaver
(@jweaver)
Honorable Member
Re: OctoPrint issues and tips


No, the point of octoprint is exactly what you say. However, it IS possible also to transfer file to SD card and print from there. Advantage? Well, printing from PC via octopi goes this way:

PC -->wifi -->Rpi -->UART (serial connection) -->Einsy board.

So, in this mode 3 things can go wrong: PC can freeze/die. Wifi can freeze/die or received command can be wrong. RPi can freeze/die. transfer from RPi via UART to einsy can be bad...

When printing from SD all above dangers dissapear. That's why i don't print like that, always directly from SD card. I have CNC machine without SD card reader so i print via USB. It happened a few times that PC froze and ruined my work...

Note that printing from PC requires only a small bitrate speed as commands go from PC to printer one by one and with actual print speed, while if you copy whole file to SD card whole file must be transferred before you can print from SD.

At the moment, I print via USB from CURA to a Printrbot and have done for years without a single issue.

I accept its now time to move on and for the short term, will print from SD (And will source a FlashAir to make that process a little easier).. But my long term expectation was to use Octopi, where I hoped to be able to slice, transfer to the Octopi SD and print from there.. I get the fact that there are problems and its not reliable yet, but expect them to solve the issues soon.

I never expected to be able to transfer GCODE files to the Printers SD as I heard it was painfully slow.. But I do hope to be able to transfer files to the Octopi at a decent rate at some point in the future.

Opublikowany : 17/01/2018 5:48 pm
Protoncek
(@protoncek)
Reputable Member
Re: OctoPrint issues and tips

Well, from my understanding when reading all these problems from people main bottleneck is the fact that ATMEGA2560 MCU as heart of Einsy is just overloaded. So only thing Prusa can do is try to optimize processes in order to give MCU a bit more power...

To be honest, i dont' see much difference between these two modes:

-Octoprint: slice, transfer via wifi to Octopi, print.

-Wifi SD card: slice, transfer via wifi to card, print.

OK, in second one you have to go phisically to printer and from it's meni select print from SD --> print. But you have to go there anyway to prepare it and insert filament...

Opublikowany : 17/01/2018 5:57 pm
jweaver
(@jweaver)
Honorable Member
Re: OctoPrint issues and tips



OK, in second one you have to go phisically to printer and from it's meni select print from SD --> print. But you have to go there anyway to prepare it and insert filament...

True.. But its was Octopi's GUI that was the most interesting to me and the fact that you could get to it from any device on your network to monitor the print and control the printer.

I will go with a Wifi SD for now, but I still hope that the Octopi solution that was promised turns into a reality.

Opublikowany : 17/01/2018 6:00 pm
Protoncek
(@protoncek)
Reputable Member
Re: OctoPrint issues and tips


True.. But its was Octopi's GUI that was the most interesting to me and the fact that you could get to it from any device on your network to monitor the print and control the printer.

Yeah, that was appealing to me, too.
Let's hope for the best!

Opublikowany : 17/01/2018 6:03 pm
Ron
 Ron
(@ron-8)
Active Member
Re: OctoPrint issues and tips

Hi,

yes you transfer to SD in the PI, (can do the SD in printer) but that's very slooooow.

but using the PI SD whats wrong with that?

Also, has anybody used a WiFi SD card? so transfer the code files to the WiFi SD card in the printer ?
or is this card only supplying WiFi to a laptop/PC ?

anybody able to test this?

i think if your not using the SD in the printer the power/panic feature doesn't work...

regards Run

Opublikowany : 17/01/2018 8:04 pm
awilde
(@awilde)
Active Member
Re: OctoPrint issues and tips


Well, from my understanding when reading all these problems from people main bottleneck is the fact that ATMEGA2560 MCU as heart of Einsy is just overloaded. So only thing Prusa can do is try to optimize processes in order to give MCU a bit more power...

To be honest, i dont' see much difference between these two modes:

-Octoprint: slice, transfer via wifi to Octopi, print.

-Wifi SD card: slice, transfer via wifi to card, print.

OK, in second one you have to go phisically to printer and from it's meni select print from SD --> print. But you have to go there anyway to prepare it and insert filament...

Main reason I use Octoprint is to control from remote, start print when I'm at work, see the progress in the GUI and over webcam and get notified with telegrambot.

Opublikowany : 17/01/2018 8:07 pm
tmolberg
(@tmolberg)
Active Member
Re: OctoPrint issues and tips

For those interested, there is a new release on github. Current version is RC5. Bare in mind that this is still beta so dont expect it to be «fully tested» as its not yet «officially released» by prusa.

https://github.com/prusa3d/Prusa-Firmware/releases

Release notes

Print reliability improved
Test for swapped fans extended
Firmware version messages shown on printer startup
Bed temperature runaway
Fail stats fixed
Mode switching during print fixed
Crash detection message added
Improved displaying of status messages
Filament change updated
Serial communication improved
Load filament beep
Wizard fixes

Opublikowany : 17/01/2018 8:37 pm
Protoncek
(@protoncek)
Reputable Member
Re: OctoPrint issues and tips


Also, has anybody used a WiFi SD card? so transfer the code files to the WiFi SD card in the printer ?
or is this card only supplying WiFi to a laptop/PC ?

anybody able to test this?

regards Run

Ron, i have this setup, as i wrote above: i have Toshiba Wifi SD card, setup as network drive. Then from Slic3r i just click "save g-code" and i save it directly to SD card. Then i just go to printer, select file and hit print.

Opublikowany : 17/01/2018 9:19 pm
Paul Meyer
(@paul-meyer)
Honorable Member
Re: OctoPrint issues and tips

My desired setup is to have all printing from Octopi. This greatly simplifies my workflow.

Sit at the kitchen table downstairs designing/modeling/slicing. When I get close to done, bring up the Octopi webpage for the printer I want, warm up the heat-bed fully, and the nozzle to 120 or so (assuming I have the right filament in). Finish the slicing, start the print. Watch the temperature ramp.

If I have any concerns on the first layer (printing PETG or some new filament instead of PLA) 30 seconds or so before the print starts, wander upstairs, watch the bed leveling (flicking off any PETG strings), and watch the first layer start.

For the next hour or 10, monitor the print on the web (via temp graphs, raspberry pi camera, and GCODE visualization). If there are any issues and I can't deal with it right now, just stop the print from the web, raise the Z, and ignore it. I can monitor and stop prints from work. When the print is done, head up and pop it off.

Works fine on my Ultimaker and my Rostock. Can't do this on my mk3.

It mostly works (I did it for about two weeks), but only getting a layer shift every 3rd print isn't good enough. This is with the latest (1-2week old) firmware with linear advance turned off.

I'm basically resigned to old-school SD card printing for now (keeping track of SD cards, finding a reader, etc). I suspect it'll never get resolved with the Einsy board. They pushed that arduino to hard. I'm hoping (optimistically) that they'll have a 32 bit marlin board sometime this spring/summer and I'll do a swap. If the Einsy board is $120, I'm hoping a 32 bit board will be $150 (the processors themselves are very cheap). I'll pay it.

Opublikowany : 17/01/2018 10:14 pm
HackMonkey
(@hackmonkey-2)
Trusted Member
Re: OctoPrint issues and tips

@paul.m27 - Have you also slowed down accelaeration as Josef suggested? Once I did this I haven't had a single layer shift with Octoprint, and it has been rock solid. Sounds more like they were just too aggressive with speed settings. I was having layer shirts from the SD card before slowing down the acceleration also.

Opublikowany : 17/01/2018 11:42 pm
tmolberg
(@tmolberg)
Active Member
Re: OctoPrint issues and tips

6.5 hour into a 8-9 hour print a no problems at all with the RC5 release. Will try more later. New firmware seems to be more stable in terms of octoprint and layershifts. That being said the silent mode is severely slower then normal mode.

https://github.com/prusa3d/Prusa-Firmware/releases

Opublikowany : 18/01/2018 2:10 pm
imod.systems
(@imod-systems)
Honorable Member
Re: OctoPrint issues and tips



I'm basically resigned to old-school SD card printing for now (keeping track of SD cards, finding a reader, etc).

I know it's a workaround but others suggested using an SD card with wifi built in. I bought one yesterday and that could be a sufficient workaround. You'd still have to walk into the room and press print though. I personally feel more comfortable with this solution because of the current bugs the printer has with octoprint. I even experienced some octoprint bugs with my other printer, MP Mini, that would cause the print head to runaway. If I wasn't in the room I would of had no idea until I got there to check on it.

Just a thought

Opublikowany : 18/01/2018 4:56 pm
Protoncek
(@protoncek)
Reputable Member
Re: OctoPrint issues and tips

Well, another option is to use wifi SD card for file transfer and Octoprint to start printing form SD and control printer (and see picture).

Opublikowany : 18/01/2018 5:05 pm
Paul Meyer
(@paul-meyer)
Honorable Member
Re: OctoPrint issues and tips


@paul.m27 - Have you also slowed down accelaeration as Josef suggested? Once I did this I haven't had a single layer shift with Octoprint, and it has been rock solid. Sounds more like they were just too aggressive with speed settings. I was having layer shirts from the SD card before slowing down the acceleration also.

No, I'll try that. Josef's instructions were pretty specific to Slic3r and I tend to use s3d.

To be honest, when he posted that I hadn't had a problem yet, so with the complexity of translating his instructions into s3d gcode I ignored it. Then last weekend when I started having the issue I wasn't in the mood to go digging. I was hoping there would be new firmware out by now with correct acceleration by default...

Opublikowany : 18/01/2018 6:48 pm
Paul Meyer
(@paul-meyer)
Honorable Member
Re: OctoPrint issues and tips


I was hoping there would be new firmware out by now with correct acceleration by default...

Looks like I delayed just long enough. Firmware rc5 is out:

...
- OctoPrint printing fixed
...
- Test for swapped fans is more robust [pgm I've been having this problem]
...
- Linear advance temporarily disabled as current implementation might be causing random layer shifts on MK2 and MK3
...

Doesn't explicitly say that the default acceleration values are changed, but I can't imagine they haven't. I'll install it tonight, and hopefully be good to go once I get my replacement PSU installed.

Opublikowany : 18/01/2018 8:55 pm
insidious
(@insidious)
Active Member
Re: OctoPrint issues and tips



I was hoping there would be new firmware out by now with correct acceleration by default...

Looks like I delayed just long enough. Firmware rc5 is out:

...
- OctoPrint printing fixed
...
- Test for swapped fans is more robust [pgm I've been having this problem]
...
- Linear advance temporarily disabled as current implementation might be causing random layer shifts on MK2 and MK3
...

Doesn't explicitly say that the default acceleration values are changed, but I can't imagine they haven't. I'll install it tonight, and hopefully be good to go once I get my replacement PSU installed.

Yeah they did change the default acceleration values, changes can be found here or seen below.


#define NORMAL_MAX_ACCEL 2500 // Y-axis max axxeleration in normal mode in mm/s^2
#define NORMAL_MAX_ACCEL_ST (100*NORMAL_MAX_ACCEL) // max accel in steps/s^2
#define NORMAL_MAX_FEEDRATE 200 //max feedrate in mm/s, because mode switched to normal for homming , this value limits also homing, it should be greater (172mm/s=9600mm/min>2700mm/min)

Opublikowany : 19/01/2018 12:34 am
PeteJ
(@petej)
Eminent Member
Re: OctoPrint issues and tips

Using Firmware c5 I’m still having problems with OctoPrint. I tried to print a stand for a Kindle e-reader, but the printer encountered problems as it finished the first layer. I got a "Crash Detected" message on the Prusa display and the print head moved off to the side, then cycled back over the print, then moved back to the side etc.

I'm printing in PETG, using the Prusa edition of Slic3r.

As a test, I tried printing the same object from the SD card. No problem.

Then I tried it with OctoPrint again. Same failure, same place.

Despite the issues with OctoPrint, I like the printer a lot, and each release of software and firmware is improving its performance. My success rate printing from the SD card is about 85%, maybe a bit higher, and it keeps getting better.

Opublikowany : 19/01/2018 3:41 am
Johncoffee
(@johncoffee)
Trusted Member
Re: OctoPrint issues and tips



I was hoping there would be new firmware out by now with correct acceleration by default...

Looks like I delayed just long enough. Firmware rc5 is out:

...
- OctoPrint printing fixed
...
- Test for swapped fans is more robust [pgm I've been having this problem]
...
- Linear advance temporarily disabled as current implementation might be causing random layer shifts on MK2 and MK3
...

Doesn't explicitly say that the default acceleration values are changed, but I can't imagine they haven't. I'll install it tonight, and hopefully be good to go once I get my replacement PSU installed.

How about MK2S Printers with FW 3.1.0 ? I guess when Prusa claims that FW rc5 will fix Octoprint printing, why there is no upgrade for FW 3.1.0 with the same solution?
...but apparently it doesn't seem to be working even with rc5 yet.... 🙁

Opublikowany : 19/01/2018 12:49 pm
Strona 6 / 23
Share: