User Tools

Site Tools

Differences

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

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
mission:resources:picoprint [2015-03-27 09:16] – [Electronic Components] chronomission:resources:picoprint [2016-03-16 12:29] (current) – [Electronic Components] chrono
Line 102: Line 102:
 Since it was undesirable to print from SD-Cards or having to install software on clients, which would need to remain with the printer while processing jobs, the Felix has been rigged to become a fully autonomous and web-enabled 3D printing robot, we may use, control and monitor from any laptop, tablet or mobile phone, from anywhere.  Since it was undesirable to print from SD-Cards or having to install software on clients, which would need to remain with the printer while processing jobs, the Felix has been rigged to become a fully autonomous and web-enabled 3D printing robot, we may use, control and monitor from any laptop, tablet or mobile phone, from anywhere. 
  
-{{:mission:resources:img_20150208_132519.jpg|}}+{{:mission:resources:felix-3d-printer-ramps-board-with-odroid-c1-backpack1.jpg|Felix 3D Printer RAMPS board with Odroid C1 Backpack}}
  
 The design and structure of the brain and nerve system of this robot are a cybernetic rip-off of nature: Basic human design. There are a couple of low-level muscles (motors/actors), tactile sensors (end-stops), environmental sensors (extruder + bed temperature) and energy conversion systems.  The design and structure of the brain and nerve system of this robot are a cybernetic rip-off of nature: Basic human design. There are a couple of low-level muscles (motors/actors), tactile sensors (end-stops), environmental sensors (extruder + bed temperature) and energy conversion systems. 
  
-These are connected to the ATMega2560 microprocessor on the electronics board, which acts as a cerebellum that is trained (calibrated) specifically to move its actors and control all converters as precisely as possible. +These are connected to and controlled by the ATMega2560 microprocessor on the electronics board, which acts as a cerebellum, which is trained (calibrated) specifically to move its actors and control all converters and heaters as precisely and as close to real-time as possible. 
  
 All high-level functions like seeing (webcam) and user-level control & communication are handled by an embedded GNU/Linux board, which acts as cerebrum to conveniently host, maintain and access other open-source software components and offer networking out-of-the-box as well as a lot of flexibility. Many high-level features can be done in software, which replicates much faster in an all open-source environment. All high-level functions like seeing (webcam) and user-level control & communication are handled by an embedded GNU/Linux board, which acts as cerebrum to conveniently host, maintain and access other open-source software components and offer networking out-of-the-box as well as a lot of flexibility. Many high-level features can be done in software, which replicates much faster in an all open-source environment.
