E3D V4 Hotend

I did some printing with Nylon a few months ago, I was running my hotend at ~245C for a lot of it which is getting close to the point where both the PEEK and the PTFE liner would be damaged. In fact when I stripped the hotend down to change the nozzle I did see signs of damage to the PTFE liner.

Several all metal hotends using a stainless steel thermal break have started to appear on the market, and I ordered the E3D one when they went up for sale.
This is what's in the package.

It's pretty much everything you need to build it, including the alan keys for the set screw and the bolts to mount the fan. E3D has assembly instructions on it's website, they are straight forwards and following the yields something like this.

The purple part is a mount designed for a JHead from http://www.thingiverse.com/thing:60539

Since I was replacing the hotend anyway I took the opportunity to add some inline connectors to make removing it easier.

Here it is mounted on the Rostock Max

Some observations, without the fan the heatsink gets very hot, with it, it's cool to the touch even close to the thermal barrier.
I pushed some filament through by and it's somewhat interesting, there is some initial resistance, but one the filament is moving that seems to clear, more on this in a bit.
I plugged everything in, reset the Z Height on Max, I ended up losing about 12mm of Z, though that could be regained with bigger spacers.
I started a print using PLA and the hot end immediately jammed, after some messing about I did get the print started and it worked well until it jammed part way through the print.
After some experimentation I think the issue is that I ended up mounting the fan perhaps 10mm higher than the supplied fan mount and there is insufficient cooling at the base of the heat sink, this in turn is increasing the length of the melt zone and the PLA is doing what PLA does and jamming.

So I tried a different mounting configuration which allowed me to retain the original fan mount.

This seems to work better, but I still had a hell of a time getting the first layer down, it would get half way through and jam. In the end I set the temperature MUCH higher than I usually would for PLA, the print above is running at 250C. It doesn't behave like PLA at 250C, usually it has the consistency of water at that temperature.

So I pulled out my thermocouple and stuck it in the spare hole on the aluminum heater block, it reads 245C, so the thermistor isn't far off.  I've been printing the same plastic at 190C in the old hotend.
Best guess is the cooling fan is causing a significant thermal gradient in the AL block and as a result the temperature at the outside of the block is significantly different than the actual temperature of the brass nozzle. Unfortunately the thermocouple won't fit into the hotend itself, so I can't verify.

Anyway here's the finished print, really pretty good.

No conclusion at this point, I need to run more PLA through it and see if I can get a handle on how best  to make it work, and obviously run some ABS and Nylon through it.

Optical distance sensors

I've been looking for a good solution to automatic bed leveling, Nophead did some work on this a couple of years ago using a sensor that was deployed during a calibration phase. I've also seen a solution using a metal bed and the hotend itself as a probe.

The idea is simple enough measure 3 points to get the plain of the bed, adjust the incoming GCode to print parallel to it.

The same approach could be taken to auto calibrate a delta printer, though in this case you'd adjust the arm positions to all have the same step value at the same height. It's actually a little more complicated that this because the measurement point would be offset from the center of the head, but it's still relatively simple.

My original idea was similar to Nophead's, have a deployable probe and use a mechanical switch for the measurements, using a system where the head would be moved into a physical obstacle somewhere in the build envelope to deploy/retract the probe.

However a friend of mine pointed me at optical distance switches, used in robotics for obstacle detection.

After reading the datasheet, they are really pretty inaccurate, but in this application accuracy is irrelevant, all you need is 3 values relative to each other, so what matters is repeatability. Of course there is no information on that in the data sheet, so I ordered one from Pololu.

I spent most of the weekend writing a TCP stack for the LPC1768 board, but I did get a change to wire up the sensor and do some rough testing.
I attached it temporarily with some tape to me RostockMax's carriage, and jogged to turn the proximity LED on and off.

I wasn't expecting much, but it turns out it's remarkably repeatable. I would estimate in the 0.02mm range and certainly better than 0.05mm.
So now I have another project to get back to when I have some time...

ARM motion controller Pt1

I picked up a cheap LPC1768 dev board from EBAY, <$40 for a 100MHz ARM processor with a 2.8 inch 320x240 touch screen, with the intention of using it as a printer driver.

A couple of weekends ago I stuck a pololu 4988 stepper driver in a breadboard, ran a few wires, connected a stepper and plugged the step pin into one of the GPIO outputs. A couple of hours later I was running the motor off the board at speeds upwards of 1000RPM, all in all a promising test.

So the next task is writing a real motion controller, now I could just port one of the many existing reprap firmwares from arduino, or even have gone back to the original source and just ported GRBL, but where is the fun in that. For me half the reason for doing it is to better understand the what works and the limitations, and the core of a motion controller isn't actually all that complicated.

First thing I needed to do was be able to coordinate motors so that multiple axis would move together at a requested velocity.
My initial thought on implementing this was to use the RIT timer on the LPC which fires an interrupt when it reaches a comparator value.
Basically you compute the velocity for the move

And  from that compute the number of ticks for each axis

You then just figure out which axis moves next, and set the comparator to that value. at the end of that interrupt you repeat the process and update the comparator appropriately.
This has the advantage of only firing the interrupt when a step on an axis is needed, and the precision of the output is basically limited to a few timer clock pulse, given the clock is running at 25MHz that's pretty damn good precision.
So I built a simple event based system and wrote the code to set up movement across multiple axis. There were two issues.
The first was that as the Cortex-M3 which the LPC1768 is based on doesn't have hardware floating point, so I made the decision to do everything as fixed point, In attempting to retain as much precision as possible I ended up with a 64 by 64 bit divide (which is probably 200+ cycles) in the setup code. This on it's own I could have lived with and I could have probably done some things like breaking down long moves to remove it.
The second issue came up when I finally thought about implementing acceleration, every time a step is taken you have to determine when the next step should be, with constant velocity this is trivially just an add of the interval you calculated above, with acceleration you basically have to solve

for t for every step of every axis, accumulating error as you do so.
OK so we can make this work but is there a better approach?
Yes, but I'll leave it for the next entry.