Rustic Retreat
Hot Projects
Live broadcasts and documentation from a remote tech outpost in rustic Portugal. Sharing off-grid life, the necessary research & development and the pursuit of life, without centralized infrastructure.
Apollo-NG is a mobile, self-sustainable, independent and highly-experimental Hackbase, focused on research, development and usage of next-generation open technology while visiting places without a resident, local Hackerspace and offering other Hackers the opportunity to work together on exciting projects and to share fun, food, tools & resources, knowledge, experience and inspiration.
Tonight's work will be another live-stream, hacking on F3l1ks. After the 3d-printer-extruder-peek-insulator-meltdown, it seemed prudent to verify that the temperatures, shown and logged by octoprint are actually the temperatures of the bed or the hot-end.
In theory it works like this: The Bed and the hot-ends have so called thermistors built-in, which are, in simple terms, just a certain kind of resistors that change their resistance (in ohm) proportional to their temperature. A specific temperature will result in a specific and predictable resistance. When we know the linearity and parameters/curve of the thermistor we can use the ADC of any uC to measure the Voltage which will change proportionally with the resistance. With a little math we can convert the digital value back to °C. So far my understanding of the principle and could/should also be reviewed in the Firmware code (reminder).
Theory is all good, but in theory the PEEK element also never should have melted. But it did. Now it's time to gather and verify data to make sure it wasn't some error in the firmware configuration, wiring or setup that led to instrumentation errors, where the temperature readouts actually were much lower than the actual temperatures to reach way above 245°C to melt the PEEK. So let's wire up an external thermometer with a K-Type temperature sensor and verify the data of the bed and the hot-end thermistors through the whole chain:
Thermistor → Cable → Connector → ADC → Firmware → USB → OctoPrint → VFCC
Since the cam and metrics shipping is already in place you can follow it live:
When you leave the commercial/proprietary software ecosphere and jump into open-source operating systems, you will have to learn how to handle daemons. And once you've created a couple of those daemons yourself, taught them what to do and let them work in production, you gain a lot of experience and confidence in dealing with all kinds of daemons.
Yesterday, a couple of friends from the awesome http://co-munity.net/ecobytes project seemed to be in some sort of possible DDoS trouble and asked for my advice and experience to mitigate the issue. Now, to me, it is a very amazing experience to simply get root access to a lot of machines lately, operated by people which I have never physically met but in this case we are connected by elf-pavlik. And in today's world, voluntarily giving root access to someone else, is the ultimate token of trust or/and friendship. So I'd like to thank you guys for that vote of confidence.
Since it was supposed to be a DDoS, I've had my input filters clamped too early and saw that something was going on and a lot of traffic was moving but it somehow seemed wrong compared to other DDoS investigations I had to do in the past. After some failed attempts to block/null-route a couple of offensive networks, our analysis focus shifted to traffic distribution where we saw that one of the VMs seemed to be the top talker. And it also became clear that the traffic wasn't coming in, it was going out. I didn't take care to look at flow direction at all because I already assumed it was incoming traffic (DDoS).
Here's where Dashboards like this come in handy. You have all relevant metrics at a glance and can compare the current to some “normal” state in the past. Matching graphs and colors visually takes much less time than working on the console to aggregate everything manually for a quick situation overview.
It then quickly became apparent, that one of the VMs was the top talker so we moved onto that box and what started out as DDoS mitigation turned into digital exorcism. You know, when there are daemons that are possessed and controlled by some evil spirit to create some form havoc, mostly motivated purely by the ultimate overlord of all evil: Financial Profit. And what do you do when dealing with evil daemons? You go Exorcist on them.
chrono : Uhhhh, H0u5t0n, I have some good and some bad news H0u5t0n : Bad news chrono : I think we have a problem with F3l1ks H0u5t0n : Could you be a bit more specific? chrono : Well, seems as if the beige plastic element of extruder 0 melted H0u5t0n : You mean the beige PEEK insulator between the hot- and cold-end? chrono : Affirmative H0u5t0n : How did that happen? chrono : I was prepping him for a new job, manually set the target temp of ext0 to 220°C for a quick cleaning extrusion of about 30mm of filament when I noticed a sizzling sound which turned out to be something dropping from the insulator onto the hot-end. A second or so later, the whole hot-end started to drop out of the PEEK insulator, at which point I set F3l1ks to standby to stop him H0u5t0n : Did you check the temperature at that point? chrono : Yeah, unfortunately, I didn't take a screenshot due to the hectic of the moment and octoprint doesn't offer a history function to get some hard data. All I can offer is a glimpse I had after I stopped him and saw some obvious overshoot ranging somewhere between 240-250°C. Did you guys ever verify the thermistor readouts with an external reference thermometer? H0u5t0n : Uhhhm, no... I suppose we did not chrono : Ok, I'll have to do that then. Could you put a spare PEEK into the next supply launch? I've already unmounted and secured ext0 so we should be able to continue printing in the meantime with ext1 - after a couple of more safety tests chrono : Which brings us to the good news: H0u5t0n : Let me guess, you figured out a way to collect and ship F3l1ks's metrics into the VFCC, to significantly reduce the risk of having to work without more reliable data again? chrono : Errr, yeah... exactly
Since the VFCC already offers all the features needed to store, retrieve and visualize all metrics of the 3D Print Robot, it was only a matter of an hour to install and configure collectd on the Odroid C1 to gather all system and printing related metrics, ship them into InfluxDB and mash up this fancy Live - F3l1ks - 3D Print Robot Stats Dashboard