At this point I understand what I need more powerful hardware to send commands to printer than Raspberry 3B+ to print faster.
Can it be also a communication delay only ?
Like, getting commands from SD card happens much faster than sending them thr USb cable?
In this case the solution can be a buffer on a printers' side, right ?
No, don't blame Marlin. Don't blame any specific firmware. It's more a case of there being so many variants out there and so little consensus on what would be needed to make things work better that I don't see anything happening here. Especially not considering how the last time went 
The printer already has not only one buffer but depending on your firmware up to three (which btw is also why it's impossible to know when a command that was sent actually gets executed - the acknowledgement does only mean it was received).
Transmission speed is influenced by a multitude of factors. I stated some from the software side, then there are also potential RX/TX buffers inside the USB-to-serial driver (especially under windows the default of 16ms TX window in the FTDI driver can be a fun surprise), firmware processing, multithreaded python simply not being able to keep up, the underlying system being busy elsewhere and so on and so on. There's not one single reason.
If you want maximum speed, use SD. Personally, I've never found myself in a situation where it was SD or nothing, but hey, your mileage may vary.
Also makes sense to check that the slicer profile isn't outputting segment sizes that simply don't make any sense (e.g. shorter that twice the nozzle width or something around that).
But in any case, you WILL hit a ceiling, regardless of what kind of hardware and software you use, and that ceiling WILL be lower than what you can achieve by just printing from SD (whether those transmission speeds are really needed for actual usage is another debate).
I see.
And thank you, once again, for your patience explaining all things over and over again 
So, 1) use the Upload to SD button and 2) print from SD. It prints quickly and leaves OctoPrint out of the serial communications business. I'd guess that you lose: 1) Gcode Viewer, 2) PauseAtZ and similar plugin behavior. In theory, timelapse and video still work.
For what it's worth and on a semi-related note, I got that FlashForge Creator Pro at work to print from SD with OctoPrint. The GPX plugin wouldn't allow it to successfully print over serial.
Yeah, and I was doing that before assembled a new printer with a MKS TFT 2.4 screen (which has SD card), and... it freezes and stops printing at some moments.
Here is the bug I created: https://github.com/makerbase-mks/MKS-TFT/issues/169
So it's not reliable, and I have to use Octoptint, which I LOVE !
Just want to have it working faster 
This seems to have been overlooked. No, more CPU probably wouldn't help, because the serial connection is the bottleneck.
How large are your files, and what's the overall print time difference? I mean, is it 10 hours vs 30 hours?
The print time from sd card (MKS TFT 2.4) is 4:54, and the same model from octoprint takes 5:45, ~50 seconds difference, 20% slower.
The file is quite small, but I cant tell you exact file size because im away from my printer now.
If the serial connection is the bottle neck when... I was told by MKS TFT 2.4 support team (?) In the github link I posted above that TFT 2.4 and raspberry works on the same serial line:
The motherboard cannot use USB and TFT at the same time, because they are the same serial port, data conflicts.
Does it mean motherboard uses the same data line to talk to TFT and raspberry ? If yes, then why TFT is "faster" ? I mean I have assumptions why it faster and we talked about this (like Octoprint does a lot of calculations) in this thread, I just mean if the serial line is a real bottleneck.
I can confirm what he is seeing on my modified Anet A8 with a MKS Gen V1.4 board running Marlin 1.1.8. This is a new bug with 1.3.9. When it needs to send command rapidly, as in circles/rounded corners, or sending rapid straight lines, the printer jitters like it can't receive commands fast enough, stop and go. There doesn't appear to be any errors in the Terminal. I was also able to confirm that downgrading Octoprint to 1.3.8 (which I was running prior to 1.3.9, fixes the problem and everything works as expected. I'll be happy to help debug between prints. Thanks!
Then please open a proper a ticket and be sure to also test if this issue persists in safe mode and hence isn't caused by any third party plugin you might have installed - I'm aware of at least one issue with a prior version of PrintTimeGenius that led to throughput problems.
Interesting, can you do more testing (like @foosel asks) please ?
I can't do my own tests this time because I disassembled my printer.
I came here after seeing jittering in prints since 1.3.9. When I upgraded I also installed the most recent PrintTimeGenius on 2 printers. After reading this I deleted that plugin from 2 printers. The problem went away on both using the exact same gcode each time. Might want to flag that plugin. It presents itself with millisecond stops, especially printing circularly. It is recognizable by small zits/blobs on outer surfaces.
CR-10 and Ender 2 both running latest TH3D Marllin builds. Raspberry PIs one wireless, one wired.
And remember: when profiling all this, run in SAFE MODE to rule out the possibility that a plugin could be the cause.
I'm reasonably certain that this is the call stack and how things probably work.
@foosel, I'll be sure to do as you requested this evening when I do another print. I apologize for not going through the proper channels. While looking for a fix for this, I ran into this thread first and thought I'd contribute.
Thanks!
You were right. It printed correctly in Safe Mode. I'll try to track down which plugin is to blame.
Yep, pretty much! Only a minor difference, plugin hook handlers are called sequentially, not recursively:
GCODE line -> OctoPrint -> plugin 1 -> OctoPrint -> plugin 2 -> ... -> OctoPrint -> printerI've experienced the same behavior. In doing some tests, I reverted to OP1.3.8 and had no stuttering. I updated back to 1.3.9 and the stuttering began on a 35mm cal cube with curved corners and a 35mm cylinder. Reloading the UI on any client device really caused huge amounts of stuttering. I reran cylinder prints in safe mode and voila.. no amount of reloading the UI caused any stuttering issue. Since I'm changing too many variables in my testing, I'm afraid I'm not able to definitively pin point which plugin it is. I will try some additional prints shortly...
Update: A print with PrintTime Genius enabled retained the stuttering with reloading the UI. A print with PrintTime Genius disabled did not stutter with reloading of the UI. I think it has printed fine with the plugin enabled and NOT using the client UI, since i've done many prints since 1.3.9 install and didn't notice any blobs, but I have noticed since 1.3.9 that my skirts have lots of blobs (since they're typically "curvy" perhaps?).
I'm running on the newest RPI3+, with a 35% cpu using crappy webcam (PSeye).
The solution for me is turning off the Genius, unfortunately because I really like that plugin.
Okay, now bring in the plugin author by creating an participating in the open issue on his/her github.
In a case like this, they'd do some profiling and determine what's running slowly in their own code.
Hi everyone,
Just tested how Octoprint would print a test model (not a complicated one, but has some circles) with a web camera.
I haven't checked the camera settings, but I suppose it's quite smart and don't require Raspberry to handle the image.
But anyway, it's like additional load on CPU, right ?
So I tested on 120mm speed, and guess what - no changes in printing with and without camera (I restarted Octoprint to make sure it's disconnected from the camera after I plugged off one).
I opened the control page in my browser to watch camera all the time during the print.
How can it be what the camera stream did not affect the speed of sending commands ?
Does it mean what my limitation is the serial bus (USB cable + etc) between Raspberry and MKS Gen 1.4 ?
Thanks,
Dima
The Raspberry Pi 3B and the + version have four cores in its processor. On my printer's TFT screen I watch the load on a per-core basis. See the bottom-right graph.
When a timelapse or webcam event is going, one of the cores will be busy. Most of the time only one of the cores is busy with serial-based activity streaming that to the printer.
What can happen is if a plugin is hooked into OctoPrint's gcode streaming and that plugin doesn't immediately return control. This results in sluggish behavior in OctoPrint.
Hi, sorry if I disturb but are you able to have Octoprint and MKS TFT Touch display working at the same time on a MKS GEN 1.4?? Are you using Marlin Firmare? I've bought the same card and the MKS TFT28 V4.0 Touch Display but everyone says that this display doesn't allow to use Octoprint due to the fact that Marlin can use only one serial comunication....I don't understand...