Wednesday, 24 December 2014

Kossel Mini Variant - opening thoughts

I have decided that my next printer will be a delta printer, and although I have come up with numerous designs, the most recent one seems to be verging towards that of a Kossel Mini, so why not simply build a variant of one of these and have done with it.
Now I could buy a kit of printed parts for $39.99 (£25.76) + $11.81 (£7.61) P&P plus some additional import taxes, but decided instead that since I already have a 3D printer, lets stop being lazy and use that to print the parts and save a few more pennies.

The aim is to complete the build for under £200.00, ideally under £150.00, which I believe is very achievable compared to a purchase price of about $1125.00 (£721.15) for an off-the-shelf version.

Cost of PLA printed parts
Frame Top (20x20)13704.133.00.46931.408
Frame Motor (20x20)34007.681.81.16533.495
Bowden Extruder13719.7330.47010.470


Cost of Vitamins and Electronics

20x20 profile 600mmMotedis2.461.5834.73
20x20 profile 240mmMotedis0.890.5795.16
Slider for 20x20 profileMotedis2.711.7435.22
Carbon fibre Tube 5mm OD, 3mm ID, 180mm (6)Robotdigg5.003.2013.20
Tie Rods & Ball Joints (12)Robotdigg7.004.4914.49
GT2 Belt Loop 1350mm (675 tooth)Robotdigg2.401.5434.62
Geared Nema17 Stepper MotorRobotdigg28.0017.95117.95
Filament Gear DriveRobotdigg4.002.5612.56
Nema17 Stepper MotorsEbay12.558.04324.13
J Head Hot EndEbay24.9415.99115.99
Step Stick Stepper DriversEbay2.301.4845.92
F623ZZ BearingsEbay0.780.5063.00
I ordered some Sanguinololu boards from IteadSutdio a while back at $22.00 (£14.10) for 10 boards, the components, are made up from various bulk orders I have made in the past (thousands of resistors for $0.99, thousands of ceramic capacitors for $4.99, hundreds of radial electrolytic capacitors for $8.99, 10 packs of 40 pin headers for $2.99, etc), I boosted the total cost of board plus components to £3.00 to include some decent connectors, rather than just pin headers.

I don't bother with FDTI chips on the Sanguinololu boards, or the associated components, I either program them via the ICSP header if I need to burn a bootloader, or an external FTDI serial programmer if just updating firmware, I also use bluetooth modules for wireless communications.

M4 or M5 T nuts I buy from Robotdigg at $7.50 (£4.80) for 100, other nuts, bolts and washers I buy from Orbital Fastners in quantities of 100 or more. Something like M4x25mm Allen Socket Button Screws are £3.72 ($5.80) for 100, I just order multiples of 100 as I use them up pretty fast anyway.

As such I will allow a fairly generous figure of £10.00 for nuts, bolts and washers, bringing our total thus far to around £120.00.

I do not want to use a heated bed, so this will save huge amounts of power and I will be able to use one of my many surplus laptop power supplies as a power source.

The print bed will be an 8mm disc of acrylic that has been sanded on one side to give a frosted appearance, this should allow PLA prints to stick yet still be removable once the print completes - a 175mm disc of 8mm acrylic can be had on Ebay for £10.70 ($16.70).

I am intending to try the Acetal Slider from Motedis instead of linear rails, I am not aware of anyone trying this idea before, and I have no idea how well it will work - it may have way too much slop to be of any real use, but at only £1.74 ($2.71) per axis, they have to be worth a try.
If this does not work, then I can use their Acetal rollers instead, these are designed to run in the 6mm slot on the side of the 20x20mm profile, these are £2.67 ($4.17) each, and I would need 9 or more, so I think it is worth the shot on the sliders first, many people have made alternate carriages to run on similar wheels/rollers, so I should be able to adapt one of these fairly simply.
Then there is always the fallback option of Chinese Linear rails at $58.00 (£37.18) from Robotdigg for a set of 3 x 400mm rails and carriages.

Even if end up I trying all 3 options, the total cost should still be well below the target of £200.00.

Tuesday, 9 December 2014

Back up and running again

I decided the quickest way to have the printer back up and functional again would be to glue the broken Y belt holder back together again, then just hope it holds long enough to print a replacement.

I use Plastic Weld to glue PLA pieces together when necessary, it uses capillary action to reach all the tiny gaps to ensure a good join.
I paint it onto both sides of the joint, then paint over as much of the joint as I can after pressing the pieces back together and holding in place.

The Plastic Weld dries pretty fast, usually just a few seconds, but I decided for maximum strength, I would leave it overnight to fully cure.

Next morning I re-assembled the printer and tensioned the Y belt and all seemed to be holding ok.

I set off a new print of a replacement Y belt holder and cross my fingers that the print completes without disaster.

Well I needn't have worried, the print was a success and even after the print had completed, the Y belt had only loosened ever so slightly, so it is possible that the repaired part may have lasted for quite a while longer.

The new part has a much more dense infill pattern and 3 perimeter layers compared to 2 on the original, so should be much stronger.
The original part is on the left, the new part on the right.

I also decided to weigh the two parts for further comparison, the old part weighs in at 7g, the new part at 12g, so nearly twice as much plastic in the new part.

Additionally, the teeth have printed much better on the new part - they were somewhat "stepped" on the original, so hopefully the new teeth will grab the belt better as well.

