Sunday, July 16, 2017

3D Printed Tourbillons, a coda

In my previous post, I wrote about making 3D printed tourbillon mechanisms. There are a few parts in these designs which are not printed, specifically two small bearings, and a few 2mm and 3mm shafts made of steel. There is not much I can do about the bearings, but I was curious to see if I could replace the shafts with plastic and used them in the version III design. I printed 1.8mm, 2mm and 2.8 mm diameter cylinders at 0.1mm layer resolution. They had to be printed with brim, so I then trimmed the brim off with a sharp knife and lightly sanded them. The 1.8mm shafts work quite smoothly for the spring/balance wheel, the escapement gear and the anchor. The 2mm shafts replace the two shafts which hold the frame together. The 2.8mm is a replaced for the the main 3mm shaft. It's a tight fit in the bearings, and is also too loose for the sprocket to engage with it well. I tried to shim it with a little blue tape the way I had done with the steel shaft, but this didn't work. However, putting a small blob of blu-tak (or similar) in the axis hole of the sprocket did. Here is the tourbillon working with plastic shafts (which I wave at the camera at the start).


One though which follows is that you could made the drive shaft better by printing it and the sprocket with a non-round cross section, like the flattened shafts you get on some stepper motors. They probably would not last as well as the steel ones, but it's an interesting idea, as you can cut the plastic to the exact length very easily.

Saturday, July 15, 2017

3D Printed Tourbillon

I've tried several times to print clocks and clock mechanisms, with not much success. Here are three models that I tried:

I printed the first with my original Folger 2020 and the other two with my Eclips3D. None of them ran very well: the clocks would tick for only a few seconds, and the tourbillon watch would not run at all, though I was able to get the tourbillon subassembly to work for a short while.

I don't really know how to debug mechanical systems. With code, I have intuitions about where to start looking and techniques that I've learned over the years for breaking down and isolating the problem. But with most mechanical systems of any complexity, I don't really know how to get started, apart from looking for obvious things such as malformed parts. With a tourbillon, the problem is particularly hard as it isn't a linear sequence of parts, unlike (say) the spring motor, where each gear just turns the next one. In a tourbillon you have a power source which turns a mechanism, and the mechanism gets blocked from turning beyond a point by the anchor, and this causes the balance wheel to turn and then bounce back, nudging the anchor and allowing the mechanism to turn further, consuming a bit more energy from the power source. If any stage goes wrong, the whole thing just deadlocks. In the context of the tourbillon watch, this is made much more complex by the gears to divide down from seconds to minutes and hours.

I like the tourbillon as a design. It just looks interesting when it's moving. So I was happy to find a couple of designs on thingiverse for just the core tourbillon on its own. Here is one. And here is the other. I spent last weekend working on the first one, and almost gave up when it didn't run at all. But unlike the toubillon watch, the mechanism is simple enough that I could look at it part by part and see which parts weren't moving freely or slipped slightly on their shafts under load. With some reprints and adjustments, it worked: not perfectly, but enough that I had some confidence that continuing to tweak it would fix it. When it does stick it is always at the same position, implying that either there are some gear teeth that need adjusting, or possibly that the weight of some of the parts throws the mechanism slightly out of alignment. Here are some pictures and video. It's a bit wobbly in the wideo, and I have since improved this.




