Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

small corners dont print smoothly (raspberry pi) #450

Open
LangBalthazar opened this Issue Apr 18, 2014 · 130 comments

Comments

Projects
None yet
@LangBalthazar
Copy link

LangBalthazar commented Apr 18, 2014

Hi,

I have had a couple of gear prints that fail get bad print results when using OcotPrint. The same gcode in repetier via a pc works perfectly without any small stops or hesitations in the movement.

This is one of the gears in thing:243278
bild 1

example images of full print from pc/repetier vs stopped print OcotPrint.
bild 4

A video of the problem. Long straight or circles work without any problems but a few seconds in when it prints the "gears" it starts to stop mid movement.
https://www.youtube.com/watch?v=tbUntyq7djY

The log from the heart gear print
https://gist.github.com/LangBalthazar/11037683

The gcode from the heart gear print:
https://gist.github.com/LangBalthazar/11037928

I am running Branch: devel, Commit: bf9d5ef

I have done a update and upgrade (so the pyserial should be 2.7 and work on baud 250000, correct or could this be my problem?) My printer is a Velleman K8200 / 3drag.

Any ideas on why this happens when printing from octoprint?

Best regards
Balthazar Lang

@foosel

This comment has been minimized.

Copy link
Owner

foosel commented Apr 18, 2014

You are printing from the Pi, right? You might simply crash against it's
limitations there. For toolpaths with a lot of small lines (e.g. lots of
rounds and direction changes, as in gears) you will have a lot of gcode
lines generated, each only moving the head a tiny fraction. Now, all those
lines of gcode need to be transfered to the printer, and that quite fast.
On a regular work pc, you won't run into problems here. On a pi though,
transfer plus house keeping can be too much. Personally, I've taken to
doing prints like that from SD instead of streaming them via USB. Serial
communication is a bottleneck. Printing slower might help.

@CptanPanic

This comment has been minimized.

Copy link

CptanPanic commented May 9, 2014

It might be better than just stating that raspi might be too slow, then maybe Octoprint can detect that it is falling behind, and report an warning or such.

@foosel

This comment has been minimized.

Copy link
Owner

foosel commented May 9, 2014

Suggestions on how to do this (without making the whole processing even
slower) are welcome

@Salandora

This comment has been minimized.

Copy link
Collaborator

Salandora commented May 10, 2014

First suggestion is you could (while anaylsing the gcode), try to detect Perimeter Movements, e.g. by Speed, and check if there are many "small" movements after each other. Just one suggestion, I believe if I think that further I'll find a few more ways to check that.

@CptanPanic

This comment has been minimized.

Copy link

CptanPanic commented May 10, 2014

If the errors are happening because the processor gets too loaded, maybe just having a graph showing the processor utilization?

@Salandora

This comment has been minimized.

Copy link
Collaborator

Salandora commented May 12, 2014

Hello,

I had an idea about speeding up the whole Analysis Process and even detecting for small movements... I don*t know if it's a good idea so i post it before doing any programming.

Idea:
Do the analysis in the browser before uploading everything to Octoprint.

e.g.: I want to upload File XY, i drop it onto the Browser, now a Javascript Gcode Analyser will process the whole file, sending all necessary informations with the file (as a comment or JSON-Data), Octoprint wouldn't need to do anything anymore.
If you notice areas with many small movements you could inject a Gcode to slow things down, make a Comment, or warn the uploader.

@foosel

This comment has been minimized.

Copy link
Owner

foosel commented May 14, 2014

The problem I have with this approach is that it's moving too much of the core work over to the client. This is critical due to two reasons.

  1. Never trust the client
  2. My guess is that this would make uploading from a mobile device or remotely (think: cloud slicer) way more complicated/close to impossible.

IMHO the gcode analysis should be the server's responsibility (and right now it doesn't add much anyways besides some stats, which is why it's done asynchronously and should never be done when printing), as should be anything to do with file processing.