- 
-{{:mission:resources:picoprint-dual-head-wiring-diagramm.png|picoprint-dual-head-wiring-diagramm.png}} 
  
 Although we love the Raspberry Pi and already have a few [[https://apollo.open-resource.org/tag:raspberry|projects]] featuring it, this robot called for a little more computing power, multicore architecture, 1G RAM and more GPIOs, SPI, I2C etc. which will become even more useful for future feature extensions.  Although we love the Raspberry Pi and already have a few [[https://apollo.open-resource.org/tag:raspberry|projects]] featuring it, this robot called for a little more computing power, multicore architecture, 1G RAM and more GPIOs, SPI, I2C etc. which will become even more useful for future feature extensions. 
Line 118: Line 116:
 The whole 2.0 duration of the setup was run on a [[http://www.watterott.com/en/Cubieboard2-Open-ARM-Box?x7ae9a=aedb9ba8f7b29ab7e49dbeaf24ce5bf5|Cubieboard2]] as basic underlying embedded Linux board for high-level interaction. Experience has been ok, timelapse rendering took still a considerable time though.  The whole 2.0 duration of the setup was run on a [[http://www.watterott.com/en/Cubieboard2-Open-ARM-Box?x7ae9a=aedb9ba8f7b29ab7e49dbeaf24ce5bf5|Cubieboard2]] as basic underlying embedded Linux board for high-level interaction. Experience has been ok, timelapse rendering took still a considerable time though. 
  
-{{:mission:resources:felix_3d_printer_7_cubieboard2.jpg|}}+{{:mission:resources:picoprint_schematics.png|Felix 2.0 3D Printer with Cubieboard2 Wiring Diagram}}
  
 === Odroid C1 === === Odroid C1 ===
  
-With the 3.0 dis- and reassembly process the Cubieboard2 was replaced by an [[http://odroid.com/dokuwiki/doku.php?id=en:odroid-c1|Odroid C1]] Quad-Core ARMv7 (Cortex-A5) Board. Since the Odroid directly comes with 4 USB Ports the necessity for a separate USB switch fell away, not to mention the added I/O boost eMMC gives. With a custom, stripped down kernel and gentoo as OS, the cold boot time until octoprint is ready to use, is about 14 seconds (2s kernel + 12s init+dhcp+services). The RGBW Status led is controlled directly via C1 GPIOs. With the power of 4 cores, the timelapse videos are no longer mjpgs since the C1 leaves enough reserves to render the videos with high quality x264 compression.+With the 3.0 dis- and reassembly process the Cubieboard2 was replaced by an [[http://odroid.com/dokuwiki/doku.php?id=en:odroid-c1|Odroid C1]] Quad-Core ARMv7 (Cortex-A5) Board. Since the Odroid directly comes with 4 USB Ports the necessity for a separate USB-Hub fell away, not to mention the added I/O boost eMMC gives. With a custom, stripped down kernel and gentoo as OS, the cold boot time until octoprint is ready to use, is about 14 seconds (2s kernel + 12s init+dhcp+services).  
 + 
 +{{:mission:resources:picoprint-odroid-dual-head-wiring-diagramm.png|Felix 3.0 Dual-Head 3D Printer with Odroid C1 Wiring Diagram}} 
 + 
 +The RGBW Status led is controlled directly via C1 GPIOs. With the power of 4 cores, the timelapse videos are no longer mjpgs since the C1 leaves enough reserves to render the videos with high quality x264 compression. A perfboard was strapped onto the the Odroid C1, for internal power distribution, additional connection terminals, the [[mission:log:2015:02:06:patching-kernel-ntp-to-fix-odroid-armv7a-chrony-adjtimex-bug|RTC hack]] and a couple of MOSFETs, to control the RGB Status LED and the table lighting LED stripe. 
 + 
 +By hooking up the Cubieboard2/Odroid C1 to the 5V StandBy (purple) rail of the power supply, the robot is always online and ready to print with minimal power consumption. The full chain of Cubieboard2 (idle), USB Hub, USB Camera and USB Stick for additional storage needed for creation and storage of timelapse videos, draws something between 2 and 2.5 Watt (0.4-0.5A@5V). That's well below the Power Supply's StandBy Rail Maximum Rating of 2A while keeping the printer fully remote accessible. Here are a couple of notes about [[mission:resources:picoprint:software|cross-compiling and installing Gentoo on the Cubieboard]]. 
 + 
 +** Mounting ** 
 + 
 +To mount the Odroid C1 permanently on the printer, a new friction tight part was created and printed which replaced the original plastic slide-in plate of the power supply's case with this:
  
 {{:mission:resources:felix-3d-printer-case-extension-odroidc1-openscad-front.jpg?320|felix-3d-printer-case-extension-odroidc1-openscad-front}} {{:mission:resources:felix-3d-printer-case-extension-odroidc1-openscad-front.jpg?320|felix-3d-printer-case-extension-odroidc1-openscad-front}}
 {{:mission:resources:felix-3d-printer-case-extension-odroidc1-openscad-back.jpg?320|felix-3d-printer-case-extension-odroidc1-openscad-back}} {{:mission:resources:felix-3d-printer-case-extension-odroidc1-openscad-back.jpg?320|felix-3d-printer-case-extension-odroidc1-openscad-back}}
  
-By hooking up the Cubieboard2/Odroid C1 to the 5V StandBy (purple) rail of the power supply, the robot is always online and ready to print with minimal power consumption. The full chain of Cubieboard2 (idle), USB Hub, USB Camera and USB Stick for additional storage needed for creation and storage of timelapse videos, draws something between 2 and 2.5 Watt (0.4-0.5A@5V). That's well below the Power Supply's StandBy Rail Maximum Rating of 2A while keeping the printer fully remote accessible. Here are a couple of notes about [[mission:resources:picoprint:software|cross-compiling and installing Gentoo on the Cubieboard]].+** Final Assembly ** 
 + 
 +{{:mission:resources:felix-3d-printer-ramps-board-with-odroid-c1-backpack2.jpg|Felix 3D Printer RAMPS board with Odroid C1 Backpack}} 
 + 
 +=== Cable & WIFI Network Access ===
  
 +The Odroid C1 already provides Ethernet connectivity, which is accompanied by a USB WIFI Stick (embedded at the top of the Status-LED). The system can be configured to either join an existent WIFI network or act as an access point with its own WIFI network, if there is none available or other reasons (like security policies) prohibit connections. This is a great feature for impromptu class/workshop setups, when you can engage your audience to watch and interact with the printer using their own smartphones, tablets and laptops.
  
 === Power Buffer/Filter Hack === === Power Buffer/Filter Hack ===
  
-To mitigate PWM switch noise and leave more reserve in edge conditions, we needed something to buffer and filter the 12V and 5V power rails, when the system momentarily peaks, reducing the risk of power supply or general system failures while printing. After the 3.0 update, the power supply casing is longer than the original V2.0 eletronics board which leaves about 3 cm of usable space in the case. A quickly hacked perfboard and a couple of capacitors out of the "rests" box later, it looks like this:+To mitigate PWM switch noise and leave more reserve in edge conditions, we needed something to buffer and filter the 12V and 5V power rails, when the system momentarily peaks, reducing the risk of power supply or general system failures while printing. After the 3.0 update, the power supply casing is longer than the original V2.0 electronics board which leaves about 3 cm of usable space in the case. There was also the issue of power distribution and not making a mess while wiring all additional components. As a result, this quickly hacked perfboard with a couple of capacitors, connection terminals and cables out of the "rests" box emerged:
  
 {{:mission:resources:img_20150208_124345.jpg|Felix Power Supply Hack Filter/Buffer Hack}} {{:mission:resources:img_20150208_124345.jpg|Felix Power Supply Hack Filter/Buffer Hack}}
  
 The Room in the middle of the board is intentionally left empty, otherwise it would be impossible to guide the complete set of cables of the printer through there. The bottom of the perfboard was sprayed with urethane to protect/insulate the connections and a non-conductive plastic sheet was inserted between the power supply's casing (top) and the buffer board to prevent DC rail contact with the grounded casing. The Room in the middle of the board is intentionally left empty, otherwise it would be impossible to guide the complete set of cables of the printer through there. The bottom of the perfboard was sprayed with urethane to protect/insulate the connections and a non-conductive plastic sheet was inserted between the power supply's casing (top) and the buffer board to prevent DC rail contact with the grounded casing.
- 
- 
  
 **12V Rail** **12V Rail**
Line 152: Line 163:
   * 1x 100nF 35V   * 1x 100nF 35V
   * 1x 10nF 35V   * 1x 10nF 35V
- 
  
 === Auto Power-On/Off === === Auto Power-On/Off ===
Line 171: Line 181:
 You can also [[mission:resources:picoprint:live|watch the live-feed]] of the framecam, which was implemented using [[https://github.com/OliverF/mjpeg-relay|mjpeg-relay]] to reduce upstream bandwidth saturation. You can also [[mission:resources:picoprint:live|watch the live-feed]] of the framecam, which was implemented using [[https://github.com/OliverF/mjpeg-relay|mjpeg-relay]] to reduce upstream bandwidth saturation.
  
-{{:lab:zephyr:3d-print-timelapse-wind_turbine_blade_helix_lenz2_32cm_dia_19cm.mp4|}}+**Latest 3D Printjob Timelapse Video** 
 + 
 +{{:latest.mp4|}}
 \\ \\
 Having a microscope headcam could prove invaluable for remote machine operation. As soon as time permits we can begin to modify the head parts to accommodate for the energy chains and to place the microscope as well. It's then connected via USB to the Cubieboard via Linux UVC USB Drivers as well and can be accessed via /dev/video1.   Having a microscope headcam could prove invaluable for remote machine operation. As soon as time permits we can begin to modify the head parts to accommodate for the energy chains and to place the microscope as well. It's then connected via USB to the Cubieboard via Linux UVC USB Drivers as well and can be accessed via /dev/video1.  
- 
  
 === Table Lighting === === Table Lighting ===
Line 242: Line 253:
 {{:mission:resources:cura-screenshot.jpg|Cura 15.01 Screenshot - Slicing a part of the ADSB-1090 Antenna Combo model (Layer View)}} {{:mission:resources:cura-screenshot.jpg|Cura 15.01 Screenshot - Slicing a part of the ADSB-1090 Antenna Combo model (Layer View)}}
  
-Preliminary and totally subjective first impression is that Cura has a very limited (user friendly) UI and renders almost in realtime but Slic3r has a couple of advanced options which yield a considerably higher quality print result (i.e. optional randomness for layer starting points for small shells are tremendously helpful) in comparison to Cura. More concise tests, with comparable data of the same part, with different slicers vs. different firmwares will have to be made, to come up with a more objective conclusion.+Preliminary and totally subjective first impression is that Cura has a very limited (user friendly) UI and renders almost in realtime but Slic3r has a couple of advanced options which yield a considerably higher quality print result (i.e. optional randomness for layer starting points for small shells are tremendously helpful) in comparison to Cura, which always seems to leave a very heavy Z-Scar. More concise tests, with comparable data of the same part, with different slicers vs. different firmwares will have to be made, to come up with a more objective conclusion.
  
  
Line 249: Line 260:
 === OctoPrint === === OctoPrint ===
  
-The heavy lifting is handled by [[http://octoprint.org/|OctoPrint]], an open-source package based on python and a websocket/HTML5 webclient. GCode files are uploaded via webinterface and then spooled to the Felix Controller Board running [[https://github.com/ErikZalm/Marlin|Marlin 3D printer firmware]] via 250000 baud (high speed - low jitter) usb-serial link. It also manages the feed of the webcams and will receive a few GPIO gimmicks in the future as well. +The heavy lifting is handled by [[http://octoprint.org/|OctoPrint]], an open-source package based on python and a websocket/HTML5 webclient. GCode files are uploaded via webinterface and then spooled to the Felix Controller Board running [[hhttps://github.com/MarlinFirmware/Marlin|Marlin 3D printer firmware]] via 250000 baud (high speed - low jitter) usb-serial link. It also manages the feed of the webcams and will receive a few GPIO gimmicks in the future as well. 
  
 {{:mission:resources:felix_3d_printer_9_webinterface.jpg|Octoprint Webinterface}} {{:mission:resources:felix_3d_printer_9_webinterface.jpg|Octoprint Webinterface}}
Line 268: Line 279:
 ==== Robot-Firmware ==== ==== Robot-Firmware ====
  
-In order to have full control over the robot and all its aspects, like acceleration values and PID tuning unique to this machine and to have a free development ecosphere where alternative firmwares may be developed, shared and easily adapted & installed, it was important to have a controller running an open-source firmware. The original Felix 2.0 printer came with a forked Marlin FW, with the update to 3.0 things seem to have moved to repetier-firmware-0.92 [[http://shop.felixprinters.com/downloads/index.php?path=firmware/|upstream]] (FELIXrobotics) for dual head support.  +In order to have full control over the robot and all its aspects, like acceleration values and PID tuning unique to this machine and to have a free development ecosphere where alternative firmwares may be developed, shared and easily adapted & installed, it was important to have a controller running an open-source firmware. The original Felix 2.0 printer came with a forked Marlin FW, with the update to 3.0 things seem to have moved to repetier-firmware-0.92 [[http://shop.felixprinters.com/downloads/index.php?path=firmware/|upstream]] (FELIXrobotics) for dual head support. [[https://github.com/MarlinFirmware/Marlin|Marlin]] support has been added recently.
- +
-There is also an [[https://github.com/andrewsil1/FelixMarlin|alternative FW on github]] which is based on a more recent fork of Marlin and includes PID support for the bed, which supposedly increases Z layer stability but needs a hardware mod: Add a 4700uF electrolyte capacitor (25V rating should be enough) over the power supply terminals of the electronics board for stability. +
 ===== Workflow ===== ===== Workflow =====
  
Line 290: Line 298:
 </WRAP> </WRAP>
 ===== Known good parameters ===== ===== Known good parameters =====
-^ Material ^ Ext ^ Bed ^ + 
-| PLA Grey | 195 | 55 |+As a reminder and guide for anyone printing on our Felix as well as to give other people, who may be new to 3D printing, a real world reference/starting point: 
 + 
 +^ Source ^ Material ^ Color ^ Ext. Multiplier ^ Extruder °C ^ Kapton °C ^ Carbon °C ^ 
 +| Felix | PLA | Grey |  1  |  195  |  55  |  -  | 
 +| NuNu | PLA | White |  0.98  |  210/200  |  -  |  75  | 
 +| ? | PLA | Black |  0.95  |  200/190  |  -  |  75  | 
 +| ? | PLA | Transparent |  1  |  200/195  |  -  |  75  |
  
  
Trace:

Page Tools