User Tools

Site Tools


Navigation Menu

Flight-Control

<
Previous mounth
12/21/2024
>
Next mounth
SMTWFTS
51
15
15
16
16
17
17
18
18
19
19
20
20
21
21
5222232425262728
0129303101020304
0205060708091011
0312131415161718









Hot Projects

SEEDStack

SEEDStack - Open 3D printable seed/sprouting systemDIY Food Hacking

UCSSPM

UCSSPM - Unified Clear-Sky Solar Prediction ModelOpen Solar Power

picoReflow

picoReflow - DIY PID Reflow Oven Controller based on RaspberryPiDIY Reflow Soldering

PiGI

PiGI - DIY Geiger Counter based on RaspberryPiRasPi Geiger Counter

DIY ARA-2000

Active Wideband Receiver Antenna for SDR - ARA-2000Wideband Antenna

DSpace

DSPace - Map everythingMap everything!

Mission-Tags

Mission-Log

3D Printer extruder PEEK insulator meltdown

felix-extruderv4-peek-meltdown

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

Live - F3l1ks - 3D Print Robot Stats Dashboard

→ Read more...

2015/03/25 12:02 · chrono · 15 Comments

Personal Log: FUCK

Freedom of speech is nothing if there is no freedom to use language in every way we individually see fit. After all, in the end, language is nothing but a crude tool to transfer knowledge, a meaning or just the state of our rational/emotional mindset to someone else. The more cryptic or inhibited the sender is, when translating thought patterns or trying to communicate an emotional state, the more likely the chance of communication failure becomes: The receiver must rely heavily on interpretation and interpolation. This problem seems to be even bigger when people from different cultures communicate, since their social and language training is different, making interpretation even harder due to a lack of common training ground (also beautifully depicted in https://en.wikipedia.org/wiki/Darmok).

But after watching http://www.imdb.com/title/tt0486585/, I really kept wondering, if the life of those people really is so fucked up, that they're rather wasting their lifetime trying to pretend to be “decent” and “on the moral high-ground” while at the same time they just go home to eagerly receive the next ass-smacking from their wives to get one up. Fucking hypocrites. Now get the fuck out or not, I don't actually give a fuck because we have way more pressing problems to solve than allocating time and resources on debating/censoring the use of the word FUCK or any other for that matter.

And if you're often feeling offended by something someone says, ask yourself or even the sender (verify) if it was actually intended as an offence, before trying to censor words and oppress people, to distract and hide the deeper issues you're having but obviously seem unwilling to resolve yourself. Unwanted reflection of subconscious things, building up from too much exposure to double-think standards, can often be triggered by words associated with that. Sex probably is still one of the biggest contexts/meanings associated to the word family of fuck. As fucks can be used or (not) given in a plethora of meanings for amplification, a huge number of readily established and available idioms or even as simple expression deriving its meaning entirely from context or intonation it is the perfect candidate for a “War on Fucks”. For the children, of course.

Go read Bukowskis poetry if you want to see how even the most “offending” and brutish words showing things how they actually are without any fake metaphoric surface to shine things up. And still, this raw and honest way of working with words turned out very beautiful poetry worthwhile reading instead of some shit you think you're supposed to read in order to be accepted intellectually. Fuck that.

2015/03/25 08:17 · chrono · 9 Comments

Personal Log: Instrumental Flight FTW

Hello H0u5t0n, thanks for giving me a heads-up about the solar eclipse today… NOT.

Watching the Eclipse of 2015-03-20 in Munich through Metric Instrumentation (24h View)

It must have been around 0935, when I couldn't escape the feeling of some environmental anomaly.

The light was just “not right”. I couldn't see the sun, since there was no quick access to southbound vantage points but a glimpse out of the northbound window revealed almost clear, blue sky and the apparent shadow/contrast and sharpness indicated no clouds in between. Yet, somehow, it was as if I was wearing dark sunglasses or as if we were suddenly much farther away from the sun.

→ Read more...

2015/03/20 23:12 · chrono · 14 Comments

3D Printer Hacking - Carbon as a printing bed surface

This is going to be very experimental and sorry for the short notice :) Since we now have a relatively efficient video stream relaying capability thanks to mjpeg-relay and a highly anticipated set of carbon sheets arrived today, it is time to remove the Kapton-Tape from the the 3D printer and replace it with a 0.5 mm carbon sheet. So, if you're interested, put on some music you like and watch the process live on live.

2015/02/12 19:04 · chrono · 13 Comments

Fixes for chrony & RTC on Odroid C1 Linux 3.10.67 (ARMv7)

For a long time, all machines in Apollo-NG's infrastructure use chrony as a replacement for the usual ntpd package. chrony can be compared to ntpd like nginx can be compared to Apache, newer, much more lightweight approach and some additional very nice features. While nginx has replaced most of the Apache installations these days, chrony still isn't adopted as a good alternative by most people yet.

During the NTPD reflection attack time and the mysql/kernel/ntpd leap second bug, it was nice to see how chrony really saved a lot of time and grief by not being affected. It has been working here - and in many other scenarios - absolutely flawlessly until today.

→ Read more...

2015/02/07 17:42 · chrono · 8 Comments

NFM GNU-Radio Receiver for RTL/OsmoSDR

Soon after the release of RTL-SDR a lot of people started to play with software defined radios. Although the Elonics E4000 tuner and the Realtek RTL2832U Chip are a long way from the quality and performance/stability of an USRP(2), the price of $11 - EUR30 makes these devices an ideal beginners device for SDR experiments, without having to invest +$1k into hardware.

As soon as the new OsmoSDR is finished and available, it will provide a very cost-effective device, filling the gap between the funcube, with only 96kHz bandwith - some people lovingly call it the sadcube these days - and the USRP. The OsmoSDR approach seems to be the best compromise of both worlds and the osmocom team is doing a real kick-ass job, putting it together.

Right now, not only hackers, but old-school hams and other people are drawn to gnuradio and rtlsdr but sometimes find it hard to leave their known world behind and dive into the new world of doing radio in software. In order to make the transition easier, good examples are desperately needed. The following setup is an easy to understand, uncluttered narrow band FM receiver, that most hams and radio related people should be able to grasp and tweak.

→ Read more...

New Reflow Toaster build with picoReflow

Here is another beautiful automated reflow toaster oven build, which makes use of our open-sourced picoreflow DIY PID conrolled Reflow Oven Software and some bootstrapping concepts & ideas:

http://www.cube37.com/projects/reflow_toaster/design

It's great to see how the concept and software are spreading fast and spawn a whole new generation of inexpensive, modular and autonomous/remote-controlled PID temperature control approaches for all different kinds of applications, perfectly easy to adapt under DIY conditions, because they were developed under DIY conditions.

From the project's perspective we'll need your feedback, issues and ideas to come up with a rough plan to prioritize a couple of milestones we can fragment into work packages to organize a hackathon to push picoReflow's development further into the direction of an even more universal controller (picoPID) that won't even need to be hacked in order to do something else than just reflow soldering :)

So, please join us on picoPID Development Roadmap Pad and share your feedback & needs.

2015/01/29 20:51 · chrono · 26 Comments

Sweet: The lab got a Mitutoyo 2046 Dial-Gauge

In order to reliably calibrate any kind of mechanical system, a dial-gauge really is a necessary tool. Today our Mitutoyo 2046S arrived and will be tasked directly to calibrate the bed of our 3D printer.

mitutoyo-2046s-dial-gauge.jpg

Mitutoyo seems to have a similar reputation level for measurement tools like Makita has for battery powered power tools: A very high price/performance ratio. The lab already carries a couple of other Mitutoyo tools, a large set of Makita tools and both have already proven themselves in terms of quality and reliability on many occasions.

You can even use them in the kitchen to drive mixers etc., this hack was successfully tested in the prototype-galley to create a number of dough's and mix all kinds of things with a Makita BHP459 (18V) while saving precious space and weight, a separate set of kitchen power tools would add. Better to make creative use of equipment which is already on-board, i.e. a battery powered motor with some sort of adapter we can put tools in.

2015/01/27 19:30 · chrono · 66 Comments

Emerge gentoo crossdev avr-gcc for Arduino and Cura

In order to update the firmware of our 3D printer for dual head extrusion and to compile Cura (an alternative gcode slicer) a working AVR crossdev toolchain was needed.

The printer firmware uses the Arduino toolkit so the dependency was obvious, the Cura build unfortunately needs a working avr-gcc as well (not that obvious), because it also ships with Ultimaker firmware, which cannot be disabled, even if you don't have an Ultimaker (kinda stupid).

Currently, the stable crossdev avr-gcc suite with gcc 4.8.3 did not compile so it was a bit of a hassle to get it running again. In order to save somebody else the time to figure this out, here's the install trace that was already tested verbatim on another gentoo amd64 box and worked as well.

Let's start with a clean slate and unmerge any cross-avr chain:

crossdev -C avr