Recognizing small movements might be possible on the fly during printing, so we could display a warning in such a case. What I want to prevent though is adding even more detection code and stuff in the send loop that will put even more strain on the poor CPU and make serial communication even more fiddly (which it already is anyways thanks to the protocol), which is why I'm quite reluctant to add large "am I slow now?" detection mechanisms in there. This is also the reason for my backtalk above ;)

I'm not even sure if a software solution is the best approach here to be honest (due to the serial bottleneck and also the fact that as said above, anything done in Software will only put more strain on the system). A small part of me is rather thinking in the direction of emulated SD card attachments connected via hi-speed-USB to the host.

In any case, at the current state it's a non trivial issue.

@vdesmedt

This comment has been minimized.

Copy link

vdesmedt commented May 22, 2014

anyway to compress gcode before sending it over the wire ?

@foosel

This comment has been minimized.

Copy link
Owner

foosel commented Feb 15, 2016

Does this problem still occur in OctoPrint 1.2.x? I backported a lot of the fixes I did on the commRefactoring branch (which sadly proofed after a lot of work on it to be unviable), so the problem shouldn't exist as much anymore (although the serial line will still always be a bottleneck the smaller the segments get, there's nothing I can do about that).

@MortenGuldager

This comment has been minimized.

Copy link

MortenGuldager commented Feb 26, 2016

I have been bit by this as well.

I made a small g-code file, only containing a few G0 commands and tried to have octoprint(1.2.9) send it to marlin over raspi serial (the one on the GPIO) at 250000 baud.

I then hooked up a LSA to RX and TX and measured time between "ok" and the next "G0" command: approx 10ms.
So octoprint seems to be busy doing stuff for 10ms between each command getting sent. seems to me like a place to look for some improvements. If I make file long enough octoprint maxes the raspi to 100% CPU load.

First place to look could be disabling terminal logging during prints. (i tried with a filter, but it did not help much)

@nophead

This comment has been minimized.

Copy link
Contributor

nophead commented Feb 26, 2016

The firmware should buffer up G0 commands, so unless you are trying to print more than 100 line segments per second you shouldn't notice. What speed are you printing at and how short are your line segments during a curve?

@MortenGuldager

This comment has been minimized.

Copy link

MortenGuldager commented Feb 26, 2016

The test data mentioned is crafted only track down where the bottlenecks are. No real printing going on here. But if I make small enough curve segments it will exhaust the buffer in the firmware. I'm pointing out that the send loop isn't particular fast, which I think I read some of the comments above to confirm as well.

@nophead

This comment has been minimized.

Copy link
Contributor

nophead commented Feb 26, 2016

Well yes it will always be possible to exhaust the buffer with a finite comms speed, but is 10ms a problem in a practical sense? It doesn't seem to affect my prints but then I don't print segments shorter than my filament width.

@MortenGuldager

This comment has been minimized.

Copy link

MortenGuldager commented Feb 26, 2016

Perhaps I should explain why I came across this in the first place. I was wondering why upload to sd card takes to long. And here I more or less constantly see a 6.6ms delay from previous "ok" till next line starts transmitting.
Sorry for trying to make the example simpler when all that it did was to confuse you guys.

@nophead

This comment has been minimized.

Copy link
Contributor

nophead commented Feb 27, 2016

So I thought I would investigate this but I can't get upload to SD to work at all with Version: 1.2.9 (master branch). The log just says octoprint.filemanager.analysis - INFO - Starting analysis of local:cal.gco and that is it. It never sends anything to the serial port.

Does this work for anybody else?

@foosel

This comment has been minimized.

Copy link
Owner

foosel commented Feb 27, 2016

@nophead

This comment has been minimized.

Copy link
Contributor

nophead commented Feb 27, 2016

OK I downgraded to 1.2.8 using your instructions. The sudo service octoprint restart did not find a service but a manual reboot worked.