I then went on to the other design (it's called design III - the person who made them recommends not trying version II). Again, it took some fiddling and reprinting parts which were a little off. I think this is a less good design than version I. In particular, the power transmission from the sprocket (the wheel with the dimples) is done purely through the shaft that it is attached to. This means it slips quite easily, and once it has slipped a few times, the wear on the inner hole of the sprocket means it will keep slipping. In version I, the sprocket was locked to the mechanism through a hexagonal hole which meshed with a hexagonal shaft on another part. I was able to overcome the slipping with a shim, in the form of a little blue tape wrapped round the shaft. I don't think this is a good long term solution. There are related problems with the other shafts. There are two in the outer cylindrical parts of the frame which hold the tourbillon together, but they are too loose to do this, again requiring a shim to fix them. The shafts for the balance wheel, escapement wheel and anchor are not enclosed at one end, so they can slip out. Here's the video and pictures. Again, it runs but does slow down or stop in some positions.




All in all, I am quite happy with these. Neither runs perfectly, but they've restored my faith that I might be able to get things like this to work. I would really like to tackle this amazing device. Perhaps I will one day.

Friday, July 08, 2016

Eclips3D

My current 3D printer is an Eclips3D, a CoreXY design. Here's a quick tour.

First a general overview:

I bought almost all of the part from Eclips3D or from the links in the standard bill of materials. The black plastic parts are from the kit. The red, blue, orange and white ones are replacements or additions. I can't quite bring myself to cut the belts to the exact length, so they are tied up to the cooling fan.
On the subject of belts, I was worried at how close the belts came to the flanged bearings in the front corner, and so I changed the innermost ones on each side to F605zz bearings instead of F625zz. They are 2mm smaller in diameter, and this created a little extra clearance. You can't really see the difference, but here's a picture anyway:



Around the back of the extruder, it looks like this:
You might just about be able to see that the E3D hotend has a screw-in thermistor instead of the fiddly standard one. I hear that E3D are about to make something like this standard. The cable support is from an entry on Thingiverse by Theo1001. My wiring is not nearly as nice as his; I've never been much good at making projects look pretty. I found early on that the cable bundle would sometimes flop down in front of the X end switch with bad consequences. This lifts it a little out of the way. The hot end is wrapped with ceramic tape in what Tom Sanladerer would call a Kapton burrito. See a previous posting for details.

The rods for the X carriage are mounted in a variant of the original design, again from Thingiverse. Some of the bolts are 18mm instead of the original 16mm ones, as 16mm is only just long enough. Once I changed to these, the X movement went from a bit grindy to being a lot quieter. They are printed in PETG. All the other printed parts are PLA.

I capped the top and bottom of the uprights: the bottom so it didn't damage my desk, and the top to clean up the appearance.
The one at the back left also has a filament guide. These are my own design.
And here is the spool holder. It supports a full 1kg roll of filament fine.

The print bed is a piece of 3mm mirror glass with PrintBite. I've only just fitted the PrintBite, and so far I am very impressed with its ability to grab the first layer when its hot and release it cleanly when it cools down. Around the back of the bed, I have a height adjuster by cporto. He has a newer and better version.
Turning to the electronics, I have the power supply mounted to the lower frame with a couple of brackets I knocked up, and a separate power switch for the LED strip next to the mains switch.

I originally used a RAMPS+Arduino combo, since the recommended Azteeg board was out of stock. I recently switched over the the Azteeg, using a mount that I designed.
If you have sharp eyes, you can also see a reinforcement on the SD card socket, as it was a bit flimsy and came loose from the board. The board is the Azteeg X5 mini version 3 with the new SD5984 1/32 stepper drivers. After the RAMPS, it is incredibly smooth. The drivers get very hot, even after tuning down the current. And they are pretty.

I had difficulty getting my Windows desktop to talk to the board over USB, so in the end I connected the USB to a Raspberry Pi running Repetier Server. I mostly use the Ethernet connection for uploading new configs via the Smoothieware web interface. I have both the cooling and E3D fans attached to the board, meaning I can turn the annoying E3D fan off when I am not printing. The config for this version of the Azteeg X5 is slightly different from the previous version, with the E3D fan attached to port 0.26.

There is still more tuning to do, but so far the speed and print quality are great. I've reliably printed with layer sizes down to 0.05mm. I might in future change over to the Titan extruder. For now, I'm happy.

Monday, July 04, 2016

Ceramic tape

The Eclips3D has two fans: the usual E3D hot end fan, and a layer cooling fan. I was finding that the layer cooling fan was so powerful that the hot end could not keep up when it was running at 100%. I had prints where the temperature of the hot end dropped from 195C all the way down to 130C due to the fan. One way of dealing with this is to set the maximum rate of the fan to 50% or 70%. Another suggestion, from the Eclips3D forums, is to use ceramic tape to insulate the hot end. Amazon sells small amounts of the tape for a cheap price.

The tape cuts easily with scissors or a scalpel and you can wrap it round the heater block and secure it in place with Kapton tape. In my case I wrapped it around so that it would insulate the block from the cooling fan while leaving the ends of the block free. This is good as there isn't much airflow across the ends, and it gives a smooth surface to stick the Kapton to. It looks like this:

Here is the tape before I attached it:


And on the hot end:


(Sorry for the poor picture quality on this one.)

It seems to work quite well in this arrangement. Here is a graph of the temperature in the incident I described before:


And here is a graph from after:

This shows the hot end coming up at 195C with it well away from the bed. At the 11:00 mark, I turned on the fan 100%, with no difference. At 12:30. I moved the Z position to about 1mm, so the backwash from the bed would have an effect. There is a bit of instability, but it did OK.

Finally here is a print of a thin walled cube with the fan at 100%. The print started at the 37:00 mark.


This confirms the dip and recovery for low Z. I will probably still run the fan at a maximum of 70%, except for bridging, so this is a worst (or at least bad) case test.  I have not done PID tuning since attaching the tape and I expect it to be more stable afterwards.

I recommend it if you have this problem. It's cheap, easy to apply, and seems to do a good job. Allegedly you can even touch the hot end when it is hot with this tape on it. Shall I try this? No.



New controller woes and wins

I've been converting my printer (Eclips3D, not the Folger 2020) to use a Smoothieware-compatible board. I settled on the Azteeg X5 Version 3. There's a long story about another board I tried, which I might go into separately. The Azteeg is a nicely-engineered board. Some of the features I like are built-in Ethernet, digital control of the stepper voltages and swappable stepper drivers. I got 1/32 stepper drivers using the new SD5984.

Getting going with this has been a challenging experience.

My previous configuration was a RAMPS board with Marlin, and I connected to it from Repetier Host on a Windows machine. The first problem I had with Smoothieware was that Windows won't maintain a serial connection to it. In Repetier, the connection times out after a few minutes, and the same thing happens using a terminal connection (such as PuTTY). In a posting on the Smoothieware forum, I described the problems in detail. The short summary is:
  • it only happens on Windows.
  • it happens on both Windows 7 and Windows 10.
  • it happens on more than one Windows machine.
  • it isn't fixed by making sure Windows keeps the USB hub out of suspend mode.
  • it happens with a different Smoothieware-compatible board as well.
The Smoothieware people were not very helpful in solving this problem: the thread went into a discussion of problems with Repetier and putting the blame on Windows. Neither of these holds up well. It's not Repetier, as the problem appears with PuTTY. And it's unconvincing that the problem is a systemic one in Windows, as no other device, from RAMPS, Arduino and other embedded boards up to commercial peripherals has ever shown this problem. My best guess is that it is some interaction between the USB stack on Windows and the implementation on the board, probably in the firmware. The thread ended with no resolution.

Given this unsolved problem, there are a couple of ways forward: either access the printer over its Ethernet interface, or switch to a different computer and continue to use USB. There is actually one other option, and that to switch my computer to Linux. This doesn't really work as I have some unrelated software, notably the Google Drive integration, with no counterpart on Linux.

Repetier Host allows you to connect over telnet to a networked printer. It will establish the connection OK, but printing is simply no good. There is a long delay (from a few hundred milliseconds up) after each command, so the print progresses in tiny steps. This probably means Repetier doesn't implement Telnet at a low enough level, using TCP/IP flow control.  Another thing I noticed is that the manual commands make relative movements: click to move by 10 in the X direction and it will move to position X=10 instead. This didn't happen with RAMPS+Marlin. According to the Smoothieware people, the default is absolute movement, but its puzzling why switching boards should cause Repetier to behave differently, as the configuration is broadly the same. The thread on this was again not very helpful.

Another solution is to use Pronterface. It's weak sauce compared to Repetier: no real-time display as you print, no ability to easily drag the objects around to position them, an ugly and inflexible user interface, and not even a kill print button. I use kill print a lot, when I start a print and the first few layers go wrong, or I realize I sliced it with the wrong settings. In Pronterface, the closest is to disconnect, as far as I can tell. It does have one major advantage: printing over TCP/IP works properly. The Smoothieware people recommend Pronterface over Repetier frequently on the forum. If only it wasn't so weak on features and so amateurish in its presentation.

The alternative to connecting by TCP/IP is to use a second computer which a USB connection to the printer and some suitable server software. I had a Raspberry Pi already on my home network, used very occasionally for backups and as a household web server. The best known printer software for the Pi is OctoPrint. You can drag files to its web interface and print them from it. It has, if you install it correctly, Cura engine built in. Some of the features missing in Pronterface are there, though it lacks good preview and arrangement panes. It connected fine, with just the need to reboot after plugging in the USB cable to the printer, and a test print went fine.

Repetier make a server in addition to Repetier Host and there is a build which runs on the Pi. You can upload files to it in a similar way. This also worked, though with a little bit of to-and-fro to set the printer config. It seemed best to change a few setting at a time, then save them. The display in the server was a little weak: it didn't show the temperature anywhere, and there is no preview. However, it's greatest value is that you can set up Repetier Host to communicate with it with full control of the printing and real-time display of the moves it is making.

Based on a couple of test prints, this set up seems to work well. I get all the things I like about the user interface in Repetier Host, together with something which will actually talk to the printer without losing the connection. I will try it more soon and see how it goes.

Monday, June 27, 2016

Glass bed temperatures

If you use a piece of glass on the heated bed of your 3D printer, how does the temperature measured by the thermistor compare to the temperature on the surface of the bed? The thermistor is underneath the bed, close to or in contact with the heater, and glass is a poor conductor of heat. So how do they compare?

I set up an experiment where I put a glass plate on a MK3 heatbed, and measured the temperature using the thermistor in the middle of the MK3 and a second thermistor taped to the top of the glass. This is not a very scientific test, but it gives a rough idea. It's a mistake to treat the values from the two thermistors as strictly comparable, as they they are not very precisely calibrated, but looking at the difference between them provides some insights. For the experiment, I started with the heater off and the bed cool and then raised the temperature 10C at a time from 30C to 80C, waited for the values to stabilize, read the temperatures and took their difference. I did the experiment on three different kinds of glass: window glass, thickness 2,2mm; mirror glass with a silvered backing, thickness 2.9mm; and borosilicate glass, thickness 3.1mm. The values are stable to within about +/-0.2C. In addition, for one reading on each material, I estimated how long it takes for the temperature on top to settle after the temperature on the bottom has done.

Here's the results. A delta of 1.9 means the reading on top was 1.9C below the reading underneath, so for example 28.1 if the reading underneath was 30.2.


Set temp Delta (window glass) Delta (mirror glass) Delta (borosilicate)
30 2.1 2.5 2.3
40 3.7 5.3 4.0
50 6.2 8.4 6.5
60 7.8 11 8.1
70 11 13.7 11
80 13 17 13

I estimated the settling time at the 40C reading, and it was around 30s in each test, perhaps slightly more for borosilicate.

Some things to note. The delta gets larger at higher temperatures. The mirror glass delta gets larger at a greater rate than the window glass delta. This is important, as the deltas are not strictly comparable due to exactly how the top thermistor was attached to the glass. This wasn't apparent for borosilicate (and I don't know what happened with the last reading). To make the point, here are the deltas for mirror glass and borosilicate minus the delta for window glass:
Set temp Delta (mirror glass-window glass) Delta (borosilicate-window glass)
30 0.4 0.2
40 1.6 0.3
50 2.2 0.3
60 2.2 0.4
70 2.7 0.2
13 3.3 -0.6


