Notice: Function _load_textdomain_just_in_time was called incorrectly. Translation loading for the OSM domain was triggered too early. This is usually an indicator for some code in the plugin or theme running too early. Translations should be loaded at the init action or later. Please see Debugging in WordPress for more information. (This message was added in version 6.7.0.) in /var/www/excogitation.de/wp-includes/functions.php on line 6114
Notice: Die Funktion _load_textdomain_just_in_time wurde fehlerhaft aufgerufen. Das Laden der Übersetzung für die Domain twentyfourteen wurde zu früh ausgelöst. Das ist normalerweise ein Hinweis auf Code im Plugin oder Theme, der zu früh läuft. Übersetzungen sollten mit der Aktion init oder später geladen werden. Weitere Informationen: Debugging in WordPress (engl.). (Diese Meldung wurde in Version 6.7.0 hinzugefügt.) in /var/www/excogitation.de/wp-includes/functions.php on line 6114 projekte | excogitation
So ever since I brought the plexiprinter along there was the idea of printing christmas cookies, chocolate or other sweets. A long time ago I even bought more than enough syringes on ebay and ever since they were sitting in a drawyer.
After finally showing the printer some attention like 2 weeks back and having Nadia tell me a few days back that we should finally make some 3dp cookies it had to happen.
Since we cancelled the family Christmas (don’t get me wrong – I love my family – just not for Christmas dinner) a few years back – this time of the year tends to be a time were we get stuff done 😉
Syringe attached to the printer: ^ the very first dough extrusion of ours.
The essential programs everyone should know – Slic3r:
A few weeks back I decided it was time to get another 3d printer up and running over at shackspace … again.
I used the Fab@Home Model 1 that I brought like 2 years ago as a base, hooked up the 4pi board that Kliment gave me during the somewhat frustrating first 3d printer build experience.
The extruder ist one of the first commercially available direct drive extruders from qu-bd’s kickstarter campaign.
^^ see that? No heated bed!
I thought I could get this working in a few hours but after ttb had hooked up the endstops and I had built an adapter for the extruder it turned out the 4pi board was broken. *bummer*
So I threw it in a corner and started looking at the electronics the next day or so.
Fortunately the 4pi board is open hardware (schematic on github) and so I set out to find what’s broken.
As it turns out there was an inductor mechanically broken off the board and I _only_ had to find one with the matching value. To get it done I simply unsoldered a lot of inductors from scrap pcb’s and measuring all with a LCR meter.
^^ _quick_ fix.
The next issue I ran into was the extruder that didn’t extrude properly. The problem was that no PLA would come out of the nozzle after a few minutes of printing. Tightening the screw that presses the material against the gear, increasing the stepper current as well as some cussing didn’t solve the issue.
Trying to manually push the PLA through the heated extruder let to the conclusion that the PLA was getting soft too far up in the supply screw and then sticking to the wall. No force whatsoever could then push it through the nozzle.
It then turned out that Phil also encountered the problem with his qu-bd but couldn’t overcome it and so his delta went to the corner again.
We thought of a fix and a few days later I manufactured a supply screw into which you can insert a teflon tube to preven the filament from getting soft too early.
^^ the original was in stainless steel (so I also did it in stainless – is that necessary?) – but the 2.5mm hole isn’t that much fun 😉
Next there was the missing steps issue occuring only in y axis. ^^dickbutt test sample
I fiddled with motor current, speed and acceleration settings, even checked whether the y-axis stepper motor had degraded magnets … but could only get rid of the missing steps by reducing the speed to a whopping 9mm/s (~180rpm).
^^ the comparison measurement show that the the tested motors were all equally good/bad.
After I avoided programming my own microcontroller to get the thing rolling in as little time as possible (sidetracking kills a lot of drive) – I finally decided it was time to take it on.
Actually the realisation that the cheap servo tester assumes the poti position when powering up as middle position convinced me that it was necessary to write my own speed controller – since I can’t (or at least not realiably/comfortably) use the braking functionality of the alien power sytem esc.
Also this way I can – or at least I can try to – write my own soft-start routine so people don’t fall off the back.
@phrewfuf encouraged me to program the arduino nano I tucked in a box some months back for when the time was right 😉
Since he didn’t send me the code I just set down myself today and took the first steps.
Also I had to wildlarize the freaking busted poti I pulled out of a part drawer. If you’re not familiar with the term:
„widlarize“ (invented by Bob Widlar): You take the bad component to the anvil part of the vice and beat it with a hammer। It will make you feel so good, for no damaged parts will appear in your latest application।
It sucks so hard wasting time and money with broken components that I consider not reusing old parts – or at least not the parts lying around shackspace 😉
Here is already another poti hooked up to an analogue pin linked to the pin the servo is connected to:
#include <Servo.h>
//onboard led
int ledPin = 13;
//servo pin
int escPin = 3; // servo signal connected to digital pin 3
Servo escServo;
int potiPin = 7; // potentiometer wiper (middle terminal) connected to analog pin 3
int potiVal = 0; // variable to store the value read from the poti
void setup()
{
pinMode(ledPin, HIGH);
escServo.attach(escPin);
//initial Servo Position
escServo.write(0);
}
void loop()
{
potiVal = analogRead(potiPin); // read the input pin
potiVal = map (potiVal, 0, 1023, 0, 180); //convert input range to servo range
escServo.write(potiVal);
}