The delay from OK to the next line is 16ms on my RPI B. Marlin only takes about 0.68ms to process the line and reply with OK. The line takes 5.3ms to send so it could potentially run a lot faster.

@foosel

This comment has been minimized.

Copy link
Owner

foosel commented Feb 27, 2016

I agree, there's something up here.

@MortenGuldager also pinged me on another channel and suggested he'd open a new ticket for that. He observed a significant performance drop between 1.2.2 and 1.2.9 so it definitely looks like there was some issue introduced somewhere between those versions. For this a new ticket indeed might be better (specific issue introduced through a code change somewhere).

It's actually a perfect timing now since the 1.2.10 has gotten delayed anyhow, this way that could contain another valuable fix if we figure this out. I have to admit, I'm unsure how to best measure this stuff (not sure my cheap logic analyser is up to that actually) and I'm still not fit again, so any help from you two in that matter is welcome to get that ironed out as fast as possible.

@nophead

This comment has been minimized.

Copy link
Contributor

nophead commented Feb 27, 2016

I measured it with an extremely cheap Chinese clone of a Saleae logic analyser. Although I do have much better equipment that was the easiest to attach to the machine in my garage that uses ttyAMA0 at 115200, rather than USB at 250000. A long time ago I found that faster for SD upload but I can't remember if that was an early OctoPrint or Pronterface.

Iscreenshot

The next step I will try is 1.2.2. To get further it might be necessary to use a Python profiler. Or I could add code to pulse GPIO lines at specific points in the code as I have six more channels on this device.

@MortenGuldager

This comment has been minimized.

Copy link

MortenGuldager commented Feb 28, 2016

my fault. perhaps not the latest octopi. The "fast" one reports Version: 1.1.1-30-g4fede5a (master branch)
and the img file I loaded on the RPI sd was 2015-01-31-octopi-0.11.0.img

@foosel

This comment has been minimized.

Copy link
Owner

foosel commented Feb 28, 2016

That is bad then, because 1.1.1 contained bugs in the comm layer that could basically ruin prints under the right conditions (race conditions in resend handling and overrunning the firmware's receive buffer) that the big rework in 1.2.x solved. So no going back to the old version without basically breaking everything left and right again for a lot of people.

There are still points in the code where I could imagine there are optimization possibilities though.

@MortenGuldager

This comment has been minimized.

Copy link

MortenGuldager commented Feb 28, 2016

well, lets leave it as it is here. I will look into other ways for speed-uploading and eventually make a feature request for a faster serial communication.

Sorry for the fuss I stirred up.

@nophead

This comment has been minimized.

Copy link
Contributor

nophead commented Feb 28, 2016

I found I had the serial log enabled. Turning that off reduces the latency to just over 9ms, so similar to @MortenGuldager's finding. If the latency was zero it would go nearly three times faster.

@foosel

This comment has been minimized.

Copy link
Owner

foosel commented Feb 28, 2016

The sd upload via serial is more like a hobbled wheel anyhow. Even if you blast at full serial rate, a large file still takes ages. I've recently been rather experimenting with FlashAir (sd card with built in Wi-Fi) and that looks like a way less annoying approach.

I'll still take another look at the current code though once I'm back on my feet, your mention of a Saleae clone reminded me that I have a ScanaPlus that might be able to help after all.

@foosel

This comment has been minimized.

Copy link
Owner

foosel commented Nov 8, 2017

A rewrite of the comm layer is scheduled for 1.4.0. Until then based on my personal experience I'd recommend to print stuff with loads of short segments rather from a Pi2 or Pi3 (I don't see any stuttering there myself).

10mm cylinder with 256 sides

Why? Honest question.

@MortenGuldager

This comment has been minimized.

Copy link

MortenGuldager commented Nov 8, 2017

