Subsystem Build & Test
Table of Contents
Team Vision for Subsystem Level Build & Test PhaseAt this review, we will present our progress on our next set of data analysis, including plans for further testing and new test results confirming the improvements made by the enclosure.
The updated end-state document can be found here.
This demonstration will also include the following systems of our design project:
- Test Bed/Atmospheric Sensor Network
- Housing and placement of: Sensors, Thermocouples, Thermal Camera, Observation Camera
Auxiliary points of progression, with appropriate time tables, that will be discussed:
- Data Logging for the sensor network
- RGB LED matrix subsystem
- First round of impact testing
This subsystem demonstration will feature the subsystems operating separately from one another at minimum. This is meant to confirm their operation and functionality as well as open a guided dialogue on their predicted progress at the week 8 review.
The test bed/atmospheric sensor network is not yet integrated into the printer, but the mounting bracket for the sensors themselves will be demoed and replacing the components current housing, a breadboard will be discussed. The sensor network is able to write to an SD card but parts are waiting to be delivered to make the CSV file easy to read and time-stamped.
As with any design project, there will be some unknown problems that will appear. In the case of the 3 weeks between our team’s last review and week 5, 2 separate problems were uncovered. These problems came in the form of a server hack as well as calibration issues with the printer. Thankfully, both issues were remedied and noted in the updated problem tracking document.
Test Results Summary
- Results were inconclusive. The impact tester measures impact energy in increments of one joule; however the energy to break the impact specimen was less than this.
- The specimens were not printed solid but were printed with a 20% mesh infill. Increasing this mesh or even making them solid will increase the impact energy.
- There are a few potential solutions moving forward to get better results.
- Results were inconclusive due to the mesh on the inside of the specimen.
- The tensile tester is equipped with a 2500kg force load cell (5500 lbs force) that has an error of ±0.5% of the total range or 0.25% of the indicated load using whichever is higher.
- The stronger of the two specimens broke at 1.66ksi. Accounting for the cross sectional area it only took 237 lbs force to break the specimen while the error of the instrument is ±27.5 lbs force.
- No real conclusions can be made from changes in print parameters when the error in the instrument is almost ±12% of the total force it took to break the specimen.
- There are a few potential solutions moving forward to get better results.
Bill Of Material
Risk and Problem Tracking
- Update your Risk Management
- The full Problem Tracking document can be found here.
SecurityThe addition of Octoprint allowed us to access the printer remotely from the internet, increasing the printer’s up-time and accessibility. While this was a boon for the team, this also opened us up to potential security concerns that were not realized, causing the printer to be accessed late one night remotely by an unauthorized individual. As a result, we were locked out of our Octoprint interface, the individual uploaded a custom print job, and he even messaged our message group! Fortunately, the printer was off at the time so nothing actually printed.
The team quickly realized that something was happening thanks to our message group being alerted about the unauthorized print. After which the team quickly addressed the issue by first going to the printer and making sure it wasn’t actually printing anything. Afterwards the Octoprint system was quickly disconnected from the printer to avoid further harm until the issues could be proper addressed in the morning.
The team met in the morning to discuss what happened and ways to minimalism the issues moving forward. After investigating potential causes for the security concern, we discovered we did not change the default login information for our Raspberry Pi, which was where our Octoprint server was located, and thus, where our Printer could be accessed from. We concluded that the Raspberry Pi was hacked and through that our Octoprint was also accessed. The individual then used our Octoprint system to send a message to our message group, which thankfully meant that they did not have access to our message group, protecting any important information we had posted there. We responded to these problems by first changing the default login information on our Raspberry Pi to something significantly more secure. Then we looked at the specific services that our Raspberry Pi required and removed the ones we did not need. Other security measures were taken into consideration; however we decided to not implement them as they would either injury our workflow or would be overkill for what our project needed to achieve.
We do have plans that will further improve our security concerns. Due to recent mount installations and calibration concerns, we do plan to move away from Octoprint or at least removing it from the internet. This decision was made due to the recent calibration issues we’ve had with print failures that results from using the extruder to remove the last print. Additionally, this way of removing the part isn’t feasible with the new thermal camera mount. With Octoprint removed from the internet, so is our printer, removing the security concern entirely.
Subsystem Development and Demos
- The sensors for the heat bed are now mounted to the printer and preliminary recordings are being taken. As noted in the Upkeep and Updates chart, software updates are still being added to the network for general organization and troubleshooting purposes.
All test plans can be found here.
- The SD card breakout board has been added to the sensor network and can write values from each sensor to a text file which separates each value with a comma. The caveat to this is that the code is currently writing data to the file in a form that visually represents the heat bed and clearly labels the spreadsheet columns that they will fit into, the time tables for which are noted in the Upkeep and Updates. Once the file is formatted, it will be delivered to the customer for further parsing.
- Thermocouples are mounted and preliminary testing is being performed in tandem to the heat bed sensors.
Issue: Initial results seem to be
affected by the air generated from the extruders'
movement during the print.
- Solution: Re-mount the thermocouples farther away from the extruders and restart the test plans stated in our week 2 review.
- Currently, the HD Raspberry Pi camera and Flir thermal camera have been mounted inside the printer and work to demonstrate a live-feed of the current print.
- The Pi camera is mounted in the front corner of the enclosure and offers a decent view with regards to generic print monitoring via Octoprint. The thermal camera is currently mounted at the front end of the bed and allows for a full image of the artifact and extruder.
Issue 1: The HD camera is at an
awkward angle and offers a blurry view of the part.
This will not allow OpenCV or any other image
processing software a clear image to process.
- Solution 1: Mount the HD camera next to the thermal camera at the end of the print bed. This will allow for a head-on view of the part (depending on orientation), and a higher probability for edge detection.
Issue 2: Currently the thermal camera
saturates on the extruder when observing the print. The
scene dynamic range of the Flir Lepton will not allow
for the artifact and the extruder to be represented in
the same image.
- Solution 2a: Continue working on development of current thermal camera and implement a way to limit the maximum temperature of the scene. This solution may be out of scope for this project.
- Solution 2b: Use a small portion of remaining budget to purchase "smart" Flir Lepton that has USB capabilities and a pre-existing software program. This would allow the most up-time. The major risk invovled in this solution would be adapting the GetThermal software for the Raspberry Pi.
- The parts were ordered and the test program was started in this phase.
- The Subsystem should not take very long to test and put together and should be done and demo ready by the week 8 review.
- To save on processing power we will use 3-bit numbers to get the Red, Green, and Blue combination for a total of 512 colors. The alternative is 4-bit numbers which is 4096 colors which isn't necessary. The board will be tested on an Ardunio Uno to make sure it works and get the program functioning. It will then be transferred to the Mega that is connected to the sensor array. The Mega will take the array, convert the temperatures to 3 values corresponding to the Red, Green, and Blue 3-bit number.
- A 5V 4A power supply will be used to power the display because with all the LEDs at full white the board draws 4A and we don't plan on using it to that full value.
FirmwareCurrently the progress for Marlin Firmware improvements is slightly behind what is expected. At this point in time, nothing is actually implemented in the firmware but several portions have been written. Methods for internal data collection from the on-board sensors have been identified and are ready for use. Additionally, a method for CSV log writing has been developed and ready for implementation in the main firmware. Code has also been developed that will allow a file to be written to the internal SD card.
While all these parts have been developed separately, they have yet to be tested as a single unit. Additional testing is also necessary to approve that each method works entirely as expected for ‘evil’ input. Once tested, this system also needs to be properly implemented into the firmware, followed by adding support for the external sensors we plan to add to the printer.
The original plan for this review was to have these functions implemented into the firmware (except for external sensor support), but a few things have kept this from being achieved. The biggest issue has been the high complexity of the Marlin Firmware and the poor documentation (or lack of in some cases) of the code in general. These issues have been the main reasons why there has been a lack of implementation into the Marlin Firmware. In order to offset some of the time lost, several things were written as stand-alone methods (as mentioned above) that will be ready for implementation once the proper location in the firmware is identified. Additionally, the location of implementation must be selected very careful to minimalize the risk of introducing potentially critical errors into the printer’s system.
The current plan is to have the CSV log writing and internal sensor logging fully tested and implemented into the Marlin Firmware by the next review (week 8). If this can be done within a quick and timely manner, the external sensors will also be added into this and presented at the next review, however this is a stretch goal and is more likely to happen at the following review (week 11).
- All of the mounting fixtures for the sensors and cameras were 3D printed during this phase.
- All of the point sensor mounts have not been printed yet because we are unsure if they will be needed because the array sensors give a good view of the entire print bed.
As per the results of the first DOE test, and conversations with the customer, a second round of DOE testing was begun using six of the previous nine treatment levels (all three extruder temp levels and the two highest bed temp levels). In addition, this test is being performed with the use of the enclosure, mitigating variance in ambient temperature. In order to obtain more information on error variance, the number of repetitions was increased from three to five, for a total of thirty prints in this experiment.
Due to the two critical problems that occurred during Phase 2, there were significant losses of printer up-time. As a result of the time lost from the hack and calibration problems, the second round of DOE testing was not completed. At the time of this review, only 22 of the 30 test prints have been completed. Until the completion of the test, we will be unable to make assertions on error variance for each of the six treatment levels. Initial results, while not complete, appear to verify our hypotheses on the enclosure and high bed temperature. All successful prints have resulted in perfect or nearly perfect bed adhesion, and overall quality and consistency seem to have improved.
Plans for next phase
Week 8 Shared VisionThe shared vision for the Week 8 review will include updates bulding upon the topics discussed today.
- The LED matrix have been ordered and hardware/software development will have begun. Progress will be shown at the Week 8 review.
- The HD camera will be mounted next to the thermal camera and a progress report will be presented at the Week 8 review. This will resolve Issue 1.
- A solution for Issue 2 will be decided upon after this review. Parts will (potentially) be ordered and thermal imaging progress will be made by the Week 8 review.
- The second DOE test will be completed, and results will be analyzed in Week 6.
- Tensile testing will move forward according to the plan we discuss during this design review. We will perform a DOE test and report our progress during our Week 8 Review.
- Impact testing will move forward according to the plan we discuss during this design review. Testing will determine if a DOE test would be conclusive and progress will be reported during Week 8 Review.
- 3D scanning was not completed this phase due to the various problems we encountered during this phase but it will be performed and results will be presented at the Week 8 Review.
- A plan for mounting the additional Arduino and Raspberry Pi will be developed and progress will be reported at Week 8 Review.
- Working on PCB schematic will move forward for sensor network and the design will be presented at the Week 8 Review.
- Optimizing CSV file for delivery to customer for further parsing by Week 6.
- The printer's firmware will be modified to implement the code developed for CSV logging of internal data by the Week 8 review.
- The printer will collect valuable data from the internal sensors and will be capable of writing this data to a CSV log by the Week 8 review.
- The printer will collect valuable data from the external sensors and will be capable of writing this data to a CSV log by the 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.