3D Delta Printer — Design Details
Sharing and asking for contribution, please feel free to connect me at mdeore@gmail.com
1 Problem Definition
A project to developing a 3D delta printer.
2 Design Considerations
3D printer has many hardware components to control and monitor. This document gives design details of the overall software system to control these devices.
It is also highly recommended to go through the SRS before reading this document. The high-level subsystem connectivity would look like this:
Subsequent section will have details of each sub-system and its function.
2.1 Android-based OBC
The reason for using Android as preferred On-chassis and Off-chassis ‘host’ operating system are following:
1. Android is made for portable system that are energy efficient.
2. The inherent feature of pub-sub architecture of sensor data to various applications. Example: phone has many sensors (GPS, gyro, light, etc) so theoretically, a phone can have unlimited applications installed and if all of them start fetching (polling) data from these sensors will kill the battery and hang the phone.
3. Android has ADK (Android Accessory Development kit), with this we can physically interface other external devices to Android hosted device. Example: USB to USART, PWM, ISA, etc.
4. Android NDK is a toolset that allow you to implement part of your application using native-code language like C and C++, that needs efficiency over Java.
5. Android is cross-compiled for ARM based processors and so are most of the Single Board Computers (SBC). We will use one of the most common SBC for OBC. Example UDOO has android 4.4 support.
6. We can also access under the hood Linux using ‘rooting’ but this Linux version is different than Debian, Ubuntu, and other flavors so we may not get some of the libraries. But good news is OpenGL is inherently supported.
7. For serial communication with microcontroller we can use android based ‘terminal emulator’.
2.1.1 Mode of operation
Using android based tablet or smart phone as OBC is important to reduce the cost and also leverage existing devices. If user wants, they can buy dedicated OBC or else they can use their android-based mobile or tablet as OBC. If user is using their existing android tablet/phone as OBC, they have to plugin the USB port on the android device to the USB socket on the chassis.
The first version of software will be OBC based and later will create strip down version for remote mobile devices. Hence the OBC software will have all the possible features required.
The OBC software will run under following mode:
1. Master: Being master this is fully populated version of software.
2. Server: It also acts as server for other remote device that will connect to printer via OBC.
The Desktop/Client will run under following mode:
1. Slave: This is the GUI interfacing part of software and not the OBC host software.
2. Client: This again is same as slave software but just different name.
2.1.2 Interfaces
There are various interfaces required to connect hardware and software. All of them are listed here:
2.1.2.1 Client/Slave to Server/Master
This interface will run over WiFi network or later we will have HTTP based connectivity to trigger the job from being outdoor.
2.1.2.2 OBC and Smoothie Board.
Smoothie board has following physical interfaces:
1. RJ45
2. USB
3. SPI serial Bus.
Looking at the criticality of the job and real-time requirements, RJ45 is not the choice because it has based on noisy and lossy network. USB is also not quite reliable connection medium hence our primary channel would be serial bus.
SPI becomes distortive and hence needs to be mounted right on the extruder or as close as possible to extruder.
2.1.2.3 Interfacing with mechanical hardware
This section gives idea about connecting electronics interfaces to various transducers on mechanical body.
2.1.2.3.1 MOSFET
Smoothie board has small (40V/5A) and big (40V/20A) MOSFETS support on board. These are enough to handle load like hotends, fans, temperature control, relay etc. More details are given in the data sheet.
2.1.2.3.2 Stepper Motors
Smoothie drives X, Y, Z (Cartesian movements axes) and E (3D printer extruder) motors. Each of the axes (X,Y,Z) can also be setup with min/max endstops.
We will use 1.8° step motor, that’s means 200 steps/revolution.
Smoothie supports 1/16 microstepping, but that high would needs highly refined power source and equally refined stepper motors. Hence 1/8 microstepping would be good enough for us.
1/8 microstepping = 0.125
i.e. 1.8° / 0.125 = 14.4 times slower than full-stepping.
Considering 1.8° stepper motor will have 200 steps/revolution.
therefore, 200 x 14.4 = 2880 total steps/revolution with microstepping.
3 Functional Structure
Following are the software components required on-board-chassis (OBC) to drive the printer.
3.1 OBC-Host Software
This is the heart of whole system where initialization, configuration, control and monitoring of all the sub-systems happen. There are quite a few open-source 3D host software mentioned in the appendix.
We would require following features as part of host software on OBS:
3.1.1 Communication and Notification
Communication with smoothie board is critical and serial ports are the preferred way to communicate (over USB) for message passing and monitoring. But we will use USB port as well and the purpose is defined as:
USART Port : This is primary communication channel will be used for all types of communication between smoothie board and host CPU. This involves: configuration, initialization, sending Gcode, progress monitoring, console, etc.
Baud rate @ 115200 should be fine.
USB Port : This will be used as secondary communication channel in case something goes wrong with Primary channel or for debugging.
3.1.2 Configuration and Initialization
Smoothie board comes with firmware software that has utility tools to control the controller. All the commands are listed here. Therefore it is also possible to issue various commands and access SD card on it. Smoothie board is highly configurable and the configuration can happen via two ways:
1) Static Configuration: Smoothie board always look for configuration file on SD card by name ‘config.txt. If this file is not there smoothie board won’t come up. This is a text file, where various configuration parameters are mentioned. These can be considered at static parameters because once configured, needs card reset for new parameters to get applied. We can also call them initialization level configuration parameters. The SD card is not allowed to be access by host and the smoothie board concurrently. Configuration details are given on here whereas configuration parameter list is here.
2) Dynamic Configuration: Many settings in smoothie board can be set immediately via M-Code commands. This acts as dynamic configuration for printer to while reading G-Code.
We will use both the ways of configuration, in the next phase we will try to explore if we can edit config.txt file for every single print job before it starts. [TBD]
3.1.3 Send G-Code commands
There two ways to send G-Code to smoothie board and they are:
1) SD card: User can copy the complete GCode file to SD card and issue ‘play’ command to start the printing job. ‘play’ is smoothie firmware utility command that takes G-Code instruction line by line.
There are other commands like: ‘progress’ ‘abort’ ‘suspend’ ‘resume’ to control the printing job. Actually, these commands convert into M-Code to check various parameters. This control is given because once the task starts we will have limited control over the job and hence with these commands user can pick-and-poke to find the details.
2) Host Streaming: Host can send streams of G-Code line by line to smoothie board, this way we have full control of job per G-Code instruction line by line. We can incorporate M-Code to get status time to time or wherever required. USART can be used for sending this stream. Host streaming is essential for initial system bring-up, because we can minutely verify the behaviors of the arms per instruction. We can also all this as debugging mode. Once the system is in good shape we can allow user to transfer complete file to the SD card and trigger the printing from there.
The details are given here with functionality at each step.
3.1.4 G-Code Generation : ‘gc-gen’
Conversion of STL and STEP format file to G-Code (Machine code), to drive stepper motors has to under this subsystem, we can call it gc-gen.
3.1.5 Progress
Progress can be monitored using ‘progress’ utility on smoothie board. For example ‘progress’ command display following output:
0 % complete, elapsed time: 31 s, est time: 326055 s
The above command may not give progress report if the G-Code file is in streaming mode, because the above calculation is based on the file size and during streaming file size is unknown.
The other way to get the progress and control granularity, inject M-Code to get the status in the G-Code file, this can be done while generating G-code from STEP file.
3.1.6 Printer Status:
Similarly, we need to inject M-Code to get printer status.
3.1.7 Calibration:
1. Configure firmware:
· Axes length: Dimensions of the machines
· Endstop positions: Endstop points.
· Steps/mm (X,Y,Z,E) :
a) XYZ axes — Calculate the pulleys ratio. (Google: Prusa calculator)
b) E axes — trial and error by measurement. Need to tell the firmware how many steps to turn the motor in order to consume one millimeter of feedback.
· Max speed :
· Max acceleration :
2. Configure the G-code generator: ideally configuration slicer software.
- Extrusion width : Filament extruded will have some height and width, this is based on the amount of material extruded. Each layer is pressed on the previous one so they are unaffected by the gravity (this is just for understanding sake).
3.1.8 Temperature:
3.1.9 Extruder:
3.1.10 Player:
3.1.11 Console:
3.1.11.1 Slicer — GCode Generator
We will support two types of file formats:
1. StereoLithography (STL)
2. Standard for The Exchange of Product model data (STEP) : ISO 10303 standard
After a survey of the available slicer software, it became apparent that the slicer software must take into account the criticalities of the 3D printer hardware, since each type of 3D printer i.e. Cartesian based or Delta configuration based has their own movement / printing issues. Hence it is better to have a customized slicer software tailored for our Delta configuration based hardware. The slicer module will have perform the following tasks:
· Parse the input file (i.e. Read the 3D model information from the STL or STEP file).
· Once the 3D model is read, it needs to be rendered on to the GUI. For rendering OpenGL library is the most suitable taking into account its availability on heterogeneous platforms. In this step the raw model as read from the input file will be rendered and the user will be able to visualize the object that the printer is about to print. At this step, user can abort the printing process in case the object is not according to his expectations.
· Once the user approves the 3D model read from the input file, software will go ahead and try to correct the surface normal errors that get introduced during the triangulation process. After correction the model will be rendered in the GUI.
· At this step the 3D model is ready to be printed. Now the slicer module will break the model into fine layers (thickness of these layers will depend on user input) in Z direction. After this process, these layers along with the 3D model in a transparent mode will be rendered for user’s visualization.
· Once the layers are generated, slicer module then needs to generate the g-code for each layer which corresponds to the commands for the 3D printer hardware (Hardware will use these commands and move the extruder unit which will in turn generate the layers of material). This sub module needs to take into account the capabilities and limitation of the 3D printer hardware and generate the g-code accordingly so as to achieve the best print from the hardware. Detailed description of the algorithms used is described in later sections.
· During this process of printing each layer the OBC software will verify the actual movements of the extruder unit using the PPM output and is equipped to take decisions whether to go ahead or abort the process in case it feels the hardware is not responding properly.
· GUI will showcase the printing process by rendering the current layer being printed along with a transparent 3D model of the object. User can also abort the printing at any time if he feels so.
3.1.11.2 PPM: Precision Position measurement
3.1.11.3 Graphical User Interface [TBD]
Common user interfaces for desktop (Web App or CLI) and later for mobile (Mobile App) if possible.
4 System Flow
<body>
5 Data Structures
<body>
6 Description of Algorithms
<body>
7 Interface Design
<body>
8 End User Interface
<body>
9 Software Restrictions and Considerations
<body>
10 Firmware Restrictions and Considerations
<body>
11 Hardware Restrictions and Considerations
<body>
12 External Restrictions and Configuration
<body>
13 Source Code
<body>
14 Development Unit Testing
Smoothie board debugging and crash analysis can be done, follow the link.
15 Initiative, Legal, & Regulatory
<Body>
16 References
1. Pronterface (http://smoothieware.org/pronterface)
2. octoprint (http://octoprint.org/)
3. repetier (http://www.repetier.com/)
4. 3D printer control (https://github.com/minad/3delta)
Most of the above software connects via serial port to Smoothie controller, converts STL (CAD Model) file to GCode using slicer utility, set/get temperature, switch off fan/motors/extruder/heatbed/power, monitor printer progress, etc.
· <Name of document in italics>, <document info in plain text>
· <Name of document in italics>, <document info in plain text>
17 Glossary
The following list describes acronyms and definitions for terms used throughout this document:
· Term 1 <in bold>: <definition in plain text>
· Term 2 <in bold>: <definition in plain text>