I print a lot of gears, many segments makes them run smoother. They almost always turn out better if printed directly from a SD card than if sent over a serial interface in real time. Quite often Marlin empties it's queue which leads to the stuttering .
Unfortunately, uploading the file to SD via serial is also a very slow process, mostly due to the un-windowed communication protocol in use.
The "real" solution would involve a add on to the firmware (Marlin) as well, something that allowed us up upload data in near wire speed, not waiting for acknowledge between every single line of g-code.

@lokster

This comment has been minimized.

Copy link

lokster commented Nov 8, 2017

Why? Honest question.

It was a test case, to better illustrate the issue without wasting too much time & material. But I have the same issue with regular prints too - especially with smaller "organic" models like skulls, dragons etc. with smooth curved surfaces.
I have done some Marlin tweaks that hide the issue a bit (mostly, increasing the buffer sizes) - because the "default" configuration has quite the small buffers.
The issue is still present though - although not as dramatic. And I still get much smoother results with repetier server (which I don't like and don't want to use... let alone pay for) :)
In fact, repetier server's result is comparable to the one I get from SD card.
Even the print time is considerably shorter. For example, this cylinder prints in about 2min 35 sec with Octoprint, and just 1min 50sec with Repetier Server. Same Pi Zero (and the same raspbian installation), same gcode.
Note: my idea is not to whine and trash Octoprint, just trying to improve it :)

Let me share what I had found regarding Marlin, even if it's a bit off-topic (it might help others):
all
Image numbering: first row 1,2,3, second row 4,5,6 etc.

Octoprint via USB
1 - BLOCK_BUFFER_SIZE = 16; BUFSIZE = 4; TX_BUFFER_SIZE = 0; DEFAULT_MINSEGMENTTIME = 20000 Print time: 00:02:31 (stock marlin)
2 - BLOCK_BUFFER_SIZE = 128; BUFSIZE = 4; TX_BUFFER_SIZE = 0; DEFAULT_MINSEGMENTTIME = 20000. Print time: 00:02:29
3 - BLOCK_BUFFER_SIZE = 16; BUFSIZE = 32; TX_BUFFER_SIZE = 0; DEFAULT_MINSEGMENTTIME = 20000. Print time: 00:02:29
5 - BLOCK_BUFFER_SIZE = 128; BUFSIZE = 32; TX_BUFFER_SIZE = 4; DEFAULT_MINSEGMENTTIME = 20000. Print time: 00:02:33
8 - BLOCK_BUFFER_SIZE = 128; BUFSIZE = 32; TX_BUFFER_SIZE = 0; DEFAULT_MINSEGMENTTIME = 20000. Print time: 00:02:35
4 - BLOCK_BUFFER_SIZE = 128; BUFSIZE = 32; TX_BUFFER_SIZE = 0; DEFAULT_MINSEGMENTTIME = 20000 Print time: 00:02:22
7 - BLOCK_BUFFER_SIZE = 128; BUFSIZE = 32; TX_BUFFER_SIZE = 0; DEFAULT_MINSEGMENTTIME = 50000. Print time: 00:02:37
6 - BLOCK_BUFFER_SIZE = 128; BUFSIZE = 32; TX_BUFFER_SIZE = 4; DEFAULT_MINSEGMENTTIME = 50000. Print time: 00:02:26
9 - BLOCK_BUFFER_SIZE = 128; BUFSIZE = 32; TX_BUFFER_SIZE = 4; DEFAULT_MINSEGMENTTIME = 75000. Print time: 00:02:25

Repetier Server via USB
10 - BLOCK_BUFFER_SIZE = 128; BUFSIZE = 32; TX_BUFFER_SIZE = 0; DEFAULT_MINSEGMENTTIME = 50000. Print time: 00:01:50

Repetier's result (image 10 is obviously the best, followed by image 7.
The default small buffers in Marlin just make the things worse.

@fiveangle

This comment has been minimized.

Copy link

fiveangle commented Nov 8, 2017

