Saturday, March 31, 2018

CoreXY frame

Continuing my noodling around from last week, I started to put together a frame for a CoreXY system. I could have done the right thing and designed this in a CAD package, got all the measurements right, blah-di-blah, but instead I'm just winging it and knocking together what I need in Blender. Here's the frame with motors and runners but no belts yet:
The motors are mounted on plates bolted to the bottom of the frame with spacers to raise them to the right height. These corners of the frame have internal L-shaped brackets.
The gantry is mounted on brackets with runner wheels:
They move quite smoothly, though I think the brackets will bend over time.

For the pulleys, I'm going to use flanged bearings. I really wanted ones with a 5mm inner diameter, but I would have had to wait a couple of weeks to get them, so I bought some with an 8mm inner diameter and added a insert.
I ran out of 5mm washers, but there is an easy solution to that:
The next stage will be to get all the pulleys set up. The motor height is designed to work with pulleys mounted on top of the gantry with a 30mm bolt as you can just see in the video clip. For the pulley fixed to the frame, I'll need a mount to raise them high enough. More to follow.

Sunday, March 25, 2018

Motion systems

I'm starting to play around with motion systems. I have no specific goal in mind: it's just noodling.

Here is a small testbed using a MGN12 linear guide that I bought for a printer upgrade and then never used, together with some parts salvaged from my now-defunct Folgertech printer and a few printed parts. There are printed T-nuts under there, though you can't see them.

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 replacement 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


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.