To be fair, the first set of parts I should have concentrated on making is a replacement set of parts for the printer itself, that way if anything did break, I am not left high and dry.

I think I will print a few more of the smaller replacement parts - one of the top Z brackets broke before I even started to use the printer and has been mended several times already so this will be the next print candidate.

Tuesday, 2 December 2014

A Bridge too Far

I believe I sorted most of the X/Y drift by adjusting the MAX_TRAVEL_ACCELERATION_UNITS_PER_SQ_SECOND_X Y and Z values in the repetier firmware to be the same as my lowered MAX_ACCELERATION_UNITS_PER_SQ_SECOND_X Y and Z settings (1000, 1000 and 100).

The creep has not completely gone away but it is now down to one strands thickness, mainly in the X direction, every 10-20 layers, sometimes I can manage 40+ layers without any creep.

I have been using this new found lack of creep to print out the parts for the Revised Fully Printable Eggbot.
Here are the parts I have printed so far:
These have mostly avoided creep. The two idler ends needed opening out in order for the bearings to fit, this I did with a boring head on my mini mill.

Next I wanted to improve the X axis motor and idler ends as mine don't really hold onto the LM8UU bearings very well.
This thing looked to be a good basis for some new ends that would grip the outside of the linear bearings a bit better.
I modified the ends I had previously drawn in Sketchup.
I mount my motor on the opposite side to most people so I can have a sturdier frame with shorter X rods and still have the same available print area.
This Part was going to be an exercise in bridging no matter how I printed it, so I thought I had better do some bridging calibration using the Bridge torture test so I did not end up with filament hanging down in a mess.
The gap being bridged in these tests is 50mm, each test takes about 5 minutes to print (all test prints are shown upside down for comparison purposes).
The settings were as follows starting with the top left bridge and finishing bottom right, in two colums:

Test #TemperatureBridge Flow

The first bridge was using the settings I had recently been using for general printing, the best bridge is arguably the last one at 186C and 0.85 bridge flow, however, I feel that the temperature was a little low as it is also the most "stringy" of the various prints and had the worst bed adhesion.

Having settled for 188C for the print, I set it off and all was going well at first, then the printer seemed to be creeping in the Y axis which up until now had been pretty stable.

I halted the print after about 20 layers, as the print had moved too far and tightened the belt, then started again from scratch.

This next print was still creeping but nowhere near as bad as before, and then after about 65 layers, whilst I was having dinner, disaster struck, the Y belt holder sheared.
The printer just printed a mess from then until I stopped it wasting any more filament.
On closer inspection of the Y belt holder it looks like the person who made the part was using ridiculously low infill values as there is next to no material inside the part to give it any strength.
Needless to say, this piece or a suitable substitute are now up there at the top of the list of items to make once I can get the printer working again.

On the plus side, at least the bridging of the wide gap in the middle of the print went fairly well, with only a few mm of bowing to be seen in the middle of a 20mm wide gap.

Tuesday, 25 November 2014

Tensioning the X axis

One of the things I have never been too happy about with the Prusa i3 design is the lack of ability to properly tension the X axis.

The best one can usually achieve is to pull on the belt and try to keep that tension whilst jamming the belt into the back of the X carriage, then tie off the ends with a cable tie in the hope that they did not move.
Unfortunately this does not make for a particularly tight belt and there is no means of adding small increments to the level of tightness.

I believe the lack of tension is one of the things that is leading to my missed X steps, so I went looking for a suitable solution.

First try was this thing, that added an additional bearing to tension the belt.
I printed this and assembled, however in a very short space of time ( a couple of hours), the U shaped piece snapped along the base of the U where the most stress is applied and rendered the part useless.

Next I thought I would try this thing, the main issue I had with this one was actually printing it, the top surface simply did not want to attach to the supports and left me with a mess.
I am also not convinced that it is physically strong enough, and would probably snap on the end of the axle pretty fast.

I also started to notice that the right hand Z rod seemed to have a bow in it probably as a result of repeated attempts to tension the X axis.

The Prusa i3 design is found lacking in this area as well, since the right hand Z carriage is not actually secured to the rods, it simply stays in place due to friction.

This second solution would potentially just make this bowing situation worse, so I ditched this design as well.

Next up is a variation on this thing where the tension for the X axis is supplied by pressing on the ends of the X rods.
This seemed like a much more viable solution, so I decided to draw create some suitable items myself in Sketchup.

Here is the tension bracket. This simply fits over the ends of the rods and provides a surface to tension against.
The other item is a bracket to hold the bearing and tension the belt.
These two items complement the existing left Z bracket
After pulling the printer apart and fitting the newly printed part I re-leveled the X axis and tensioned the X belt and tried again. The result was still not perfect, but it was a lot better and the left Z rod is no longer bowing.
The top one is the first print, the bottom one after the upgrade, believe it or not, they are both the same way up with the first layer nearest the bottom of the photo.

Even with the newer second printed tensioner and a lot more tension on the belt, the next print still skipped by about .5mm after 3 layers, so belt tension is not the cause of my X axis skipping, time to look elsewhere, maybe reducing the jerk some more will help.

Wednesday, 19 November 2014

Lets print from an SD card...