...print stuff with loads of short segments rather from a Pi2 or Pi3 (I don't see any stuttering there myself)

How do you know you don't see any stuttering ? :) I think you mean you don't observe any obvious stuttering, but it is surely there. I setup an IO pin on Marlin (with OP on the Pi2) to trigger when the queue was drained and it absolutely still does (albeit not as grotesquely as on my orignal B+ ).

The "real" solution would involve a add on to the firmware (Marlin) as well, something that allowed us up upload data in near wire speed, not waiting for acknowledge between every single line of g-code.

Marlin side is done and merged on both 1.1 and 2.0 dev branches : MarlinFirmware/Marlin#7818 MarlinFirmware/Marlin#7459

Not a whole lot of testing so could certainly be some stumbling blocks once any hosts are outfitted to support it, but you gotta start somewhere…

@nophead

This comment has been minimized.

Copy link
Contributor

nophead commented Nov 8, 2017

@lokster

This comment has been minimized.

Copy link

lokster commented Nov 8, 2017

The thing is, it's obvious we are not hitting hardware/mechanical limitation here, because the same setup (gcode, raspberry pi and printer) works considerably better with repetier server or a simple gcode sender.
So, using slower print speed and lower mesh resolution just hides the problem, and is not really a solution.

@nophead

This comment has been minimized.

Copy link
Contributor

nophead commented Nov 8, 2017

True but there is no point in printing segments shorter than half your filament width. The filament smooths out the curve so you don't need more detail in the curve than it can reproduce.

@lokster

This comment has been minimized.

Copy link

lokster commented Nov 8, 2017

First, you mean "half the nozzle width", not "half the filament width". Because "half the filament width" is nonsense.
Second - the question is not whether there is a point or there isn't. This is a subject of another discussion, unrelated to octoprint. "There is no point" is just an excuse, and this is not the place to argue about it.
I say there IS a point.
And third - most of the people with 3D printers don't actually design all the models they print. And even if they do, just a small fraction of them cares to "optimize" them. This is highly unlikely scenario. Just check 10 random thingiverse models with "organic" shapes.
So, if repetier or whatever + pi + printer is able to produce smooth prints, so should octoprint + the same pi + the same printer.
The issue is real, and is quite easy to reproduce. Even on models with lower resolution (but stil not "low-poly").
Don't try to understate the issue, just because it is not present in your workflow / setup.

@foosel

This comment has been minimized.

Copy link
Owner

foosel commented Nov 9, 2017

@fiveangle

I literally said "I don't see any stuttering", not "there cannot be any stuttering!!1!"

[XON/XOFF]

Do I see it correctly that there's currently no way to detect if the firmware supports that (e.g. by checking capability report, then adjusting serial parameters accordingly)? 🤔

@lokster & @nophead Both of you have a point and stated it accordingly, keep it civil ;)

works considerably better with repetier server or a simple gcode sender

The thing here is - OctoPrint is not a simple gcode sender. It offers a load of functionality. And I fear that I'm simply hitting the limits of the underlying architecture due to that. I've spent a ton of time trying to make the current comm layer faster. There have been some performance gains here and there, but considering that everything has to run in the same process that also means that API, business logic and the gcode sender have to share the same resources constantly. That plus gcode processing on sending (think plugin hooks, think check summing etc) is a bad combination. And that is why this is not a simple quick fix but something that needs a very invasive rewrite of a very important component to address. If I'd known what I know now around four or five years ago, I'd done things differently back then, but alas, I didn't.

The first attempt at this rewrite happened in late 2014 and made me hit a crippling firmware issue present in pretty much all Marlin forks out there that happened earlier than that and that forced me to abandon the whole approach I had back then and start completely from scratch.

The second attempt at this rewrite happened in early 2016 (@nophead might actually still remember the benchmarking we did back then), was going strong, and then the funding crisis hit. Since then I've been trying to get back on this, but this ain't something that I can do "in between" other things, so I didn't manage so far thanks to drowning in regular maintenance, support, ticket triage etc. As I mentioned above, I have this scheduled for 1.4.0 though and I also recently did a huge change in my general task management approach that finally freed up some valuable development time again, en bloc.

