Show all posts by user
Page 1 of 1 Pages: 1
Results 1 — 8 of 8
Quoteo_lampe
I just visited your hackaday page and read about the USB-camera problem. I have a USB "Endoskop" camera which is much smaller and comes with integrated LEDs too. The focal length is pretty short, but not as short as a microscope. Just thought, I mention it here...
thanks. I, got a budget ($10) USB endoscope a weeks ago, because of the form factor and the integrated LEDs, but abandon
by
rmie
-
Mechanics
A lot changed since the last update. Oozing was a major issue, but this is now under control by covering the nozzles of unused/parked hotends with silicon wipers (molded from 350°C silicone). The print head is now supported on four steel pins and printed (instead of brass) bushings. Everything except for steel pins and some aluminium T extrusion is printable.
The design files, a plugin for
by
rmie
-
Mechanics
Quoteo_lampe
I wonder how you make sure the z-height is the same on all hotends? Do you set each z-height in the tool change macro?
I correct for the offset in software. One tool is set to zero for bed leveling. Find details about offset calibration here:
A discussion about the options for offset correction will be available soon.
by
rmie
-
Mechanics
QuoteEvan
How is the project coming along? repeatability looks really good.
Much slower than I had hoped for. The first major milestone was reached last week, dual extrusion prints:
I started a project on hackaday.io yesterday, and have plans to publish a lot of the details over the coming days.
by
rmie
-
Mechanics
Sorry that it took me that long to come back to this.
QuoteTrexation
I would love to see more pictures of the designs and more detail of the mechanics of the system.
I just uploaded another video, from a birds view perspective.
The principle is very simple, the hotend mount has two prisms at the bottom and top, that used to lock it in the parking position by moving the hotend back -> left -
by
rmie
-
Mechanics
One of the issues of the usual dual extrusions implementations, IMHO, is that that the unused nozzle(s) are a steady source print hazels and failures, either by damaging the printed object (unequal Z height) or nozzle clogging if materials with different melting temperatures are used (ABS and PLA) or simply oozing. Recently some workarounds appeared. 2-in 1-out hotends (eg. E3D Cyclops) solve mos
by
rmie
-
Mechanics
bobc Wrote:
-------------------------------------------------------
> So the risk is that the host to AVR comms becomes
> a bottleneck. From what I have seen the interface
> to the AVR is still a serial interface, which in
> computing terms is pretty slow.
Some back of an envelop calculation. Let's assume a serial speed fo 115200 baud, that's about 92kBit/s of data.
One segment would
by
rmie
-
Firmware - experimental, borrowed, and future
I thought about this as well, after reading the specs of the upcoming Arduinos (Tre, Gallileo, Yun maybe as well).
They all offer a decently fast linux host as well as a AVR. I too expect python to be to slow/unpredictable for the low level real time stuff, but splitting the firmware into two parts, each dedicated to onw of the CPU's, could just hit the sweet spot for both.
The AVR would execut
by
rmie
-
Firmware - experimental, borrowed, and future