As mentioned in my previous post, I have been having what I believe are some random stepper skips as a result of activity on my host machine that cause subsequent layers to become offset in random directions (X and Y) after successfully printing the first 6-8mm of height of a 20mm test cube. My Prusa i3 is correctly calibrated for movement in all axes and also for filament extrusion, however when say the screen saver wants to kick in, or some other background takes requires too much CPU, the communication to the printer slows right down and re-transmits go up and steps are missed.

To try and combat this issue I have decided to try printing from an SD card, however as soon as I upload the new firmware (only change in configuration.h is for changing '#define SDSUPPORT false' to 'true') when I next connect to the printer, via Repetier Host, it now shows the extruder temperature as -20C as opposed to around +19 or +20C. This is the same regardless of whether or not the SD card unit is actually connected. Disabling the sdsupport setting and uploading firmware once again and everything goes back to normal.

The pins.h definition of the SDSS pin for a Sanguinololu is D31 (or A0, or physical pin 40), the Extruder thermistor uses A7 (or D24 or physical pin 33), the heated bed thermistor uses A6 (or D25 or physical pin 34) all as per the default wiring for a Sanguinololu board.

I do not believe I have a short on the board as I regularly use the ICSP connections for re-loading firmware and I have had the SD card working on this same board with a much older version of Marlin at some point in the past, plus this is pretty wide spacing for header pins with large gaps in between.

I raised this issue on the RepRap Forum and had a response from Repetier, the author of the firmware that I am using. He suggested, that this was likely to be a duplication of pin usage, and I have to say that I agree with him, however I cannot prove it.

He also gave me a piece of code to use to print out variable settings to the log interface of the Repetier Host software:


I used this in various forms throughout the firmware testing just about any variable I could think of but only managed to prove that they were all set correctly.

I tried using a separate variable of SDSUPPORT1 to replace SDSUPPORT in a number of source files to only enable parts of the code, this just proved to me where the issue was being manifested, and not the source of the problem.

I confirm that the call to sd.initsd() is what causes the extruder temperature to go to -20C. Preventing this call allows the extruder temperature to read normally, attempting to mount the SD card will then call the sd.initsd() function which in turn calls the fat.begin() function and immediately the card is initialized, the extruder thermistor goes to -20C.

I soldered up a second Sanguinololu board and connected up the thermistors and endstops, This new board exhibited exactly the same behaviour, so I believe that test pretty much ruled out a hardware issue. (This was not an entirely wasted exercise as I intend to use this second board in my laser cutter). For both boards, the SD card can be mounted and files can be seen on the card, which shows me that I also have the SD card wired up correctly, likewise for both boards, with SDSUPPORT set to 'true', the extruder temperature is permanently at -20C, and yet with SDSUPPORT set to 'false' the thermistor values show correctly.

I tried swapping the pins for the Extruder and Heated bed sensors and all that happened is that the Heated bed thermistor experienced the same issue, started reading -20C and again was disabled - this ties the issue to Analog pin 7 and a possible conflict with digital pin 7 (SCK).

I am not entirely convinced that the digital pin numbering for the physical pins 33-40 is correct, there are differing sets of information on the web as to how Arduino maps these pins, the pinout shown in pins.h shows physical pin 33 as Analog 7 and Digital 24, with numbers decreasing for Analog and increasing for Digital up to physical pin 40 which shows as Analog 0 and Digital 31.
shows a different pinout with physical pin 33 as Analog 7 and Digital 31, with numbers decreasing for both towards physical pin 40 which shows as Analog 0 and Digital 24.

I decided to try moving the SDSS pin definition to Digital 24 and something different happened - instead of going to -20C on mounting the SD card, instead it went to about 998C! still obviously wrong, but at least it is a different result, the thermistor signal pin has gone high as opposed to low.

Further checking of the pinouts and datasheet showed that the correct pin to be using for SS with an SD card is actually physical pin 5 (Digital 4), this is also presented on the Sanguinololu board but with the name of PWM/D12, the D12 is somewhat misleading as this is more likely to mean PCINT12, and in the schematic shows as PB4-PWM wihich again are other names for this pin as defined in the Atmel datasheet (PB4/SS/OC0B/PCINT12).

After moving the CS/SDSS pin to D4 (physical pin 5) all appears to be working correctly once again - the SD card can be accessed and both thermistors are sending sensible readings.

I have since performed a print from the SD card, and yes, the printer no longer exhibits any form of slow down, unfortunately it has not fixed my creeping.

In all, several days of tearing my hair out to make very little progress, although now I do not need to worry about my prints failing due to high CPU load or high I/O on my MAC.

Up up and away

My next prints have largely been additional tuning of the printer, the test print being a roller platform for the PLA spool, with varying degrees of success.

My first issue has been that I have issues with Z height for subsequent layers of a print - I can manage to lay down a beautiful first layer, yet one or two layers later the print is being dragged off the build platform because the print head has not risen enough.

At first I thought  that this was because the print was not sticking well enough and tried various different methods of helping the print to stay put, increasing/decreasing the heated bed temperature, Kapton tape, PVA glue, bunny ears, all to no effect, the print fails after about 10-11 layers after being dragged off the bed.

This caused me to look more closely at the Z movement. I double checked the free movement of the axis by moving it up 100mm and back down again.

Initially I was having some results that seemed to imply that my steps/mm were out and I reset these a couple of times until one of the Z screws came loose from the motor and after putting it back in place and re-calibrating, I was back at my original figure of 4000 steps/mm for M5 threaded rod.

