Prusas own blog about timelapse for mk3s+ and 2.5 possible solution for the MK4?
Hi everybody
I looked at the old Timelapse Prusa Blog Post by prusa. Here they descripe how to attacht to the Einsy board. Is there no chance of doing something similar with the MK4? I have no idea of what electronics are used on the MK4, was hoping somebody here could clarify whats possible and not.
RE: Prusas own blog about timelapse for mk3s+ and 2.5 possible solution for the MK4?
Hello there, i have the same question!
RE: Prusas own blog about timelapse for mk3s+ and 2.5 possible solution for the MK4?
The Mk3S+ and older used a Rambo board to control the printer. This is an 8-bit board and was pretty much topped out with what it could do. The Mini, XL and MK4 all use a 32-bit board that is custom designed, built and assembled by Prusa. To the best of my knowledge, it has not been released to "Open Source", so there are probably no schematics to reverse engineer how to wire a camera up to these.
That means that unless someone really good with deriving schematics from live circuits, and is willing to risk destroying a one or more of these boards, it's unlikely a solution for mounting a triggered camera directly to it will be done. Prusa will likely need to tell us how to do this or better yet provide this cable, since they hold all the "cards"...
RE: Prusas own blog about timelapse for mk3s+ and 2.5 possible solution for the MK4?
The CPU that Prusa is using is barely powerful enough to handle low speed networking when the printer is not running. There is no way it has enough power to stream even still's for time lapse photography.
Prusa's idea of using a phone and their connect app is a joke and not well thought out from the users standpoint.
On the MK3 a Raspberry Pi Zero (about 1000 times more powerful than the 8 bit CPU running the printer) was used for all network and WiFi activity including video streaming.
RE: Prusas own blog about timelapse for mk3s+ and 2.5 possible solution for the MK4?
The obvious solution is a Pi, but if Prusa takes a step back and looks at the overall situation, they'd realize the obvious solution is to fully embrace Octoprint. That is a time-proven solution that works very well. Slap a microSD loaded with linux and octoprint in a Pi4b and you have the ideal solution. It's fast, reliable and can even support a touch screen (visually displaying progress, working around the MK4 minimal support for Octoprint). There are even Mods that do great jobs of handling timelapses. Personally, I don't do timelapses often because they tend to screw up the prints. The mod support for Octoprint is incredible.
The only way Prusa can hope to create something as effective and efficient as Octoprint, is to make something like it. Their instance of the Cloud based printing is horrible for those on the other end of the world from the Czech Republic (assumes that is where the server cloud hardware is located)... Just loading gcode takes a LONG time, whereas when loading gcode or bgcode on octoprint takes 3-6 seconds typically.
RE: Prusas own blog about timelapse for mk3s+ and 2.5 possible solution for the MK4?
The obvious solution is a Pi, but if Prusa takes a step back and looks at the overall situation, they'd realize the obvious solution is to fully embrace Octoprint. That is a time-proven solution that works very well. Slap a microSD loaded with linux and octoprint in a Pi4b and you have the ideal solution. It's fast, reliable and can even support a touch screen (visually displaying progress, working around the MK4 minimal support for Octoprint). There are even Mods that do great jobs of handling timelapses. Personally, I don't do timelapses often because they tend to screw up the prints. The mod support for Octoprint is incredible.
The only way Prusa can hope to create something as effective and efficient as Octoprint, is to make something like it. Their instance of the Cloud based printing is horrible for those on the other end of the world from the Czech Republic (assumes that is where the server cloud hardware is located)... Just loading gcode takes a LONG time, whereas when loading gcode or bgcode on octoprint takes 3-6 seconds typically.
You are preaching to the choir here. With the advent of very powerful low cost multi-core ARM CPU's I am very surprised Prusa took the route they did. I believe they were trying to save pennies on a $1000 printer.
I understand the need for a deterministic processor to run the printer. On a multi-core CPU one or more cores could be dedicated to the printer and the other core or cores could be dedicated to Networking, display, octoprint, etc.
As for Prusa's ridiculous cloud and web software. I think they took the software they wrote for their factory and dumbed it down for small farms. Forgetting that a majority of their users own one or two printers. Again, the MK3 networking software was orders of magnitude better than the more expensive "better" MK-4.
Don't get me wrong, I love my MK-4. However, it has some huge flaws, most that relate to end user experience, that should just not be there in a printer from Prusa.
If I don't get my MMU3 soon, I will seriously consider selling the MK-4 and getting a Bamboo.
RE: Prusas own blog about timelapse for mk3s+ and 2.5 possible solution for the MK4?
The XL has recently made huge leaps in stomping out design/software bugs. Most of the major issues have been resolved, but yes there is still a lot of room for improvement, especially in a printer that costs as much as it does. That said, with 5 printheads, there is a lot of capability with that printer. In terms of filament efficiency, the Bambu Labs wastes a LOT more filament with every color change than the XL does. A few simple wipes on the tower and the XL is ready with the next color. The Bambu Labs multi color literally poops a basketful of wasted filament every print! With the XL or the Prusa MMU, you save a lot of money on filament, compared to the Bambu Labs multi color... This becomes a huge financial issue if you get into the higher end industrial grade filaments, (PEEK, ASA, PC-CF, etc...)