I printed out a terrain piece for a friend to use in his Warhammer 40k game. His group was so happy with the print that they told me they would pay for more, so I went looking for more designs that would suit their purpose (technological debris on a sci-fi backdrop).
I found this really nice design of a crashed “killabot” (pictured above) – a robot driven by a race of aliens called Orks.
I priced it at €5.65 – €0.65 for the cost of the filament, and €5 for the time to setup and print it. This is actually quite a ridiculously low number compared to other people that print things professionally (see 3dhubs.com for your local supplier!).
It was going to take about 8 hours to print, according to the slicer program (Cura). I set it to print about 10:30pm.
This morning, I went to check on my 3D printer (an Anet A8), and noticed it was doing something strange at around the 80% mark – some missing layers in a part of the print were leaving obvious bands in the model.
After checking the Layers view of Cura, I saw that what appeared to be a solid model in the default view turns out to have some errors in it that cause Cura to print out some empty layers (pictured below). This is bad, as it can cause later layers to blob.
Cura has a number of built-in mesh fixing algorithms that can be used. It is not always obvious which one (or combination) will fix the problem so you may need to play with it.
In this case, I managed to fix the missing layers by using “Keep disconnected faces”, which is a last resort option. Here’s the fixed view:
I’ve left the faulty print to continue on, because I think the missing layers were few enough that the thing as a whole will still bond together well, but in future, I’ll take a close look of the layers view of a print before I start an 8 hour print…
I promised myself that the first major thing I would complete with my Anet A8 3D printer was to print another printer.
After calibrating the A8, I found a design online that I liked (the MyCore CoreXY design on Thingiverse (pictured)) and printed out all of the parts needed for both the CoreXY part and for the bed.
I’ve encountered two problems so far: 1. the Y axis rail sliders are designed for LM6UU bearings, but I have LM8UU, so they don’t fit. 2. the MDF I have, which will be used for the walls and floor of the printer, is too thin for the design I printed out
These are easy enough to fix, though.
I can simply adjust the radius of the holes on the Y axis sliders and print them out, fixing the bearing radius issue.
The MDF is slightly harder. I could go out and buy new wood, but I don’t like spending money when there is a free solution in front of me. So, I’m going to thicken up the parts of the MDF box that the plastic parts need to interact with.
If I glue two extra strips of MDF over the existing sheet, that should bring it up to thickness, and should also strengthen the MDF against warping under pressure.
To do this, I needed some G-Clamps for gluing the MDF. I found a wonderful print on Thingiverse which turns out to be very strong when printed at 35% infill. The Anet A8 even did a great job on the knurling detail on the end of the screw (pictured).
I will also need to print out some corner clamps, but there are designs available for that as well.
I love 3D printing! Everything you need, someone has already designed and shared, or you can design for yourself.
After I’ve finished fixing the thickness problems and bearing holes, I need to make a bed for the printer to actually work on. For the first few weeks, it will be an unheated bed, as I haven’t yet ordered a heated bed online. Maybe I could design and build one myself? Or an alternative is to totally enclose the printer and heat the air itself in there to 60 deg – make the thing into a small oven.
Actually, that’s something I’ve been considering anyway – totally enclosing the printer, but having tubes feeding cold air to the fans.
I tried setting this up so that the drum could be rolled from an elastic band or cog against the edge of the drum, but it turned out there was a simpler way – the little air-holes in the drum are an equal distance apart, so I designed and printed a gearbox that could turn the drum using those holes.
It sacrifices a little bit of surface area for the cold side of the drum, but I don’t think it will make a huge difference.
I made a few 1mm errors in the gear box prototypes, but when I corrected them, it worked as soon as I applied power to the motor. The motor I’m using in this case is one of the standard yellow geared motors (like this).
I’m still waiting for the heating element to arrive, but have a few fans I can use to get started on the airflow. I don’t even know what size the heating element I ordered is, so can’t design that side yet, but I can design the cold side while I wait. I’ll get started on that tonight.
The 3D printer I’m using is an Anet A8, and I have to say that it’s a dream to work with compared to my old Makibox 3D printer. I was amazed when I printed out the drum and enclosure for this project and they fit perfectly. With the Makibox, the circles would have been flattened and I’d have to sand away any bits that rub, but this one is just perfect.
Even the gearbox would have been impossible to print on the Makibox. The Anet A8 is so good that when some of my students were asking me for a bill of materials to make a 3D printer, I told them that even though it would be possible to spend €120 or so and make a 3D printer from scratch, they’re better off spending $150 and buying one of these ones instead.
I recently finished building the frame of a shed, and covered it with temporary cladding (MDF and plastic) to protect it during the winter until I have more time and money next year to continue with it.
There is a small lake starting to grow in the shed. I don’t think it’s coming up from underneath the soil, and the door end of the shed is covered in plastic to stop rain coming in, so I think the lake is forming from condensation. The air in the shed is basically dumping water on the inner walls of the shed and that water is then rolling down and converging in a large pool.
Because the shed was being built to house a lab, I had planned on building a dehumidifier at some point anyway (I like to build things, even if it might be easy to buy them), but this is encouraging me to get on with it now and build it early.
So over the last week, I bought a half-kilogram (500g) of desiccant crystals, which just arrived, and I’ve started designing the machine.
I’m using the idea of a “desiccant wheel” – a constantly turning wheel where most of it is adsorbing water, and the final part is being dried of its water and regenerated, with the water being blown out as damp air, and either collected in a jar, or dumped outside (what I’ll be doing).
I designed a small wheel last night and started it printing. It’s 60mm in radius (12cm diameter), so really small for this purpose, but as this is my first time making a dehumidifier, I want to make something small and test it, before making a bigger one.
You can see from the image that the wheel is segmented into six parts. The idea is that the wheel will revolve about once an hour, with each segment getting about ten minutes of that hour with hot air being blown through it while cold air is blowing through the rest.
Heat encourages desiccant crystals to dry, with the collected water evaporating and making the hot air damp. That hot air will be blown into a tube that leads outside the shed. Eventually, I may use the water for an indoor gardening setup, but for now, I’ll just get rid of it.
The 5 remaining segments will have cold air blowing through them, with the dampness in that air being adsorbed onto the surface of the crystals, getting those crystals ready for their next ten minute session in the hot air drying part.
I’m waiting now for the heating element to arrive so I can design the fan section and the electronics to keep the temperature constant.
When the hardware is finished, I’ll then need to start testing it with different temperatures, different fan speeds, different wheel speeds, to see how to get the most moisture out as quickly as possible.
I’ll put my design up on Thingiverse as soon as I’m finished and have a working system, and may even start selling prints if this works out.
I’m thinking that I may have two versions – one which is tuned so you just turn it on and it gets to work, and another which is smart enough to measure relative humidity and work towards a specified value.
I assembled my new printer last week and found some issues with the z-axis.
The first issue was that the right z-axis motor was not staying in step with the left. if the right moved up 1cm, the left might move up 5mm. It was suggested that this might be an electrical balance problem and that I should turn the potentiometer on the Anet board to fix this. I turned the potentiometer about 90% clockwise and that seemed to do the trick. They were both moving the same distance as each other now.
The next issue happened when I tried to print a calibration cube. It came out 20mm*20mm*10mm. Only 10mm high.
After much research and questioning, I settled on three steps to take (after taking some wrong turns involving changing steps/mm):
1. check the alignment of the lead screws. The frame that comes with the printer is off by fractions of a mm in some cases, and this can cause pressure that makes it harder for the motors to turn the lead screws. I found that the left motor was off by about .5mm, so I used a drill to extend the holes in that direction and reseated the motor directly under the lead screw (basically dropped the lead screw down through the brass thing on the x-carriage and moved the motor to where it fit best). 2. turn the potentiometer a bit further. it turns out that potentiometer is not for balancing the two motors – it controls the overall current that goes to the motors. If there is too little current, then the motors can’t lift the x-carriage. 3. change the steps/mm back to the stock 100/100/400. The default settings of 100/100/400 are based on the actual hardware. Stepper motors turn through precise degrees, so it is a mathematical issue to figure out how many turns it takes to move the belts or lead screws a certain distance. If the motors, belts, pulleys, and lead screws have not changed, then the default values should be perfect in all cases.
When this was done, I printed out another calibration cube, and this time, it was perfect. See the image – the cube on the right is the latest.
The next issue to solve involves large prints. My first project is to print out a new printer. I’m printing a CoreXY printer. There are STL files available on Thingiverse for this.
I found almost immediately that the default print bed is inadequate.
1. You can’t print directly onto the aluminium, as the plastic will just slip right off. Even if you could, sometimes a print will get stuck and you might have to chip it off, damaging the print bed. 2. The Anet-recommended method is to place painters-tape (a paper tape designed to let people paint without worrying about getting the paint onto glass, etc). This is not good enough, because it involves placing tape precisely so there are no seams, making sure there are no bubbles. It’s annoying work.
The solution I settled on, and others settled on, is to use a glass overlay. I got a cheap picture frame and took the glass from it. It was a little too long in one dimension so it’s currently poking over the edge on one end.
Keeping the glass in place is a problem. The recommended method is to use clips (like from clipboards) to stick the glass to the aluminium, then remove the handles of the clips so they don’t snag on things. I don’t have any yet, so for now, I’ve settled with some teflon tape. It’s designed to not warp in high temperature, so should be fine for a while, until I can print out some proper solutions for this.
The final problem of the day- I was printing out a piece for the new printer. It initially started very well, printing onto the glass like a dream. However, after the print was about 1cm high, it suddenly came lose from the glass and the printer started printing out a “nest” instead.
After examining the print, I found the problem – the bottom had curled upwards from the bed, reducing the volume that was in contact with it, and making it more likely that the movements of the print bed would break the print free.
The curling is caused by temperature differences between the newly printed layers and already-printed layers. As the plastic cools, it shrinks. If there is even the slightest gap under the plastic when this happens, then this will cause curling.
The solution was to spray hair-spray where the print was to contact the bed. This lays down a thin layer of binding plastic on the glass that increases contact between the print and the bed, reducing the chance that it will come lose.
After printing, removing the print from the glass is a simple matter – I whack the bottom of it with a metal ruler. Instant release, and no damage.
The Facebook community are also avid upgraders and publish a lot of posts explaining what they’re done.
My previous machine was a Makibox, which rapidly fell apart. Even when combined with the parts from a replacement Makibox, it still only lasted a few more weeks, and all prints done from it were fixes for itself.
I’ve had problems with the A8 already, but the community is very good and the printer is common enough that there are plenty of articles online about it.
Example problems I’ve had:
Z-axis motors out of sync. There are two motors controlling the z-axis (up/down). They both run basically through the same circuit. If they don’t receive the same power to both, then one might be a bit jerky or not move at all. On the Anet motherboard, there is a potentiometer between the two Z-axis controllers (looks like a little silver circle with an X in it). I just turned that 1/4 to the right and that fixed my problem.
I printed out a calibration cube and it was only half the height it should be – 2cm*2cm*1cm instead of 2cm*2cm*2cm. The problem here is a mixture of the slicer’s code, and the firmware of the printer itself. I think I have this sorted now – the steps per mm were off in the Z-axis. After some experimentation with the console in Pronterface (and some measurement of movements with a ruler), I think I got it right. List of gcodes are here.
clogged nozzle. Well, this one is an old friend… Sometimes you will find that the extruder doesn’t extrude anything at all. In my case, it was a clogged nozzle – there was a lump of plastic at the top of the throat leading down to the hotend and nozzle. I had to melt it out with a tea-light candle, because it was just /not/ moving. I then poked a guitar E-string through the end of the nozzle (0.4mm – too thin for a needle) to make sure that was clean.
cables a little too short. There is no “play” in the cables, so I found that sometimes the extruder stepper’s controller wires would literally get pulled out as the X-carriage moved. Solution – remove the clip that was holding the black plastic wrap to the back of the LCD, so that the wires could be moved.
Overall, I am /very/ happy with this printer, but I’m still wary from my experiences with the Makibox, so the first project I’m working on with this new one is to print yet another printer – the Smartcore CoreXY.
Every day, I spend about an hour taking figures from Google Webmaster Search Analytics and adding them to a spreadsheet I manage that does some calculations and then highlights anything interesting in the data.
I got tired of the drudgery of it, so spent most of the day today building something to cut that down to just a few seconds. Basically, I just open up the new stats thing, upload a CSV file into it, and it does all the hard work itself.
And then I stuck the whole thing up on GitHub: here you go
I wrote a quick overview of how I approach the scaling-up of FieldMotion, over at the FieldMotion blog.
Basically, we started off with a huge monolithic block of code and data, then looked carefully at it to see how we could tear it apart into logical chunks.
The simplest to start with was data, so we separated out the database into a MySQL master/slave cluster, and a MongoDB replicated shard cluster.
Afterwards, we looked at the actual services that were performed by the server and started separating those out so they were completely independent from the main block.
At the moment, FieldMotion runs across more than 60 servers, and can tolerate sudden catastrophes on pretty much any part of it. We actually had an incident recently where an entire datacentre went offline for about 8 hours, but no-one noticed because we make sure each of our replicas is in a different datacentre.
Time flies. I keep on planning to do things, and then failing to do them because there isn’t enough time, in between working 12 hours a day and trying not to fall asleep as soon as I get home.
I finished the basics of my next book, Live Forever, which I put up in website form so I can figure out through statistics which pages (a lot of them!) need work. Tonight, I’m working on the Cancer chapter so haven’t put that in there yet.
Over the weekend, I hope to get a start on a new project, which will help to design 100% nutrition diets based on common supermarket produce. There are known recommended daily allowances (RDAs) for all nutrients, but when you make your dinner, you don’t calculate an optimal meal because it’s just not practical or easy. The new project is designed to get around that by offering meal plans that are affordable and personalisable (you will be able to put your preferences into it). We’ll see if that gets off the ground!
In CoderDojo, some of my students (I really mentor them, more than teach, but what do you call someone you mentor? Mentoree?) are working on some interesting projects for this year’s Coder Dojo conference and next year’s Young Scientist. Two examples: programmable magnetic levitation, and a laser harp.
In work, we’ve moved beyond the frantic development stage that all companies go through, and are now in stabilisation mode, making sure the system is bulletproof and can scale well beyond current needs. I still find it interesting, even though the work I’m doing at the moment is not flashy and user-visible. Today, for example, I was writing a logging system to make sure that even though users access our mobile servers in a “round robin” method at the moment and the logs of their visits are therefore scattered among the servers, I can still aggregate them on the other end into something that can be searched easily. Not flashy, but quietly satisfying.
I’m going to start blogging again soon. I’m getting more and more into Arduino stuff, and want to be able to explain stuff properly to my students at the Monaghan Coder Dojo, so will be writing articles explaining what I’m teaching.
We’re also doing a new thing with the reports that we generate, where we can apply “skip logic” to the actual reports, resulting in personalised reports depending on the questions answered in the job forms.
I’ve had to take a break from the 3D Printer stuff, because the printer I had (a Makibox) broke down so often that I was spending more time fixing it than using it. I’m not quitting with 3D printing – just need to wait for a bit of cash to come in so I can afford a better printer. Once I have that new printer, the first thing I’m doing is making a second printer with it!