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.
Image creation/manipulation is an essential part of UI design and, with Photoshop gone, GIMP and Inkscape came to the rescue. Almost all graphics used in the Apollo-NG realm are created with Inkscape. With many people already using Inkscape and it being a vector oriented tool creating SVGs, it was just a matter of time until the SVG standard and its implementations matured and spread. Some features, such as SMIL animation and SVG Fonts are not as widely supported. There are many SVG authoring tools, and export to SVG is supported by all major vector graphics authoring tools.
SVG 2 is currently under development, and will add new ease-of-use features to SVG, as well as more closely integrating with HTML, CSS, and the DOM, and deprecating features not supported by all browsers. The SVG Working Group is currently working in parallel on a set of modules for extending prior specifications and adding functionality to CSS, and the new SVG 2 specification will combine those modules with the rest of the SVG framework to work across the full range of devices and platforms.
Let's see about bypassing even Inkscape and learn with a simple real-world example about programming UI elements directly, as opposed to manually drawing in Inkscape and thereby giving our code the means to control the design itself, making another step towards better SDUI.
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: