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!
1 Like
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.
1 Like
And remember: when profiling all this, run in SAFE MODE to rule out the possibility that a plugin could be the cause.
- OctoPrint sends the first tiny line segment on its way to the printer...
- Plugin1 is hooked into the outbound gcode event stream and thinks about things...
- Plugin2 is hooked into the outbound gcode event stream and thinks about things some more...
- Plugin2 is done thinking about things and its handler returns
- Plugin1 is done thinking about things and its handler returns
- OctoPrint now has control again and sends it to the printer.
I'm reasonably certain that this is the call stack and how things probably work.
1 Like
@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.
2 Likes
Yep, pretty much! Only a minor difference, plugin hook handlers are called sequentially, not recursively:
GCODE line -> OctoPrint -> plugin 1 -> OctoPrint -> plugin 2 -> ... -> OctoPrint -> printer
1 Like
I'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.
1 Like
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
1 Like
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...
Hi @red_dragonlord71!
You already opened a topic for this. It's not necessary to post a question twice.
hi there,
no, I don't use them both at the same time.
actually, I'm getting some conflicts between them, was getting, because I removed MKS, don't see much sense to have it if I have OctoPI +similar app on my smartphone (android) 
Love it !
Do not hate what I'm going to say now. It's only one idea.
In my idea, the comunication between Octoprint > Printer board is more critical than Printer board > octoprint.
Thinking outside the box, different from the workflow used so far.
If we use SD card as default to print with octoprint and create a way to manage it (send data of gcode from board to raspberry).. we will have the best of SD card with less load in raspberry.. but how manage, how firmware will need send data to octoprint?
It would require work on the current firmwares to fit the new gcode processing view. But if we do not lead this, it will never be done.
Similar to how Microsoft did with Windows mixed reality, all devices have the same hardware (required by MS)
Sorry if you did not like the idea or thought it was crazy.
It's only one idea. Solve the slowness of serial communication is very important to us.
1 Like
What about the video stream; does that not write to the disk?
Hello @CareyB !
Timelapses are stored as single images, not as stream. After print they are renders to the stream.
Besides, you referred to a post that is 5 years old.
Things may have changed...