The next print was again promptly dragged off the bed again due to the Z axis not having risen enough.

This is when I started reading all sorts of forum posts relating to similar issues, but not really finding anything that would solve my issue, they mainly centre around bed levelling and additional methods of adhesion or bed temperature.

Eventually I stumbled across a posting that related to maximum feed rate and decided to give it a try, changing the MAX_FEEDRATE_Z value from 5 to 3.

This had the effect of slowing down the speed that the Z axis attempts to respond to requests. The result of the change was quite dramatic - I could now see that new layers actually had a noticeable height where previously they had looked more and more squashed.

Looks like on the 5 setting, the acceleration was such that it was causing the stepper to miss steps and slowing it down has stopped this from happening

This new setting combined with a 70C heated bed and I had no corner lifting and no failure of the print due to being dragged off the print surface.

The print still eventually failed, but this was due to insufficient hot end temperature at 180C to cause the new layer to fuse with the existing plastic so the print failed due to de-lamination of the filaments.

I found a table that someone had compiled that showed maximum feed rates against temperature

180C1.59 mm³/sec20mm/sec
190C2.97 mm³/sec37mm/sec
200C4.24 mm³/sec53mm/sec
210C5.59 mm³/sec70mm/sec
220C7.00 mm³/sec87mm/sec
230C8.25 mm³/sec103mm/sec
240C9.54 mm³/sec120mm/sec

Considering at this point that I was using 180C and 30mm/s I was probably a little outside what is realistic.

The next print at 200C was much stronger exhibiting none of the previous de-lamination issues.

It still has issues in that the vertical ends are not straight - they wave back and forth, which does not imply an out of true Z axis, as this would be a more consistent and gradual "lean" of the print.

A test print of a 20mm cube shows the issue more clearly.
Not only is the print moving in the X direction, but also in the Y direction, albeit to a lesser extent.

My guess is that it is a combination of an X axis belt that is not taught enough and possibly too much acceleration on the X axis, much like my Z axis issue, so my next steps are to tighten the X belt again and then reduce the MAX_FEEDRATE_X setting down from 200 and possibly do the same for Y, even though I am not currently seeing the issue here, it could well be experiencing the issue but simply not showing due to the nature of the current test print.

Saturday, 18 October 2014

First Prints

Well, I decided that in order to rule out the torque issue, I decided to buy a Greg's Wade reloaded extruder for Prusa i3 and mount this as a direct drive extruder.

The extruder was £22.99 with free shipping from ebay and came with all the required hardware for assembly.

I assembled the extruder by following the instructions on phenom networks, who have a very good assembly guide with plenty of pictures.

Some of the nuts were a bit loose, others required a soldering iron to seat them in their sockets, and the holes for attaching to the Prusa X carriage were about 5mm out. As a result I had to re-drill one of the sets of holes closer to the hot end so it would attach to the carriage correctly.
I decided to use some M3 nuts as the spacers for the motor as these were unlikely to fall off , unlike 3 stacks of 3 or 4 washers, and make my life difficult when I was attaching the motor to the main assembly.

I then needed to re-calibrate the extruder - this extruder ended up with a steps per mm setting of 826 to extrude 100mm when I requested 10 x 10mm within the GUI.

Some more playing with the slic3r settings and I am finally extruding plastic reasonably well, however it still won't stick to the heated bed.

I re-level the bed and play about with the start height and eventually I start to persuade the PLA to stick to the bed.

Unfortunately now it seems to get half way through the first layer and then tears up the layer as it passes over high spots that have not stuck down or extruded well.

The other issue is that around the time that the first layer is nearly complete, the hobbed bolt in the extruded grinds its way through the filament and no more filament is extruded.
I decide to dismantle the hot end again and check the diameters of the various parts.

Even though I ordered a 1.75mm extruder, it would seem that I was actually sent one for 3mm filament, and the molten filament is backing up through the PTFE liner and eventually becomes too stiff to push at which point the extruder grinds through the filament and stops being any use.

I decided to drill out the PTFE liner from 3mm to 4mm and sleeve it further on the inside with a short length of 4mm OD, 2mm ID PTFE tubing that I have been using on the bowden extruder.

I decide to leave the melt pot as it is for now, even though it is a little to large, and re-assemble and try again.

Finally I manage a decent print that sticks to the heated bed and continues all the way to completion.

The only issue being that 2/3 of the way through the print the host software appeared to be doing a lot of resend activity and the printer nearly ground to a halt, other than that, a fairly uneventful first print.

Following on from the success of printing the front side of the Pirates of the Caribbean Coin, I decided to print the back side as well.
It is still not 100% perfect, but for now I am happy, there are virtually no "strings" showing on the print and both sides printed without issue.

So just over 2 years from my opening post in this blog, I finally have a working printer.

Extruding or not as the case may be...

I found a suitable single pole single throw 12V/40A automotive relay and wired it up as per the previous diagram, however I managed to connect the solenoid backwards at first so nothing happened when I requested power to the heated bed.