If you think I'm not aware of there being an issue somewhere in the comm layer or possibly in the general architecture that is negatively influencing achievable sending speeds, you are mistaken. But: It's also not bad enough in the majority of cases (if noticeable at all without adding actual sensor equipment in the one or other way) that I can justify dropping everything else to exclusively concentrate on this - and also risk breaking compatibility with the hundreds or thousands of firmware variants out there. In fact, I fear the majority of my patrons & other sponsors who even possible for me to work on this don't even necessarily agree that I need to make this rewrite at all, but thankfully so far haven't vetoed as far as I can tell.

@lokster

This comment has been minimized.

Copy link

lokster commented Nov 9, 2017

@foosel fair enough, and I get your points. Let's see what happens in 1.4.0.
In the mean time I will be researching for workarounds.

@fiveangle

This comment has been minimized.

Copy link

fiveangle commented Nov 10, 2017

Do I see it correctly that there's currently no way to detect if the firmware supports that (e.g. by checking capability report, then adjusting serial parameters accordingly)?

This early mechanism was to rely on the user knowing if it's enabled or not and if so, using the feature. The idea was originally to speed SD uploads. If you are interested in supporting this from the host side, I'll ensure by the time you're ready it will be in the capabilities report. I'll start working on that now (since it really should've been done anyway, but was overlooked).

@nophead

This comment has been minimized.

Copy link
Contributor

nophead commented Nov 11, 2017

First, you mean "half the nozzle width", not "half the filament width". Because "half the filament width" is nonsense.

No, not the nozzle width or the filament diameter, the width of the filament laid down. You simply can't see tiny facets because the filament smooths them out like a French curve. I design with OpenSCAD with $fs = filament_width / 2 as a good rule of thumb and I don't see facets in my printed curves.

Yes organic models on Thingiverse won't print over USB unless you slice them with Skeinforge. That eliminates tiny facets. More modern slicers don't seem to bother.

IIRC a raw gcode sender is about twice as fast as OctoPrint, so you can hit the problem even then if your segments per second rate gets too high. You can either switch to SD, reduce the number of segments in the model or reduce your print speed.

@fiveangle

This comment has been minimized.

Copy link

fiveangle commented Nov 11, 2017

No, not the nozzle width or the filament diameter, the width of the filament laid down.
I design with OpenSCAD with $fs = filament_width / 2 as a good rule of thumb and I don't see facets in my printed curves.

The term is "extrusion width" so you shouldn't be suprised when you conflate it with "filament width" and others don't understand what you are talking about ;)

IIRC a raw gcode sender is about twice as fast as OctoPrint, so you can hit the problem even then if your segments per second rate gets too high.

Comparing the effective GCODE serial rate throughput of Octoprint and raw serial, I find this statement hard to beleive. Can you point us to any discussion where this was determined ? I'd imaging the upper speed limit to be a moving target and highly environmentally dependant so if others have done this work, I would love to read it.

You can either switch to SD, reduce the number of segments in the model or reduce your print speed.

Not sure if you missed it, but the discussion is about brainstorming possibly ways to mitigate the (50%, according to you) throughput drop observed when printing with Octoprint. Your statement to switch to SD card at this point in the discussion is confusing. Are you trolling us ? :)

But I think the situation is far more dire, because the current avg throughput rate of OP is more than enough. It's the occasional hiccup that interrupts realtime GCODE processing that is the real problem, not raw average throughput.

If what you say is true — that there is a doubling of speed on the table — Gina's 1.4.0 rewrite will likely attain that (at a minimum - I'll reserve judgement until I see this discussion about where that 50% number came from). The real value in having the comms layer run as a separate lightweight process is to attain more realtime delivery, while the asynchronous operations can happen at whatever speed the system can muster with what's left over.

