I turn to you because I have a problem with octoprint and my raspberry, during printing there are lags that cause the nozzle to stop moving a few milliseconds and cause printing defects (blob / zits)
it is clearly a power problem with the raspberry because I have tested octoprint with windows and everything is fluid.
my question: what materiel to buy to replace raspberry?
to buy a raspberry 3B +? that will be enough?
or buy a product of this type: https://www.intel.co.uk/content/www/uk/en/products/boards-kits/nuc/kits/nuc7i3dnhe.html?_ga=2.223395283.971855300.1529791073-1753881004.1529791063
If the model has to many triangles the printer can "lag"
In general many printer boards (especially the 8 bit ones) are not good when you print faster than 45-50 mm/s.
If i want to print that fast i do it with sd card.
If you build a pc by your own you can have one cheaper.
i use a 60w
+
and a bay trail based board.
with the cheapest case you can build a pc for octoprint for around 110€ which consumes around 10w.
thank you for the explanations.
OK, even the B + model will have the problem.
for the specific pc for octoprint, the barebone format is very small.
do you think this pc might be appropriate?
~190 € (with memoiry and ssd)
or this :
or this :
another question, you use custom pc for octoprint ?
what distributions do you use ? raspbian for desktop ?
A photo of the printed model might allow us to see how bad the blobbing is. I'm not completely convinced that your problem is in the Raspi, btw.
Note that a slow RAMPS board could also cause blobbing; it might not be the Raspi at all.
Not sure which one you have but I assume from your text that you have a not-a-Raspberry-Pi-3B+. I have a Raspberry Pi 3B and mine prints beautifully.
Cura 3.3.1 has a feature called Spiralize outer contour which will do great things in this area if we're talking about the slight blob that results from changing layers.
Klipper moves some of the processing from the RAMPS board to the Raspberry Pi 3B in this case. If the problem is your RAMPS board, then this will significantly help your surfaces. I've heard anecdotally that this removes print hesitation as you've described.
I do not know if it is related to a layer change, but during printing, the print head is not always fluid or stops a few milliseconds.
in direct test with the SD card no problem.
to be sure, I just made the same print with the same settings since an octoprint install on windows.
The result: a perfect piece without fault
note: I installed the same plugins as the raspberry octoprint
To me, that looks like layer change blobbing. The surface looks good, otherwise I would have suggested that you drop the hotend temperature by five degrees.
This feels like it may be related to the serial communications or yes, the Raspi. And yet, you might wonder in this case if you have any additional plugins loaded which hook into the serial communications, especially something that pays attention to the layer-related information.
The way a plugin is written, if it hooks into the serial connectivity, it can actually hold control over whether or not that gets sent to the RAMPS board. It can accidentally insert the delay you're seeing. (Try disabling any plugins which you think might be running slowly and especially those that hook into the serial communications.)
The serial cabling itself would be unique to the Raspi version of this. Does it have a ferrite core? If not, then there could be serial errors which could slow down the throughput.
@OutsourcedGuru no i don't have ferrite core on USB cable, but i never seen that on aUSB cable
@tedder42 I disabled all the plugins I had installed, it seems better.
I only have to find the culprit.
but I have the impression that it does not take much to disturb an impression with a raspberry
Stepper motor circuits make for a noisy electromagnetic field and these signals are induced into the serial line if it's not shielded with a metallic braid. Alternately, the soft metal ferrite core beads help to block high frequency noise.
Just querying if you have upgraded mainboard and stepper drivers. If you are running stock hardware then I believe the factory mainboard has fixed 4988 stepper drivers which are running at 1/16th stepping.
Too higher micro stepping and too much speed can reach the capacity of the 8bit processors (which yours is). If you are running default hardware then you are fine.
I have 3 raspberry pi 3b+ 2 running octoprint and another nanodlp none have any issues with performance. My fastest FDM is running at 90mm/sec with 1/32th stepping and dual belt geared extruders at 1/16th.
Do you have your baud rates set correctly? I think 115200 is correct for your mainboard and usb interface.
With correct settings I have only ever seen pauses and freezes during printing when I have tried 1/64th stepping on my geared extruders, this resulted in stuttering during retraction heavy segments and ultimately failed prints as temperatures didn't get promptly reported back and fail safes kicked in.
The pauses are not happening at layer changes are they?
Hello @mungbean,
Thank you for the explanations. I did not upgrade the motherboard of my CR-10S, I only updated the firmware (TH3D U1.R1.8i) yes me baudrate is at 115200. hard to say for the changes of layers.
I have a gcode file that with octoprint creates breaks of more than 3 seconds (https://ufile.io/vx0xj) https://www.thingiverse.com/thing:686111
i add a video with my problem (play with sound) : pb octoprint.zip (446.3 KB)
Hello,
I tried running the previous Gcode directly from the new instance of octoprint (windows) and I have the same problem.
for my previous test I had a difference with my raspberry (octoprint) and windows (octoprint), now after having optimized my plugin configuration of octoprint it's the same.
but i still have lag, much less, but still on some gcode files
First, I am a real novice with the Raspberry Pi unit. However, I did have a problem with mine that was solved by powering it with a wall wart with more output. You should have a 5 volt supply with at least 2 amps, preferably 2.5 amps. The unit may be starving for current and waiting for small periods of time unit the power supply can catch up with the output. Just a guess, but you problem sounds like hardware, not software.
ALan