What does this mean? First, don't trust absolute temperatures. For example, if someone says print on a bed at 60C, figure out what this means for your printer, as you might have a different bed configuration. This shouldn't be news to most people.

Second, if you are switching between different bed types, you probably don't need to worry about changing the temperature if you are printing at 50C (my usual value). It's only a couple of degrees different between the different types. But at higher temperatures, such as 80C and above, you might need to do some adjustment.

Thirdly, consider inserting a delay in your start gcode after the bed reached temperature and before you start printing. If you are heating the bed first and then the hotend, you probably have enough delay already.

You should treat all this with a healthy dose of skepticism. I was really interested in just one question: what should I expect when switching between the piece of glass that I have? It's not a detailed study or guidance on the kind of glass you should choose.

Sunday, February 21, 2016

The extrusion multiplier

There has been some discussion on the Folger thread at http://forums.reprap.org about setting the extrusion multiplier. I've noticed in the past that my printer tends to over-extrude. You see it especially on holes which often print smaller than they should be, and on mechanical parts such as gears. Recently I've been trying to print this pieces for http://www.thingiverse.com/thing:1249221 and it's very apparent.

I did an experiment to get some data on this. When I was still fairly new to 3D printing, I was advised to set the extrusion multiplier to less than 1.0 in cases like this, but I've not previously collected any data on it.