Beyond that, flow control (already implemented in Marlin today) should mitigate the speed limitation of ping-pong mode entirely so that the new limit is exponentially higher than 2x of current capabilities, but more importantly, not so dependant on realtime processing. The Marlin implementation currently allows a minimum of 1k RX buffer on the serial (vs. default of 32), which (if it all works as expected) would free the OP process to have a lot more hiccups in processing before draining the planner on the other end.

@nophead

This comment has been minimized.

Copy link
Contributor

nophead commented Nov 11, 2017

Yes extrusion width is a better term. I will have to a do a global replace in all my code.

The work I did with a logical analyser starts here: #450 (comment) in this issue.

@fiveangle

This comment has been minimized.

Copy link

fiveangle commented Nov 11, 2017

Thanks.

Btw- this may be wishful thinking but the hints are that the new Prusa MK3 controller board (Ulimaker Einsy) has a pin footprint on the underside to pick up a PiZeroW that the hive mind consensus expects is for use with Octoprint.

With the newly-implemented real-time Linear Advance feature in the Prusa fork (originally by @Sebastianv650 in Marlin 1.1), increased rigidity of the MK3, and ability to adjust microstepping real-time over SPI on the 256-interpolated Trinamic drivers I’d imagine they would easily hit the Octoprint serial comms threshold of affecting the print on the modest Pi0. The question is how will they mitigate ? There’s been speculation on direct GPIO to Marlin but if they stick with serial, perhaps some form of OP optimization maybe on the horizon of being released ? All rumors at this point but we shall see…

@markwal

This comment has been minimized.

Copy link
Collaborator

markwal commented Nov 12, 2017

@fiveangle I'm not sure whether Prusa was just optimistically hoping a PiZeroW would do it or if he's got another trick up his sleeve, but so far PiZeroW testing indicates that when it is using the wifi (send or receive) there isn't a whole lot of core CPU left over for processing.

Maybe he's intending to publish his own barebones g-code sender/server.

He did say in some interview that people shouldn't be so worried about the PiZeroW's limitations because while you can't mount a whole Pi 3 on there, you should be able to connect it easily to the the connector he's put on there.

@foosel

This comment has been minimized.

Copy link
Owner

foosel commented Nov 13, 2017

perhaps some form of OP optimization maybe on the horizon of being released ?

Well, at least I'd hope they'd get in touch with me about something like this, and so far that hasn't happened. They also said they weren't aware of any issues with the 0W WiFi, which struck me as a bit of surprise considering that a simple curl without anything else running on the machine will already gobble up more than 50% CPU. With a Pi0W, I can tell you that OctoPrint's comm layer is the least of your concerns, unless you plug in a USB WiFi/Ethernet dongle (or keep the thing completely off the network, kinda defeating the whole purpose).

@lokster

This comment has been minimized.

Copy link

lokster commented Nov 13, 2017

I did an interesting observation on the Pi Zero. Not unexpected, but still interesting: when there is a webcam running (and streaming MJPG) the quality drops drastically even though the CPU usage is within ~50-70%.
What's even more interesting, is that when streaming the webcam & printing via Repetier Server, it does not affect the quality :)
So, what is Repetier doing differently?
I tried giving the octoprint process more CPU & IO priority with ionice and renice, but it had absolutely no visible effect.

simple curl without anything else running on the machine will already gobble up more than 50% CPU

Interesting. Is this well know issue with the Pi Zero W?
It does not apply in my case, because I use "regular" Pi Zero + ESP8266 SDIO, connected directly to the SDIO pins on the Zero. Just tested, and a wget download with ~2MB/s takes just 2% CPU.
Not that my comment helps much... just sharing some observations.

@fiveangle

This comment has been minimized.

Copy link

fiveangle commented Nov 13, 2017

It’s because the WiFi implemention is not optimized.

Also, lots of Pi0’s came underclocked from 1GHz To 700MHz, which certainly doesn’t help anything

@nophead

This comment has been minimized.

Copy link
Contributor

nophead commented Nov 13, 2017

It does not apply in my case, because I use "regular" Pi Zero + ESP8266 SDIO, connected directly to the SDIO pins on the Zero.

Interesting, how do you configure the Pi to use the ESP8266 for its Wifi connection?

I was playing with one of those recently and it seemed to connect to my Wifi much better than the average USB dongle.

@lokster

This comment has been minimized.

Copy link

lokster commented Nov 13, 2017

Not sure if it's ok to share the link here (might be considered free advertisement) but I have documented the process here: http://lokspace.eu/control-your-anet-a8-3d-printer-using-octoprint-on-raspberry-pi-zero-with-sdio-wifi-addon-direct-uart-connection-and-still-have-one-free-usb/

It uses ESP-12F module, a couple of resistors, and manually compiled driver. Once set up, it's VERY reliable and the connection is fast & stable. E.g. getting 4MB/s download speed without issues.
I got tired of cheap USB wifi dongles constantly losing connectivity...

EDIT: I made this before the Pi Zero W existed :)

@fiveangle

This comment has been minimized.

Copy link

fiveangle commented Nov 13, 2017

…now replace the ESP-12F with an Einsy, and corresponding serial loopback driver with Einsy TTL serial as the endpoint and you understand what I am getting at with my predictions of the forthcoming Pi0 impelmentation in the MK3. No major Octoprint changes necessary, if at all. But again, we shall see…

@mpapierski

This comment has been minimized.

Copy link

mpapierski commented Oct 3, 2018

Hey @LangBalthazar On what raspberry pi do you experience such problems? I'm running OctoPrint on Pi Zero now I'm mostly happy regardless small imperfections. I'm switching to Pi3B+ because the load on Pi Zero is far too high to be reliable.

@Thorinair

This comment has been minimized.

Copy link

Thorinair commented Jan 30, 2019

Too bad that this issue is still present... I am printing from a Raspberry Pi 3 Model B, and I am getting exactly the same issues. Interestingly, even printing as something as simple as a Benchy will create visible slowdowns while printing the curved bow part. As @lokster explained in their analysis, increasing the buffer in Marlin did help slightly, but I am still not happy with the results.

One very nice way to make these issues clear as day while printing is to enable the linear advance in Marlin. The result will be this wonderful grinding sound that sounds like the printer is physically falling apart (realistically, it might from the vibrations) as Marlin triggers the linear advance movements after each serial buffer empties and waits for the new batch from OctoPrint.

I have made a video last year which showcases this issue quite well on a Benchy: https://www.youtube.com/watch?v=-u8j61-BWLw
At around 11 seconds in, the printer will start making the perimeter walls of the bow. You will notice a sudden slowdown near the end of the bow in the first perimeter, followed by a longer slowdown during the second perimeter. You may ignore the third one as that one is intentionally slower for a better outside finish.

@changedsoul

This comment has been minimized.

Copy link

changedsoul commented Mar 10, 2019

I can say I am also seeing this issue. Most my prints are boxy and so I never really noticed it. It wasnt until I made a small object to test and fine tune my retract settings that I found it slowing down considerably on arcs. It came to a crawl on an ark that is about 3.5mm in diam....so I increased it to 10mm in diam and it still had issues going around the curve.

I printed the exact same Gcode from my computer from Repetier-Host and had "zero" issues. So I thought AH-HAAA its the PI and its crummy slow USB.

But then I installed Repetier-Server on the PI's SD card and printed from the PI again, but this time instead of printing using OctoPrint, I was using Repetier-Server.

Both times the PI was connected to the printer with the same USB cable, Same power, same everything. The only difference was one time I was running OctoPi, the other time I was running Repetier-Server.
The Repetier-Server printed flawlessly around the arc features.

So it would appear its not a limitation of the PI, its how Octoprint is implementing its serial communications, or maybe other stuff in the background causing the serial communications to lag.

If there is anything I can provide, let me know what it is, I would be happy to help in any way I can to resolve this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.