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...
LOL... Looks like I missed the funny little timeline in the upper right. I did actually look for a date, and saw the July dates, so assumed it was last year. Oh, well.
My question comes from quite a bit of speed testing on SD cards related to videography. SD card IO can be a massive bottleneck, even on Class 10 cards.
1 Like