This was used originally:

USE="multilib -cxx" crossdev -v -s1 --without-headers --target avr --gcc 4.5.2 --binutils 2.21 --libc 1.7.0
USE="multilib cxx" crossdev -v -s4 --target avr --gcc 4.5.2 --binutils 2.21 --libc 1.7.0

As of 2015-04-05 the above combination doesn't work anymore, please use this instead:

USE="multilib -cxx" crossdev -v -s1 --without-headers --target avr --gcc 4.5.4 --binutils 2.21.1-r1 --libc 1.7.0
USE="multilib cxx" crossdev -v -s4 --target avr --gcc 4.5.4 --binutils 2.21.1-r1 --libc 1.7.0

And to finish it up:

ln -nsf /usr/x86_64-pc-linux-gnu/avr/lib/ldscripts /usr/avr/lib/ldscripts
ln -nsf /usr/x86_64-pc-linux-gnu/avr/lib/ldscripts /usr/x86_64-pc-linux-gnu/avr/binutils-bin/2.20.1/ldscripts
cd /usr/avr/lib
ln -nsf avr5/crtm328p.o .
ln -nsf avr6/crtm2561.o .
ln -nsf avr6/crtm2560.o .
mkdir -p /usr/share/arduino/hardware/tools/avr/bin/
ln -s /usr/bin/avr-gcc /usr/share/arduino/hardware/tools/avr/bin/avr-gcc
ln -s /usr/bin/avr-g++ /usr/share/arduino/hardware/tools/avr/bin/avr-g++
ln -s /usr/bin/avr-objcopy /usr/share/arduino/hardware/tools/avr/bin/avr-objcopy
ln -s /usr/bin/avr-ar /usr/share/arduino/hardware/tools/avr/bin/avr-ar
ln -s /usr/bin/avr-as /usr/share/arduino/hardware/tools/avr/bin/avr-as
ln -s /usr/bin/avr-size /usr/share/arduino/hardware/tools/avr/bin/avr-size

If you want to use the Software Serial and monitoring feature, you need to install rxtx-2.2_pre2 or newer. This version is still masked in the main portage tree, so you will need to unmask it by adding

=dev-java/rxtx-2.2_pre2 ~x86 ~amd64

to /etc/portage/package.keywords/arduino and then (re)emerge it

$ emerge dev-java/rxtx

Also, if you don't want to use the crappy JAVA based Arduino IDE, you can simply use a Makefile like this: https://github.com/sudar/Arduino-Makefile

2015/01/20 16:07 · chrono · 12 Comments

Clear-Sky Solar Prediction: First Test-Results

Since it's currently winter in central Europe, it's the perfect time to evaluate the ucsspm for its feasibility/validity. After bringing the VFCC online, it was a simple task to ship prediction metrics and reference measurements into influxdb and create a couple of dashboards to create meaningful graphs to evaluate its performance very easily.

Yesterday was the first full clear sky day since the beginning of data collection and the prediction results definitely look very promising as we can see on the following dashboard screenshot:

First clear-sky day prediction results compared to reference pyranometer measurements on VFCC Dashboard

The top right graph shows global solar radiation over a 10 hour period. The green line shows what the UCSSPM predicted as a maximum clear-sky value, the yellow bars show the reference measurement of global solar radiation in W per m² over the same period. The bigger graph at the bottom shows how that translates into the context of photovoltaics (conversion of solar radiation into electricity) and since the output is always a derivative value of global solar radiation the graph looks about the same but the output is measured in W. We can see that we are a long way off the 800-1000 W/m² which are often used for baselining. Of course, it cannot predict the weather but it is an enormous help in planning, scaling and operating solar energy conversion systems in order to have a reliable baseline, so that we know what could be obtained as a maximum at a specific location/time, when there are no clouds.

The reference measurements are sourced from a pyranometer operated by the physics/meteorological department of the Ludwig-Maximilians-University in Munich, who were kind enough to share their data online, which saved us the investment of monetary resources to buy or time to build/calibrate our own pyranometer for now. In order to keep the prediction evaluation results consistent, all other metrics needed by the UCSSPM like temperature, humidity, air pressure etc. are also collected from the same station and fed into the UCSSPM.

If time permits, it would be interesting to see if we can make use of our global cloudmap service, to use either historic or live data for an even more accurate prediction, not just clear-sky baselining.

Long term live reference and UCSSPM prediction metrics are contiously collected and publicly accessible on these VFCC dashboards:

2015/01/14 10:35 · chrono · 19 Comments