This was partly due to translating the pin-out on the relay to the pin-out in the diagram since I had mounted the relay with pin 87 to the right hand side, I had managed to confuse myself regarding the positive and negative sides of the solenoid.
Once I had sorted the wiring including the fly-back diode, the heated bed worked perfectly turning on and off via the relay.
The other thing that you need to do when using an automotive relay is to change the heated bed manager in the firmware from 1 (PID controlled) to 2 (Bang Bang, limited check every HEATED_BED_SET_INTERVAL) where the interval is set to 5000ms.

If you don't do this then when the temperature for the bed is reached, the relay flaps on and off rapidly and, even with the flyback diode in place, manages to reset the microcontroller.

My 1.75mm PLA filament arrived from sunwoif ebay seller - £11.99 inc p&p for a black 1Kg spool. so it was time to start calibrating the extruder.

The first issue was actually persuading the extruder motor to turn at all. It energised when the other motors did and locked in place so I knew that it was receiving power to both coils, however no matter what I did, I could not persuade it to turn when hitting the extrude button in the Repetier Host GUI or even with the Pronterface GUI.

Eventually it turns out that this is a safety feature and it will only turn if the extruder is at a suitable temperature to melt the plastic so as to avoid damage to the motor - that only took an hour or two of searching and finding many other people with the same problem, largely troubleshot by changing motors, stepper drivers and wiring all for something that was as simple as a line of code that prevents extrusion below a certain temperature.

Having managed to persuade the motor to turn, I now needed to calibrate the motor such that when I ask for 10mm of filament, it actually pushes 10mm.

Before making any adjustments to the firmware, I requested 100mm of filament and the motor promptly pushed out 355mm of filament, so some adjustment is definitely required.

The formula for working out the required number of steps/mm is ((extrude button clicks) * (extrude length per click) * (e_steps_per_mm)) / (length of filament pushed) as shown on Josef Prusa's Blog entry.

The initial setting in the Repetier firmware for e_steps_per_mm was 453, so my calculation was (1 * 100 * 453) / 355 which gives a new e_steps_per_mm of 123.

Once the firmware was updated and uploaded a request for 100mm of filament resulted in 100mm being pushed, so we were making progress.

The next issue was with the J Head hot end and the thermistor in particular. Initially I had selected type 1 (100k thermistor Epcos B57560G0107F000 - and many other) for both the heated bed and the extruder.
After not being convinced that the extruder was achieving the correct temperatures (PLA refusing to melt) I started to do some research on thermistors and also double check what type I had bought and used on the heated bed.

Turns out that I should be using type 8 (ATC Semitec 104GT-2) for the heated bed as this is what I actually bought from Rapid Online, however I had no idea what the thermistor was in my Chinese J Head.

I compared the resistances of the two thermistors at a number of temperatures setting the temperature with the Chinese thermistor and then comparing the resistance with that obtained from a spare 104GT in the same hole on the J head. Although it looked like it should be a 100K thermistor in that at around the resistance was close to 100K Ohms just like the 104GT, where the 104GT showed 70K Ohms at room temperature (about 22 degrees C) the Chinese one was showing 80K Ohms.

At higher temperatures it was showing nearly double the resistance of the 104GT. Since I don't have accurate readings for 25 and 85 degrees C it is not easy to work out the required Beta value for this thermistor and from that work out a suitable thermistor table as described on the RepRap Wiki.

In the end I decided to replace the unknown Chinese thermistor with the spare 104GT so at least it would be a known quantity.

The next problem I have is that despite having accurate temperatures at the hot end, my motor is struggling to push the filament and loses steps when the required torque is too high.

I appreciate that greater motor torque is required for an extruder than one of the axes, and even more when using a bowden extruder, however the motor I am using is rated at 4.8Kg-cm/42oz-in holding torque, so more than the recommended 40oz-in mentioned on the RepRap Wiki, although that is with a geared extruder.

I believe part of my problem is that the filament is melting most of the way up the PTFE sleeve in the J Head and then solidifying again at which point it becomes very difficult to push.

If I have the fan turned on, then the hot end struggles to reach temperature, however with it off the PEEK part of the J Head may not be cooled sufficiently for PLA.

I will double check my J Head for the melt chamber size since for 1.75 filament it is supposed to be drilled to 2mm as opposed to 3.5mm for 3mm filament (again from the RepRap Wiki).

It could also be as simple as higher temperatures are required at the hot end - I have been trying 180 degrees C but will try pushing the temperature up to around 200-220 degrees C.

Saturday, 27 September 2014

Printing on Air

After several separate attempts to work out why my end stops were not triggering, on several different occasions over a month or two, double and triple checking the wiring, trying just about every combination of settings in the firmware, I was still no further forward.

I decided to add a connector to the breadboard where I first tested out the hall effect sensor, so that I could verify that they were actually working correctly and I was using the correct side of the magnet with each one.

Sure enough all worked perfectly: I move the magnet close and the LED comes on proving that all is well with the sensor wiring.

I try with hardware pull up resistors between signal and VCC on the sanguinololu board, and with software pull up resistors within the repetier firmware, still no joy.

I try the M119 G-Code to see what the sensor is showing, high or low, again with all of the various different settings in firmware, but all I see is the value staying the same regardless of what I do with the magnet to trigger the sensor.

I edge a little nearer to the problem when I start checking the voltages on the pins of the sanguinololu board both triggered and non triggered between signal and ground - for some reason they are pretty much the same at around 1.3V which seems very odd.

I eventually realise that I when I check the ground to VCC connections of the sensor connections and these are showing minimal voltage (millivolts) that something must be wrong with my wiring on the sanguinololu board.

I check the board in Eagle and there it is plain as day - there is no power to the V+ terminals of the sensors unless a bridge is soldered in place between two of three pads depending on your choice of 5V or 12V.
Sure enough on re-reading the sanguinololu page, under the section titled Endstops, there is a section that mentions soldering a bridge between two of three connectors depending on your choice of 5V or 12V to supply the power to the end stops.

So I remove the board from the inside of the printer frame and solder a bridge so as to make use of 12V for the sensors, reset some of the firmware values, use built-in pull up resistors, and lo and behold the end stops are now working perfectly.

At this point I had the Z axis homing to the minimum setting, and decided now was as good a time as any to try out a dry test print, and what better than the front half of the Pirates of the Caribbean coin from Thingiverse.
I loaded up the STL file into Repetier Host and had Slic3r generate some G-Code, then ran that on the printer.

The estimated time for the print was around 4 minutes, although that was somewhat optimistic, some of the seconds seemed to take ages, and ultimately it failed with about 40 seconds to go, complaining about resend errors and eventually dropped the connection to the printer due to only receiving errors.

I reset everything and tried again, but with the same result at around the same place.

More searching and this looks like it is possibly a communications issue with the Repetier firmware complaining about lines that it has not yet received or has somehow dropped, there are also comments about this possibly being fixed in newer versions of the firmware.

The version I have been using up to now is 0.71, so I download the latest which is 0.91 apply as many of my settings as I can find in the configuration.h and pins.h files and compile up and download this new version to the sanguinololu.

I decided that I don't like the Z axis homing to the minimum value as this could cause the print head to crash into whatever may be on the bed, or even into the bed itself, so I relocated the sensor to the top of the Z axis and made the appropriate changes to the firmware, as this version happily supports this configuration.

The next issue I have is that the printer now tries to print the coin 250mm up in the air after homing all of the axes!

After trying all sorts of settings, none of which had the desired result, I removed the G28 (home all axes) entry from the Custom G-Code section of the Printer Settings in the Slic3r configuration pop-up and manually set the Z starting height and then choose the "Set Home" button on the Print Panel within Repetier Host to convince the software that this is the new Z=0 value prior to starting the print.

This time the print ran all the way through to completion and the host software was keeping track with the printer with regards screen output and what the printer was actually doing, whereas on the previous version of firmware the host appeared to be a few lines of code ahead of the printer and eventually exceeded the available buffer space causing the resend errors.

If I had decided to start with a less complex test piece it may have been some time before I ran into the buffer issue as it only seemed to manifest when lots of tiny moves were being carried out for the surface detail of the coin.

After reading a few horror stories about less than ideal track sizes on the sanguinololu board for the current required for running a heated bed, I have decided that I will run the heated bed directly off the power supply, using the output on the board to activate a suitable relay to enable/disable the connection. This will probably be a 30 or 40A SPST automotive one that I will almost certainly have already somewhere in my garage, or failing that, available for £0.99 on ebay.

The image below is from a thread on the eventorbot forum where they discuss the issue and then show the basic circuit and the use of a flyback diode across the relay connections to prevent back EMF destroying the MOSFET on the sanguinololu board.

Friday, 25 July 2014

Thread-less Lead Screws with no Backlash

I came across an item the other day on Thingiverse that looked pretty interesting, that has huge possibilities for DIY CNC machines - that being a "thread-less ballscrew" with zero backlash.
There are a few other designs that have evolved this idea a little further, including another one that uses cheap 608 skate bearings with 10mm rod and requires around 50lbs (23kg) of force to cause the nut to slip on the rod.
This concept is certainly not new - on researching further, it would appear to be based on an idea that was originally patented back in 1972 by Xerox Corp as a thread-less linear actuator.
There are versions of this design commercially available today from the likes of Amacoil

They even produce a model that has an adjustable pitch, which is produced by varying the angle of the bearings.

More recently in 2011 Fengdong Zhao has further adapted and patented a design to one that can even traverse a curved guide where the core of that guide is composed of strands of wire.
He also includes a useful calculation for determining the lead pitch for the thread-less screw:

tan θ=L/C where
θ=angle of inclination
L = desired lead (inches of revolution)
C = circumference of drive shaft (in inches)

The formula works just as well with mm, so to produce a lead of 1mm on a 10mm rod (the equivalent of M10 threaded rod), the angle of the bearings would need to be 5.71 degrees (atan(1/10)=5.71 degrees), for a 2mm lead - 11.3 degrees and for a 3mm lead - 16.7 degrees.

Monday, 24 March 2014

It's Alive...

I finally managed to find some time to complete the wiring, well, not quite complete, because I still have yet to buy the pins for the extruder motor connector, but sufficiently complete that I could test it out.

I cut a 200 x 200mm piece of glass from one of the many sheets I have saved from various scrapped scanners and all-in-one printers, using a glass cutter I bought on Ebay for the Princely sum of £1.85 with free postage.
I then used 4 of an 8 pack of "binder clips" from Wilkinson (£0.80) to attach it to the heated bed, which needed raising in order to accommodate them, so I replaced the 3 washers with springs (again salvaged from some scrapped printer) and used some longer M3 screws and then did an "eyeball" levelling job to ensure an even distance to the extruder nozzle across the surface of the glass. This partly aided by a spirit level to ensure the X axis and the Y axis were parallel to each other to start with.

The glass improved the flatness of the printing surface considerably. as the heated bed on its own was quite bowed towards the front, something that will only become worse when heated.

I believe the last firmware I burned onto the chip on the Sanguinololu was some version of Sprinter, and so I used this for the initial tests.

The motors seemed smooth and were not vibrating or making nasty noises, so the A4983 stepper drivers from China came pre-adjusted to a useful setting, unlike the ones I bought from Europe.

I was having issues yet again with the endstops, proven by shorting them out and then being able to move all axes in both directions, So I rechecked the endstop wiring and the activation by the magnets and re-did some of the connections and positioning of the hall effect sensors, still having issues, now almost certainly because I am using hall effect sensors rather than mechanical switches and the output needs to be inverted.

Sprinter only compiles with Arduino 0.23, and since I am not interested in firmware that doesn't compile with at least version Arduino 1.0, that means either Marlin or Repetier based on what I have downloaded and played with already.

I opted for Repetier 0.71 as that is what I made work with my I2C LCD, plus it compiles to smaller binary than Marlin and still fits on an ATmega644P even with the LCD code enabled. The 0.91 Repetier code did not want to compile out of the box, even after using the auto configuration web pages, so that will need some more investigation before I try that. 

I disabled the LCD and SD code I had previously made to work, then loaded this up onto my ATmega644P by removing the chip from the Sanguinololu and swapping it with the ATmega1284P on my breadboard before reprogramming it with my USBtinyISP.

Since this was a laborious process, I had a closer look at the ICSP pins on the Sanguinololu board and they just happen to line up exactly with the six pin connector for the USBtinyISP, looks like the guys who developed the Sanguinololu were following the industry standard ICSP header pinout.
As I refused to install the FTDI chip on the Sanguinololu, previously when I programmed it I was using a USBasp programmer, which only had an 8 pin connector, so wiring it up was a little more involved than simply pushing on a 2x3 connector from the USBtinyISP, which has the option of 6 or 8 pin headers.

I am still having issues with the endstops - Repetier seems to completely ignore them, however it decides, based on where it thinks they should activate, to disable movement in a given direction after you pass that point.

I adjust a few more settings, mainly those for steps/mm as the current 10mm move is more like 6mm, based on the actual belts and gears being used.

X and Y axes are using GT2 belts with 16 tooth gears, 1/16 micro steps and 1.8 degree/step motors, this equates to 200 steps/turn (360 degrees/degrees per step = 360/1.8 = 200), and 100steps/mm (steps per turn * micro steps/(belt distance * grooves in pulley) = 200*16/(2*16) = 100).

Z axis is using M5 threaded rod, so with a screw pitch of 0.8mm this gives 4000 steps/mm (steps per turn * micro steps/screw pitch = 200*16/0.8 = 4000).

At least the axes now move the right distance when I choose a 0.1, 1, 10 or 100mm move even if it still completely ignores the end stops. 

Friday, 24 January 2014

Repetier and I2C LCD panel

I was having yet another bash at persuading my breadboard based hardware to work with the I2C connected LCD display as mentioned in my Panelolu post.

I have been bashing my head against a wall with the Repetier firmware for months. Every time I had it use the LCD and uploaded the firmware, the whole board would hang just as it reached the initialisation of the LCD display.

I had tried with the built-in I2C library as well as several other Liquid Crystal libraries, none of which would work with Repetier once the LCD part was enabled.

I could manage to talk to the PCF8574P  I2C chip and obtain the address with the Scanner program, I could also write my own code to talk to the LCD all of which seemed to work fine, yet no matter what I did the LCD would just not play ball with Repetier.

I decided to re-read a bunch of posts about the various Liquid Crystal I2C libraries along with checking the schematics used for each of them, re-check the pin configurations in Repetier and also how it was wired up on the board.

Eventually I discovered that I had the RS and RW pins backwards in uiconfig.h for Repetier and after one last compile and upload we had success and the LCD sprang into life. (kind of begs the question how it was working with the other pieces of software though).
This is my pin configuration for the LCD in uiconfig.h

What display type do you use?
0 = No display
1 = LCD Display with 4 bit data bus
2 = LCD Display with 8 bit data bus (currently not implemented, fallback to 1)
3 = LCD Display with I2C connection, 4 bit mode
4 = Use the slower LiquiedCrystal library bundled with arduino. 
    IMPORTANT: You need to uncomment the LiquidCrystal include in Repetier.pde for it to work.
               If you have Sanguino and want to use the library, you need to have Arduino 023 or older. (13.04.2012)

// This is line 2 of the status display at startup
#define UI_VERSION_STRING2 "Orig. Mendel"