I have already calibrated the E-steps for my extruder, so that if I manually extrude 100mm of filament, I really get that much to within 1 mm. To conduct the test, I created a 10mm cube and then extruded it in vase mode. Vase mode guarantees that there is a single strand of filament, so by measuring the thickness of the (vertical) walls you can see how much filament is being extruded. I did this for four filaments, at extrusion multipliers of 1.0, 0.9 and 0.8 using a 0.4mm nozzle. I also measured the diameter of the filament, by picking three places and at each measuring the diameter twice, with the measurements at right angles to each other. The diameter measurement are a little imprecise, while the wall measurements are probably more accurate. I use a E3D hot end, printing onto blue tape.

The results look like this:

Filament               Wall thickness (mm)          Ave filament diameter
                       x1.0    x0.9    x0.8         and range (mm)
MakerGeeks PETG        0.49    0.44    0.38         1.74 (1.71 to 1.78)
JustPLA PLA            0.50    0.46    0.38         1.78 (1.76 to 1.81)
Colorfabb PLA/PHA      0.48    0.43    0.39         1.75 (1.72 to 1.78)
Meltink3d PLA          0.44    0.42    0.36         1.69 (1.63 to 1.75)

It isn't clear to me why the value are so much larger than 0.40. The numbers looked so close to 0.5 that I even wondered whether I have the right nozzle. However, I use a E3D and the markings on it (dimples in the sides) indicate it is 0.4mm. Another hypothesis is that the weight of the next layer causes each one to squash out a bit; I can't really test this well, but trying to measure just the top layer suggests it isn't the case.

Whatever the reason, I'm going to try setting the multiplier to somewhere around 0.85 for a while and see if I like the results. It may be make PETG printing a little tricky. Reducing the multiplier makes the first layer stick less well, and with this particular brand of PETG (and maybe others, I don't know), that's already a problem. Making the first layer a bit thicker should help.