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:

Com::printFLN(PSTR("SDCARDDETECT="),SDCARDDETECT);

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.


Pighixxx.com
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

tempmaxmax
volumespeed
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.