Differences

This shows you the differences between two versions of the page.

--- kb:proj:ftg:auto_printer [2026/09/24 02:36] – removed - external edit (Unknown date) 127.0.0.1
+++ kb:proj:ftg:auto_printer [2026/09/24 04:03] (current) – robertk
@@ Line 1: / Line 1: @@
+====== Auto Printer ======
+<note warning> The Auto Printer project is no longer maintained. It is based on an outdated printer and because the bulk of my projects are one-offs 24/7 production is not required</note>
+===== About =====
+The goal of this project was to create an automated FDM 3D printing setup. It was based on a Prusa i3 MK3S+ printer. Initially, I had planned on starting a print farm, but after some market research I found that wouldn't be a good use of my time. I still built out an automated printer to learn more about 3D printing technology and firmware.
+To make the Prusa print and eject parts I developed a system with 4 basic parts:
+  * a custom FR-4 print surface that allows prints to release automatically at ambient temperature
+  * an Arduino controlled bed scraper
+  * an actively heated and cooled chamber
+  * a custom version of the firmware to send commands to the arduino using g-code
+==== Build Plate ====
+FR-4 and G10 are popular and now fairly common build plate materials. The advantage of FR-4 is inherent flame-retardant characteristics. This is the same material that most circuit boards are made out of. What makes it a great build surface for 3D printing is that at ambient temperatures it has a low surface energy, meaning other materials stick to it poorly, but at higher temperatures it has a much higher surface energy. This means that most common filaments stick aggressively to FR-4 when it is heated and release automatically when it is cooled. I ordered some custom spring steel sheets and laminated FR-4 to the surface to create a build plate suitable for part ejection.
+==== Bed Scraper ====
+The bed scraper used two u-shaped photo-electric sensors, a geared motor, and an arduino. Because the Prusa parts are open source, I was able to download and modify them to also act as supports for the scraper. The Arduino contained simple logic that received a signal from the 3D printer control board to raise and lower and ran the geared motor until it could confirm the position of the scraper using the photo-electric sensors.
+This took several CAD revisions and prints to make perfect, because the exact trigger point of the sensor was consistent but not accurate between sensors. In hindsight, I would have made the positions of these sensors more adjustable from the start rather than having to iterate the physical configuration through prints.
+==== Chamber ====
+The chamber was a simple extruded aluminum frame with fiber reinforced concrete poured as a base. This with some custom printed feet allowed the printer to be held at an angle.
+The same Arduino that ran the scraper was also used to control the chamber temperature. A small resistive heater was used to raise the temperature and a circulatory and exhaust fan were used to homogenize and decrease the temperature. The exhaust fan was also equipped with a simple low pressure membrane , all air was retained in the chamber and when the fan kicked on the slight differential pressure opened the membrane and allowed air to be exhausted.
+To allow part ejection and air circulation for cooling, a servo actuated door on the front of the chamber was also controlled by the Arduino.
+==== Custom Firmware ====
+To tie this whole system together, I had to edit the printer's firmware. This is much easier than it sounds. The firmware is open source and well documented, so I added a macro that responded to a specific m-code and used one of the extra headers on the control board to signal the Arduino. The Arduino itself handled all of the scraper and temperature logic. It would have been possible to set the chamber temperature with g-code, as is done in most modern heated chamber printers, but I found it simpler to set the temperature with a potentiometer and allow the Arduino to do all of the cooling and ejection logic. This was a suitable solution because I rarely changed filament type, but it was a bad design decision because it ignored convention.
+===== Logic Outline =====
+Once the m-code for ejection is sent, the control board signals the Arduino. The logic then follows these steps:
+  * chamber heater off
+  * chamber door open
+  * exhaust fan on
+  * wait configured period
+  * lower ejection arm
+  * move bed to rear
+  * chamber door close
+  * camber heater on
+Over a 48 hour period I had a single failure. The main limitation of this system is that the control board communicates with the Arduino but the Arduino had no way to confirm or communicate a successful ejection to the control board.
+For a completely naive approach, this setup worked surprisingly well, but it really falls short as far as integration is concerned. It relies and the wait between g-code and Arduino matching and lacks communication for confirmation. I did not pursue the project further because I decided I had learned what I intended to when I took it on.

FTG Wiki

User Tools

Site Tools

Differences

Page Tools