Integrated System Build & Test
Table of Contents
Team Vision for Integrated System Build & Test Phase
- Shared Vision from Last Review:
Test Results Summary
The second round of DOE experimentation was completed with a larger sample size and one fewer level for bed adhesion. The summarized results are below:
The results strongly indicate the use of the low settings for bed and extruder temperatures, which we believe to be a result of the enclosure. A few print failures increased the error in some categories, but the 20070 print (the desired print, according to our data) had the lowest overall variance in addition to higher quality scores.
Linear models did not prove that the two factors were statistically linked to quality change in most cases, due to the low number of replications, but did detect the impact in the most significant cases.
Inputs & Source
- The sensors have a seeing dynamic range of 60° by 15° creating a 16x4 matrix shown above.
- A proximity sensor will be used to determine the height from the sensor to the print bed so the location of the 16x4 matrix can be determined. The lower left hand corner of the print bed will be considered the origin as shown below. The centers of the sensors relative to the origin of the print bed are also shown below.
- The matlab script shown below outputs a y matrix for all four of the sensors because they are all 150mm from the lower edge of the print bed and it outputs four different x matrices for each of the sensors. The only input into the script is the height of the print bed which will be read from the proximity sensor.
- Test Plan
- So that the data recorded quantitatively and qualitatively summarizes capabilities, performance, and robustness of the system, test plans for the sensor network have been re-evaluated and altered. The entirety of our team's test plans can be found here.
- Subsystem fabrication
- Functionality has been added to the sensor
network programming. As seen in the upkeep document,
further work on the network's programming will
involve optimziation to see if overall performance
can be improved.
- The file saved to the SD card is now a .csv instead of a .txt
- The 16x16 array is now saved to the .csv file as a 16x16 array instead of 2 8x16 arrays.
- Files now contain dates/times in the SD card directory
- A start/stop function has been added to allow for the control of the recording process.
- Added code to save each recording as a different file
- The Printed circuit board design was finished and ordered.
- Functionality has been added to the sensor network programming. As seen in the upkeep document, further work on the network's programming will involve optimziation to see if overall performance can be improved.
- This is the meat of the given program on how to make the color wheel. From this we can we can see they use two loops to color the wheel in the size of the circle in the x and y direction.
- This program includes both the shapes and text examples which is made easy to read. The library given by Adafruit is very straight forward and should be hard to decipher.
- This is a clear example of how to use text on the board using the given library. We can use this to display the ambient temperatures.
Outputs & Destination
- System integration
- The sensor network has not yet been integrated
with the Raspberry Pi/Camera subsystem.
- Solution: Integrating the two subsystems together would involve installing the Arduino IDE onto Raspbian, the Linux OS recognizes the program so it can be installed using a simple 'sudo apt-get' terminal command. This is reflected in the Upkeep document.
- The sensor network has not yet been integrated
with the RGB LED matrix.
- Solution: The RGB Matrix needs 3 GND connections, 6 digital I/O pins, 3 analog input pins, a LAT (latch) signal pin, a clock connection, and an output enable connection which are all free and available on the Arduino Mega that is being used for the sensor network. From there, code that we have designed needs to be implemented to read the array of values already printed by the network. This is reflected in the Upkeep document.
- The sensor network has not yet been integrated with the Raspberry Pi/Camera subsystem.
- Behind schedule
- Unfortunately, due to the power outage before break and getting very ill just as I got back from break I fell behind schedule. I plan to be making this time in the next week or so hopefully. With the library being easy to understand I should be able to deconstruct how it works easily and get it implemented with the Sensor Network.
- Currently have only minor updates due to difficulties
installing the GetThermal software GUI.
- Dependency is on a package called QT 5.7, which is not native to the Raspberry Pi. Only method to install requires a 2-day long compilation - because the Pi has limited resources.
- Also, native Octopi image lacks certain resources that would make the install easier. Will be switching Pi from Octopi image to standard Raspbian image for easier integration.
- Discussing with another MSD team who has been using a thermal camera on how to install necessary SW packages and use the device.
Impact TestingAn impact specimen was printed solid and tested and the impact energy was close to 2N. This is much too small to be able to generate any valid conclusions due to changing print properties when the error is 1N. Therefore, going forward we are going to concentrate all of our energy on the Tensile DOE test as well as geometric accuracy testing.
Tensile TestingOnly three tensile specimens were printed since the previous review due to numerous print failures. The specimens printed are all highly warped and more tuning needs to be done to the print properties and/or the printer to create more acceptable specimens.
Geometric Accuracy TestingInitially it was thought that the 3D scanner that we have access to had 100 micron accuracy it has become evident that it only has 1mm accuracy. This will not be accurate enough to show any inconsistencies between the benchy specimens. Going forward we are going to use what has been learned from the qualitative DOE testing to start printing the NIST parts. These parts will be measured using calipers and a CMM pending access to it. For the remainder of this project we will only be printing NIST parts and Tensile specimens to perform DOE testing. The technical drawings for the NIST specimen are shown below.
StatusCurrently the firmware development is behind schedule. The plan for this review was to have the internal sensor data accessible and printed to a csv file on the SD card. At this point, the data is accessible within the system and is formatted to write to a csv file, however writing to system’s SD card is proving to be challenging. Additionally, the data collection was setup to allow for expansion and additional data to be added before writing out to the csv file. The plan for the next phase is to be able to write the collected data to the SD card and integrate the internal and external data in the system.
IssuesThe biggest issue currently is the inability for the 3D printer to perform more than two file operations at one given moment. Currently while the printer is printing anything, it must be performing file operations to read the print data as it comes in, instead of storing all of it within the program. While this is great for performance and stability, it does create the inability to log csv data as we acquire it from the internal sensors. Since the firmware is not written in an object-oriented manner with little documentation available, this problem is more difficult than just adding another ‘sdfile’ object. Additional methods and modifications are being written into how the firmware handles sd cards in order to add this new functionality into the system.
Another issue that has been showing up is the ‘Watchdog’ for the firmware will occasionally cause the firmware to enter a kill state. Normally, this is the intended function of the Watchdog as its job is to guard against system hang-ups and cleanly terminate printer functionality if the system does hang-up. This is achieved by having the watchdog expect a ‘heartbeat’ message within a timeout period of the last heartbeat. Currently, the modified firmware will occasionally trigger the watchdog by not sending a heartbeat within the timeout window. The cause of this is currently being investigated using timers to time critical execution components of the firmware.
Other issues have popped up, but they have been minor and easily solvable in nature. Initially, the lack of a ‘main’ entry point into the code was an issue, but this was resolved by reading both the documentation for the Arduino and the Marlin firmware and discovering that they use a ‘setup & loop’ paradigm where the setup is the entry point, and loop is constantly looped. Other issues have been of a syntactical nature, such as having issues with how the marlin system works with character pointers for string construction, how the system accesses its internal data, how the system manages SD cards, how the system manages its memory and data members, and function calls.
Bill of Materials
Risk and Problem Tracking
Plans for next phase
Week 11 Shared VisionThe shared vision for the Week 8 review will include updates bulding upon the topics discussed today.
- The LED Matrix will be integrated with the sensor network and display live bed temperature data. Progress will be shown at the Week 11 review.
- Tensile Testing data will be complete and analyzed. Results will be shown at the Week 11 review.
- NIST parts will be printed and inspected. Process and analysis will be shown at the Week 11 review.
- Thermal camera will be installed, and progress will be made on recording thermal history. And update will be given at the Week 11 review.
- OpenCV will be implemented on the Pi and edge detection will be operational and presented at the Week 11 review.
- A .csv file will be collected from print data, and a control chart will be generated to interpret the results. This control chart will be included in the Week 11 review.
- The external sensor system will be integrated with the printer firmware. The results of this will be shown at the Week 11 review.
- The Arduino and Raspberry Pi will be mounted to the printer and individually grounded by Week 11 review. Depending on the shipping time of the PCB it may or may not be mounted by the Week 11 review but a plan for mounting it will be developed.
- Arduino code optimization progress will shown at Week 11 review.
- Distance sensor as well as code for bed measurement calibration will be shown at Week 11 review.
- Results from Array sensors and Thermocouples will be shown at Week 11 review.
Three Week Plans
- Mike's three week plan.
- Ryan's three week plan.
- Maseo's three week plan.
- Justin's three week plan.
- Jacob's three week plan.
- Jon's three week plan.