/** Number of columns per row

Typical values are 16 and 20
#define UI_COLS 16
Rows of your display. 2 or 4
#define UI_ROWS 2

/* What type of chip is used for I2C communication
0 : PCF8574 or PCF8574A or compatible chips.
1 : MCP23017
// 0x40 till 0x4e for PCF8574, 0x40 for the adafruid RGB shield, 0x40 - 0x4e for MCP23017
// For MCP 23017 define which pins should be output
// Set the output mask that is or'd over the output data. This is needed to activate
// a backlight switched over the I2C. 
// The adafruit RGB shields enables a light if the bit is not set. Bits 6-8 are used for backlight.
// For MCP which inputs are with pullup. 31 = pins 0-4 for adafruid rgb shield buttons
/* How fast should the I2C clock go. The PCF8574 work only with the lowest setting 100000.
A MCP23017 can run also with 400000 Hz */
#define UI_I2C_CLOCKSPEED 100000L
Define the pin
#if UI_DISPLAY_TYPE==3 // I2C Pin configuration
#define UI_DISPLAY_RS_PIN _BV(4)
#define UI_DISPLAY_RW_PIN _BV(5)
#define UI_DISPLAY_D0_PIN _BV(0)
#define UI_DISPLAY_D1_PIN _BV(1)
#define UI_DISPLAY_D2_PIN _BV(2)
#define UI_DISPLAY_D3_PIN _BV(3)
#define UI_DISPLAY_D4_PIN _BV(0)
#define UI_DISPLAY_D5_PIN _BV(1)
#define UI_DISPLAY_D6_PIN _BV(2)
#define UI_DISPLAY_D7_PIN _BV(3)

The _BV values are the P0-P7 pins from the PCF8574P chip - I only needed P0-P6, D0-D4 are for the low nibble, D5-D8 for the high nibble, you can connect in 8-bit mode if you have enough pins (D0-D7), or you can connect in 4-bit mode (D5-D7), you just pretend that both sets are connected to the same pins and both the low and high nibble data is transferred over these 4 pins.

As mentioned in my Firmware and Making Fumes post, I have 10 pins to play with (13 if you include MOSI, MISO and SCK) on the sanguinololu.

Now I have reduced my LCD pin requirement from 6 to 2, I have a few more to play with, which means I can use the buzzer again, and still have 3 pins spare.

Physical Pin #Pin NameSanguinololu PinArduino UseMy Use
40PA0A0/D31GP I/OSD card CS
9RSTRSTRSTReset Button
38PA2A2/D29GP I/OEncoder 1
39PA1A1/D30GP I/OEncoder 2
16PD2D10RX1Encoder C
37PA3A3/D28GP I/OBuzzer
36PA4A4/D27GP I/OFree

Whilst at a first glance, this might not seem the most logical layout, it makes more sense if you look at the way the pins are actually laid out on the sanguinololu.
I believe I have mentioned it already, but I am not interested in running any firmware that will not compile against a relatively current version of Arduino, (trying to obtain any support for issues with older versions is quite simply a pain), as such I am only interested in firmware that will compile against Arduino 1.0 or greater (I am currently using 1.0.5).

I have not compiled in the extra code for the rotary encoder or the buzzer yet, but things are looking good for using an ATmega644P rather than needing the more expensive ATmega1284P, as the compiled code is only 47,928 bytes. Previously with the Marlin firmware, after enabling the LCD code, I was beyond the 64Kb limit of the ATmega644P.

Here is a possible interface board for the panelolu.
And without the components covering the connections.
The only real difference from the schematic is that the connections for pins 9 and 11 (P4 and P6) have been swapped in order to make wiring simpler.

Wednesday, 22 January 2014

Prusa i3 Physical Build (part 3)

Progress on the build has been somewhat slow recently (almost non-existant for a couple of months).

I eventually caved in and bought a J-Head MK IV hot end from ebay for £21.99.

and an Airtripper extruder for £15.95.

I have made some progress however with the wiring and neatening up some of the cables.
 Here you can see the reworked end of the Xbox power cable and a few other wires that have been routed and had connectors applied.
I also decided that my "free" belts were too narrow (2mm), and did not really stay put when tensioned. So I bought a 10m reel of GT2 belt for £17.61 from ebay and used about 1m each for the X and Y axes (they actually fit the pulleys that came with my steppers better than the T2 belts did, so they were probably GT2 pulleys after all) the rest will be used on future 3D printers or other CNC machines - I see a DIY laser cutter in the future at some point.
I have finally wired up the PCB heated plate using some surface mount components - 2 x LEDs and a 1K resistor.
I have also started on wiring up my hall effect sensors (10 for £2.43 from ebay) for the homing switches. I drilled an extra hole in the bracket to allow for some strain relief.
Here is a shot of the hot end and a home made mount made from some aluminium angle and a small chunk of hdpe (cut from a £3.00 chopping board).
I added a fan that happened to be the right size that was lying around from some scrapped piece of kit and ran this wire to one of the 12v output connectors on the sanguinololu. As you can see I have connected the J-Head via a bowden tube using a pneumatic fitting.
Here is the other end of the ptfe bowden tube connected to the Airtripper extruder, now attached to a stepper motor and mounted on top of the frame.
 Current progress shot from the front of the unit.
I still have some more wiring to do - I need some different pins for the extruder motor as these use a different JST connector with a 2.5mm spacing, a pack of 100 pins is £4.20 +VAT from RS. I have 4 more of these motors, so I think I will buy a pack and reuse the nylon connectors that came with the motors rather than join the individual wires.

I am also waiting on sone kapton tape I bought on ebay to arrive from Hong Kong so I can finish connecting the thermistor for the PCB heated bed.

I still have 2 more hall effect sensors to connect up and position as well as positioning the 6x2mm round neodymium magnets (10 for £1.18 from ebay) to activate them.