I see these type of problems when using octoprint on a fine mesh typically. The printer slows down and cannot work fast further as the internal buffer is almost empty. OK, this is not intended, all right.
The reason for the low level buffer can be either the octoprint server is not capable to deliver sufficient many lines of g code in a given time period (i.e. the CPU/IO scheduler of the RPI is overloaded) or the problem is the communication itself (i.e. the USB line is the bottle neck).
In the above mentioned link the main reason for these type of errors are assumed to be of the way of transport. So the educated guess in this topic (I just call it like this, no offence) is that the USB is not capable of transferring sufficiently data over the line.
In my setup I see quite some load on the small RPI. It gets laggy while printing etc. When monitoring the RPI's health state, I would assume problems with real-time processes anyway. However I am not perfectly sure, if this is true.
As I play with the idea to upgrade the hardware (either orangepi or even a small i386 based solution), I would like to know if the problem is of computational nature (the RPI is simply too weak) or a problem of the USB connection. In the latter case, the upgrade might be useless.
To get a reliable statement, I would like to measure some timings. How many bytes are transmitted per second (to compare with the baud rate)? How long does octoprint wait for confirmation by the printer's firmware? How long does the transmission itself take (compared to the overall transmission-waiting-confirmation cycle)?
Do you have any idea to get a bit more insight here?
I have been using Octoprint for a year now with a PI 3B+ and have had no such issues. Infact the reason I went with the Octoprint and a PI is because my windows 10 would suffer stalls do to windows inability to multitask and slice cpu time well. Linux has no such issues. Looking at my CPUs most are idle as the print runs, the chrome interface I have running on the PI Head takes up about 58% or one core.
Might want to try a new USB cable.. Install sysstat package and nmon to get some OS monitoring tools and see what your Pi is doing.
you can "check" by doing the same print on the SD card vs through Octoprint. Which Pi do you have? If you run "sudo htop" you can watch all of the cores.
Unfortunately not possible by comparing with SD. This is what I want to avoid as I do not know if the PI or the USB connection is the problem.
It is a RPI 2. Running htop (do not use sudo with it. You do not need it), I see that my CPU is quite buy doing things. Much of it comes from Octoprint.
This is also the reason, why I was so focused on tracking down the real issue: In the right column of the header up there, a so called load average is printed. This is the number of currently pending processes. It should be smaller than the number of CPUs otherwise some process will for sure be stalled. This rises clearly above 1 (single core RPI) during printing.
I will try another cable, soon. At the moment the printer is not running (no needed parts ready to print).
I have munin runnin in the network, should not be too complicated to add one more machine . I hope 5min resolution will be sufficient? Otherwise I will have to look into sysstat and nmon.
As I understand you want to check the bottleneck.
I don't quite understand the USB problem, because it is capable of sending (USB 2.0) around 20 MB/s. So not the transmission is the problem. Assuming it's 2.0 not 1.0.
you can check - as previously said "htop" or "top", you can also monitoring the serial port, for example:
You can "nice" the OctoPrint all processes a little so they would get more stable CPU constant access. I would also checked how much data is transferred to/from a sdcard where the operating system is. I would guess that can be a problem because those cards aren't too fast and when some data waits to get access to "hard drive" it can also block the USB sending. It would be command "iotop" as I remember correctly.
At the moment the printer is not running (no needed parts ready to print).
Not needed, Just prepare any printing in the air, for example 1 cm over the bed with extruder command cut off. It would send normal printing, not needed heating, not filament use and you can test it for hours.
Honestly, investing in the Raspberry Pi 3B upgrade is like $35 and is the first thing I would have done.
If I were considering leaving the pure-Raspberry space and go with a competitor, I think I would choose something with USB 3.0 support in addition to at least doubling the 1GB RAM ceiling that the Raspi 3B has. Maybe this beast with a wi-fi dongle.
I have just found usbtop, I guess it can be very helpful
Bus ID 1 (USB bus number 1) To device From device
Device ID 1 : 0.00 kb/s 0.00 kb/s
Device ID 2 : 0.00 kb/s 0.00 kb/s
Bus ID 2 (USB bus number 2) To device From device
Device ID 1 : 0.00 kb/s 0.00 kb/s
Device ID 4 : 141.73 kb/s 13777.68 kb/s
Device ID 5 : 9.98 kb/s 11.24 kb/s
Device ID 6 : 0.00 kb/s 0.00 kb/s
Device ID 7 : 0.00 kb/s 0.00 kb/s
Device ID 8 : 141.71 kb/s 15257.26 kb/s
I doubt if you will be getting 20MB/s out of a USB connection to most printers. A good number of printers that have a 32bit processor will be using the LCP176x device. These typically only support USB 2.0 Full speed mode (at least in the way they are used on printer control boards) which gives you 12MBits/s so probably around 1.5MBytes/s at best (and in reality less than that). Many of the other 32bit processors also only support the same mode. But this is still pretty fast for transferring gcode. What is probably more of an issue (as explained in the USB thread), is the protocol used over this connection which basically uses a send and wait system (send a command wait for the ok, send the next command), which can reduce the actual throughput considerably.
I'm not aware of any control boards that support USB 3.0, though I'd be happy to be proved wrong.
Yeah, sorry, I think I live in an ideal world where USB 2.0 is always High Speed.
I've installed the usbtop and printed a small detail.
The max speed to my Anet A6 I've noticed was 11 kb/s
when my camera is around 15260 kb/s
It is sending commands and there is even a 8 seconds gap (when doing skirt).
At first layer it was 1,12 kb/s quite constant, at speed 20 cm/s
Rest of printing (40-60 cm/s) around 0,6-3 kb/s and still gaps (up to 2 sec).
What is curious - speed to and from device is very close, 1,60 / 1,30 kb/s like almost every command has it's response.
Edit: by gap I mean 0,00 kb/s
Edit2: CPU is up to 15%, memory 8%
Edit3: Still - Full Speed is up to 12288kb/s, simple printing 10 kb/s. 100 times more is still 1/12 capable bandwidth (or 1/6 counting both ways, I cannot remember is 12Mb/s for one direction or both). I think it should be no problem with a USB connection.
I never had gaps so long, but please can you confirm that you print the first layer with 200mm/s and the other layers with 400 - 600mm/s ? is it centimeters what you wanted to say or milimeters ?
I noticed I have some problems when trying to increase the speed, on my DIY printer I usually print the inlay and inner walls with 80 - 100mm/s, the outer wall with 50mm/s, but to have a smooth "gap free" / stuttering free printing process I had to lower the MAXIMUM RESOLUTION in Cura, from 0.01mm to 0.1mm, after this change the printing process is running smooth - but a new problem shows up as the big radius lines are made by some 5mm long straight line, and this is where I don't understand what Maximum Resolution means, because 0.1mm is a small number, if the minimum distance between 2 gcode lines in term of X / Y coordinates will be 0.1mm (what I would expect when setting the resolution to 0.1mm) I don't know why I have some straight line segments so long, about 5mm long each
I want also to start a discussion also on Cura forum, to better understand what 0.1mm maximum resolution means for Cura developers.
I also try to find out if getting an MKS Base 1.3 32bit controller will help in terms of computation power, when trying to print fast (over 100mm/s) and with a high resolution set in slicer (0.01mm is high for me) I think not the USB link is the problem, anyway I'm not sure it's USB but Serial over USB, and the limits should be because of Serial connection on the controller side, not on the Raspberry Pi
Will a 32bit controller receive more information over the usb compared to an 8bit controller (when printing fast with 100mm/s - 150mm/s)?
PS. I haven't cleaned the prints, not even the BRIM completely.
At such low speed there shouldn't be any problem , even with the resolution set to 0.01mm. What I try to achieve is to print faster, and so far my only problem is related to this stuttering issue when printing fast and in high resolution (lower than 0.05mm).
Anyone knows if the 32bit MKS Base 1.3 board will solve this issue?
Regarding the photo above, I forgot to mention that all prints (1 - 2 - 3 - 4 - 5 - 6) ware made using print speed between 50mm/s - 60mm/s for the outer wall, and from 80mm/s - 120mm/s for the internal walls, the main difference between them was the change of resolution, as you guys can see the 3rd one is very nice on the exterior because I tried to print first the external wall, and the internal walls after, that is a 0.01mm resolution print, the exterior is perfectly smooth with no visible straight lines, to form the big radius, but on the internal walls the print is as bad as #5 .
For the first two prints #1 & #2 I used MAXIMUM RESOLUTION of 0.1mm in Cura, so there is no stuttering happening but you can clearly see the large straight segments that form the bog radius
. I hope 5min resolution will be sufficient? Otherwise I will have to look into 