Integrated System Build & Test with Customer Demo
Table of Contents
Team Vision for System Level Demo with CustomerShared Vision from the Week 8 Review:
- 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.
- At Imagine RIT we will be giving live demos of parts being printed. We will also be handing out the part shown above and will be printing as many of these as possible in preparation for Imagine.
Test Results Summary
- The PCB board has not yet arrived at the Senior Design office. While unfortunate, this has been noted in the previous reviews shared vision for week 11.
- Array Sensor
- From the initial data found from the test plans for the array sensors, 2 of the 4 sensors are reading slightly lower values than what has been recorded from the Electric Vehicle Team's Fluke Ti105 Thermal Imager. The source used to measure the sensors was the screw in the printer's heat bed which was the most reliable constant on the bed after the glass was removed.
- After this was discovered, the sensors were first
tested separately with I2C communication to confirm that
the I2C multiplexer used to read data from the 4 sensors
was not to blame. After confirming that it was an issues
with the sensors themselves, I also eliminated the
possibility that it might be a software issue as all four
sensors are using the same functions but getting
different values. An offset could be made for the two
sensors that are inaccurate but due to the complexity of
the functions used for computing the temperature measured
from the sensor, it would be unlikely to be of any help
unless very strictly tested over a great deal of time
which would account for altering constants in a number of
equations, testing the sensor’s constant and
transient state measurement values and then making a
suite of completely separate but similar functions for
the two sensors; all of which may do nothing to change
the results at all if the hardware inside of the sensors,
the RAM, the EEPROM, etc. cannot be individually tested
- Solution(1): Removing the two sensors with inaccurate readings and re-positioning the two accurate sensors so that they cover as much of the bed as possible. Based off of the amount of data readings from sensors measuring temperature at either side of the bed, there will be very little data loss and will not change the way in which we process the data for each part build.
- Solution(2):Buy two more array sensors; This is a very unpopular solution as there is a 50% that the newly purchased sensors will be accurate based on purchasing history and the lack of information pertaining to whether this was caused before or after the sensors were purchased.
- Datasheet can be found here for preference.
Data Output Analysis
All of the collected data is well below the setpoint of 80 degrees, and drops off dramatically with distance from the center. There is also a significantly higher temperature on the left side of the bed (C1, C5) than the right side of the bed (C11, C16).
The ambient temperature data shows evidence of heat creep inside the enclosure. A1 and A4 are significantly hotter than A2 and A3, meaning the ambient temperature is hotter on the left side of the enclosure than the right.
- From the plot above it can be seen that specimens 2 and 3 had a very similar stress strain relationship while specimen 1 had a much lower yield point and fracture.
- Specimen 1 was the most geometrically accurate test part and did not have any warping while 2 and 3 had significant warping. Although it may seem that a more accurate part would produce better results, this shows quite the opposite.
- Specimen 1 was printed with a extruder temperature of 200C while the others were at 220C. We can't say with absolute certainty that this caused the discrepancy however we are confident that the lower extruder temperature caused worse layer adhesion which allowed specimen 1 to break easier.
- Specimens 2 and 3 were printed with the same settings and exhibited a similar stress strain relationship. More tests would be needed to say with any certainty that the printer produces specimens with the same structural integrity within error when they are printed with the same settings.
- The full document is shown here
Bill of Material
Risk and Problem Tracking
Functional Demo Materials
- Still image edge detection has been implemented in a basic Python script. When the script is executed, it will capture an image and process with the Canny algorithm and output a black and white image with edges detected. The following snippet displays the current script progress.
#import the necessary packages import numpy as np from picamera.array import PiRGBArray from picamera import PiCamera import time import cv2 from matplotlib import pyplot as plt #initialize camera and grab a reference to the raw camera capture camera = PiCamera() rawCapture = PiRGBArray(camera) #allow the camera to warmup time.sleep(0.1) #grab an image from the camera camera.capture(rawCapture, format="bgr") image = rawCapture.array #convert to hsv hsv_image = cv2.cvtColor(image, cv2.COLOR_BGR2HSV) #define green color range lower_green = np.array([25,0,25], dtype="uint8") upper_green = np.array([225,255,225], dtype="uint8") #mask the image mask = cv2.inRange(image, lower_green, upper_green) res = cv2.bitwise_and(image,image,mask= mask) #display the image on screen and wait for a keypress cv2.imshow("Image", image) cv2.imshow("hsv", hsv_image) #cv2.imshow("mask", mask) cv2.imshow("res",res) edges = cv2.Canny(image, 90, 120) cv2.imshow("Edges", edges) edges_filtered = cv2.Canny(res,80,120) cv2.imshow("Edges Filtered", edges_filtered) #save images cv2.imwrite("NoBackground/Image.jpg", image) cv2.imwrite("NoBackground/hsv.jpg", hsv_image) cv2.imwrite("NoBackground/Edges.jpg", edges) cv2.imwrite("NoBackground/res.jpg", res) cv2.imwrite("NoBackground/Edges_Filtered.jpg", edges_filtered) #cv2.imshow("Grayscale", gray_image) cv2.waitKey(0)
Images Without Backdrop
- The script was tested on a variety of parts but demonstrates best results when observing simpler shapes.The following images represent the set of test images with no backdrop behind the part.
Note: The Pi camera has a ~3.6mm focal length, but slight adjustments have been made to accommodate the proximity of the artifact.
- This image can also be converted into HSV format and/or it can be filtered by RGB levels.
- Edge detection can then be applied to the original and filtered images.
Images with Backdrop
- The following images represent increased image quality while using a white piece of paper as a backdrop. Note the bed reflections.
- It is important to note how much cleaner the edges are in the images that include a solid backdrop. This method will help ensure accuracy when comparing to a reference.
- Continued research will determine if filtering of the HSV image will allow for increased edge detection accuracy in the no-backdrop images.
- This is the meat of the program I made to write to the LED display. It is all put into the sensor program and currently displays a 16x16 square with colors corresponding to the sensors. It also is set up to display "T =" followed by a number that could be the ambient temperature. However, we feel that the 16x16 display is bit small and not very smooth so I will be changing it to the full 32x32. Since we only have 256 data points and not 1024 I will be using the data points every other LED and then using the average in between.
- Sampling time has gone down from 20 seconds to a little under 2 seconds; the sampling time can be improved even further, if requested by the customer, by abandoning printing values to the computer's serial monitor.
- Functionality was added to filter out the initial 'garbage' values read from the array sensors. This was done by prompting the user to start recording after the program cycled through reading each sensor once.
- Sensor Network can now save up to 100 CSV files.
- 'Garbage' values from the header string have been eliminated; CSV file now prints only header string for labels and value sting for array sensors and thermocouples.
- Sensor network is fully integrated with LED matrix subsystem.
- Sensor network is fully integrated with Raspberry Pi. However, the code for the sensor network is not cooperating with the Raspberry Pi OS.
StatusThe firmware development is coming very close to its completion; however problems are still being worked out. The development of the SD expansion to allow another file operation is almost complete after iterating on the solution several times. Additionally, several previously written code implementations were improved and cleaned up for additional readable and safety concerns. In the next week or two after the code is properly debugged to ensure proper performance, it will be implemented into the printer.
IssuesThe issue of performing two different SD file actions at once has been mostly addressed and there are only a few more issues that remain. At first the attempt to expand the firmware was an approach that would have little resource impact on the system, but proved to be more complicated than what it would be worth. So instead, the approach to add an additional SD file module was chosen that would always keep track of the given log file for a print job. This SD file runs completely separately from the primary one which should allow dual SD file capabilities. There are a few remaining bugs and safety concerns that need addressed in order to complete the SD implementation.
The Watchdog reset issue has been addressed and is continuously being considered in the process moving forward. After further research into the issue, the cause was linked to trying to perform file operations during critical time periods. In order to work around the issue, the SD file was accessing was changed to be as a separate call group with other calls of the like in a non-critical time period. This change required several different method additions unique to log file access.
Plan Forward and OutlookBefore the customer hand-off, the firmware should be in a state that allows capturing of the internal CSV data at minimum. Having additional updates to the firmware PID controller do not look possible with the given time constraints. The next two weeks will be spent ironing out issues to make sure there are no errors in the new firmware modifications that could cause danger to the printer or to normal printer operations as well as debugging current errors. In the week before the hand-off, heavy documentation will be done on the firmware modifications that have been made, including in code annotations. Following the handoff, modifications will be made to the additional printer being bought so it will also have the logging mechanisms being developed for our current printer.
Plans for next phase
Shared Vision for Next Review
- The LED matrix will be implemented with the sensor network. Jon will be optimizing the LED matrix and making it look better as well as fixing the color. This will be ready to demonstrate at Imagine RIT.
- Further analysis of the printed NIST specimens will be done, and analysis presented at the Week 15 Review.
- The technical paper will be completed and presented at the Week 15 Review.
- Firmware will be updated to our specifications and in use at Imagine RIT.
- The sensor network will be stress tested by the Week 15 Review.
- The thermal camera system will be implemented and will record thermal history. This will be demonstrated at Imagine RIT.
- Giveaway parts for Imagine RIT will be printed ahead of time to meet anticipated demand, and further printing of the part to demonstrate the printer’s abilities will happen at Imagine RIT.
- Further control charts will be made after corrections to the sensor array. A sample control chart will be demonstrated at Imagine RIT.
- Sensor Network code will be operational on the Raspberry Pi by Imagine RIT.
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.